[
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17500747#comment-17500747
]
Gary D. Gregory commented on LOG4J2-3425:
-----------------------------------------
[~SkyCrawl]
A Syslog Appender is a Socket Appender, so you can use a *SocketOptions*
element, here is a Socket Appender example:
{code:xml}
<Configuration status="OFF" name="MyApp">
<Appenders>
<Socket name="socket" host="localhost"
port="${sys:SocketAppenderSocketOptionsTest.port}" protocol="TCP"
ignoreExceptions="false">
<JsonLayout properties="true"/>
<SocketOptions keepAlive="false" oobInline="false"
receiveBufferSize="10000" reuseAddress="false"
rfc1349TrafficClass="IPTOS_LOWCOST" sendBufferSize="8000"
soLinger="12345" soTimeout="54321" tcpNoDelay="false">
<SocketPerformancePreferences bandwidth="100" connectionTime="100"
latency="100" />
</SocketOptions>
</Socket>
</Appenders>
<Loggers>
<Root level="debug">
<AppenderRef ref="socket" />
</Root>
</Loggers>
</Configuration>
{code}
Any setting on a *Socket*
([https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html]), can be
configured through the *SocketOptions*
([https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/net/SocketOptions.java]),
excepted here:
{code:xml}
<SocketOptions keepAlive="false" oobInline="false"
receiveBufferSize="10000" reuseAddress="false"
rfc1349TrafficClass="IPTOS_LOWCOST" sendBufferSize="8000"
soLinger="12345" soTimeout="54321" tcpNoDelay="false">
<SocketPerformancePreferences bandwidth="100" connectionTime="100"
latency="100" />
</SocketOptions>
{code}
It looks like forgot to document it on the site.
> Syslog appender lacks the 'readTimeoutMillis' setting
> -----------------------------------------------------
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
> Affects Versions: 2.12.1
> Reporter: Jiří Smolík
> Priority: Major
>
> Recently, we've had an issue with our syslog server (collector), where it was
> suddenly unable to forward messages sent to it. This resulted in flooding the
> server and ultimately, exhausting its resources (memory and allocated
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
> # At the moment of exhaustion, one thread (T1) entered the synchronized
> block in TcpSocketManager (see
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
> and tried to write the message (see
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
> # The server didn't respond immediately - actually, it blocked T1 for hours
> (it was most likely waiting for resources to be free).
> # In the meantime, all threads attempting to write a message to the syslog
> appender hanged at the synchronized block (they were waiting for T1 to
> finish).
> Eventually, the connection to the server broke apart or some resources were
> freed, and T1 finished. Interestingly, it didn't throw any exception, but
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in
> our application, but due to the way TcpSocketManager is implemented, our
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a
> read timeout setting to the TcpSocketManager (also syslog appender), which
> would in case of the above described situation prevent T1 from blocking other
> threads for a long time. At least, that's my idea of an easy fix. Connect and
> reconnect timeout settings have a different purpose and were useless in this
> case.
> I am aware that the issue is also a matter of the syslog server
> configuration, but application developers do not always have it under their
> control.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
