[ 
https://issues.apache.org/jira/browse/LOG4J2-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913331#comment-16913331
 ] 

Ralph Goers edited comment on LOG4J2-2679 at 8/22/19 2:10 PM:
--------------------------------------------------------------

Yes, TCP sends an ACK for every packet. That is typically handled by the OS, 
not the target application, so it doesn't mean the target app has received it. 
In fact, it may not have even been sent. See  
[https://stackoverflow.com/questions/14782143/linux-socket-how-to-detect-disconnected-network-in-a-client-program],
 [https://stackoverflow.com/questions/14303198/is-tcp-100-reliable] or 
[https://stackoverflow.com/questions/52202529/c-tcp-cannot-detect-broken-connection].
 So unfortunately, just because send has been called and received a successful 
response it doesn't mean the target application has actually received it. So 
ACKs have to be handled by the protocol used by the application to be reliable. 
Raw TCP and Syslog don't perform ACKs at that level.

As for the second behavior, the SocketAppender tries to reconnect. The 
reconnect should fail if the server is still down so I am not sure why you 
wouldn't be seeing an error for that.


was (Author: [email protected]):
Yes, TCP sends an ACK for every packet. That is typically handled by the OS, 
not the target application, so it doesn't mean the target app has received it. 
In fact, it may not have even been sent. See  
[https://stackoverflow.com/questions/14782143/linux-socket-how-to-detect-disconnected-network-in-a-client-program],
 [https://stackoverflow.com/questions/14303198/is-tcp-100-reliable] or 
[https://stackoverflow.com/questions/52202529/c-tcp-cannot-detect-broken-connection].
 So unfortunately, just because send has been called and received a successful 
response it doesn't mean the target application has actually received it. So 
ACKs have to be handled by the protocol used by the application to be reliable. 
Raw TCP and Syslog don't perform ACKs at that level.

> SocketAppender/Syslog Appender with TCP protocol does not throw exception 
> immediatly when server is not reachable
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-2679
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2679
>             Project: Log4j 2
>          Issue Type: Bug
>    Affects Versions: 2.12.0
>         Environment: The code is running on apache-tomcat 8.5 on Linux
> NAME="CentOS Linux"
> VERSION="7 (Core)"
> ID="centos"
> ID_LIKE="rhel fedora"
> VERSION_ID="7"
> PRETTY_NAME="CentOS Linux 7 (Core)"
> ANSI_COLOR="0;31"
> CPE_NAME="cpe:/o:centos:centos:7"
> HOME_URL="https://www.centos.org/";
> BUG_REPORT_URL="https://bugs.centos.org/";
> CENTOS_MANTISBT_PROJECT="CentOS-7"
> CENTOS_MANTISBT_PROJECT_VERSION="7"
> REDHAT_SUPPORT_PRODUCT="centos"
> REDHAT_SUPPORT_PRODUCT_VERSION="7"
>  
>            Reporter: Tamir Noach
>            Priority: Major
>
> Hi,
> We're using Log4j 2.12.0 org.apache.logging.log4j:log4j-core:2.12.0.
> We creating in code SyslogAppender with *TCP *protocol in order to send 
> Syslog LogEvents to remore syslog server
> +*Problem 1*+
>  if the syslog server is down or not reachable we are NOT getting immediate 
> exception when trying following code. 
> try {
>             StructuredDataMessage message = new StructuredDataMessage("", 
> logMsg, type, params);
>             LogEvent logEvent = Log4jLogEvent.newBuilder()
>                 .setMessage(message)
>                 .setLevel(level)               
>                 .build();
>             appender.append(logEvent);
>             //LogEvent was sent and we need to check if we need to close the 
> alarm
>             if(alarmOpen){
>                 closeSyslogConnectionAlarm();
>             }
>         }catch (Exception exc){
>             //Exception is thrown only if we work with TCP/TLS and set 
> SocketOptions
>             log4jLogger.error("failed to send to syslog",exc);
>             if (!alarmOpen){
>                 openSyslogConnectionAlarm();
>             }
>         }
> +This is how we create the SyslogAppender +
> private SyslogAppender createAppender(URI uri, SslConfiguration 
> sslConfiguration, Protocol protocol, String name, Layout<? extends 
> Serializable> layout) {
>  *{color:red}SocketOptions socketOptions = new 
> SocketOptions().setSoTimeout(5000);{color}*
>  SyslogAppender appender = SyslogAppender.newSyslogAppenderBuilder()
>  .setName(name)
>  .setAppName(APP_NAME)
>  .setIgnoreExceptions(true)
>  .withHost(uri.getHost())
>  .withPort(uri.getPort())
>  .withConnectTimeoutMillis(5000)
>  {color:red}.withSocketOptions(socketOptions){color}
>  .withSslConfiguration(sslConfiguration)
>  .setFormat(FORMAT_RFC_5424)
>  .withProtocol(protocol)
>  .withImmediateFlush(true)
>  .withImmediateFail(false)
>  .withReconnectDelayMillis(1000)
>  .setLayout(layout)
>  .build();
>  appender.start();
>  return appender;
>  }
> *+Problem 2+*
> After we created the SyslogAppender the appender SocketOptions is null !
> please advise if we're not creating the SyslogAppender/SocketAppender 
> correctly.
> Following code is copied from your SyslogAppender implementation: Line 135
> final AbstractSocketManager manager = createSocketManager(name, protocol, 
> getHost(), getPort(), getConnectTimeoutMillis(),
>                     sslConfiguration, getReconnectDelayMillis(), 
> getImmediateFail(), layout, Constants.ENCODER_BYTE_BUFFER_SIZE, 
> {color:red}*null*{color});
> The last parameter is null while it should be SocketOptions..
> Is this intended or a bug ??
> Will appreciate your quick response.
> Regards, Tamir



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Reply via email to