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

Yi commented on LOG4J2-2989:
----------------------------

Hi [~mattsicker],

Thanks for the suggestion and Apache Flume looks good. But unfortunately we 
cannot switch our remote log server to Flume.

Anyway, our current situation is that we can only stream to the remote log 
server. Could log4j make an improvement for SocketAppender to buffer the bytes 
if reconnector cannot reconnect immediately? Otherwise, there is a risk of 
losing logs when the remote server has a short outage with SocketAppender.

Thanks in advance.

> Has Log4j2 a risk of losing logs for streaming towards a remote server when 
> it cannot re-establish a connection towards the server?
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-2989
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2989
>             Project: Log4j 2
>          Issue Type: Question
>          Components: Appenders
>    Affects Versions: 2.13.3
>            Reporter: Yi
>            Priority: Major
>
> Hi,
> Currently we are trying log4j2 to stream logs towards the remote server with 
> SocketAppender.
> I am checking the source code of TcpSocketManager and its inner class 
> Reconnector.
> protected void TcpSocketManager:write(...)
> In the above function, once the manager cannot write to the socket, it use 
> the reconnector to reconnect synchronizely. If it succeeds, it sends the 
> bytes again and everything is fine.
> However, if it fails, the reconnector is going to start a seperate thread and 
> wait for a configurable time to reconnect. But the current method throws an 
> exception instead and the bytes/Log event is then lost due to broken 
> connection.
> Is my understanding correct? If so, can it be improved?
> Thanks in advance. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to