Multiple things could slowdown drastically TcpSyslogMessageSender

[bsigouin]

TcpSyslogMessageSender has three things that need to be change in order for that class to be more reliable regarding performance

1. Connection timeout should be configurable and have a default value of 5ms (or even less)
2. Inner retry mechanism should be remove or be configurable
3. sendMessage should not be a synchronize method (actually one thread at a time can sent a log and could lead to huge slowdown when there is high volume of event being log)

• my recommendation is to start using non-blocking socket and remove the synchronization in order to avoid any performance issue

[cyrille-leclerc]

Connection timeout should be configurable and have a default value of 5ms (or even less)

Please see TcpSyslogMessageSender#setSocketConnectTimeoutInMillis(int socketConnectTimeoutInMillis)

https://github.com/CloudBees-community/syslog-java-client/blob/syslog-java-client-1.1.7/src/main/java/com/cloudbees/syslog/sender/TcpSyslogMessageSender.java#L256

Inner retry mechanism should be remove or be configurable

Please see TcpSyslogMessageSender#setMaxRetryCount(int maxRetryCount)

https://github.com/CloudBees-community/syslog-java-client/blob/syslog-java-client-1.1.7/src/main/java/com/cloudbees/syslog/sender/TcpSyslogMessageSender.java#L260

sendMessage should not be a synchronize method (actually one thread at a time can sent a log and could lead to huge slowdown when there is high volume of event being log)

2 key ideas that motivated this choice are:

• For reliability & scalability, users can introduce a syslog forwarder on their infrastructure, close to the emitter.
• The UDP sender could solve some scalability problems ... with some downsides