My first thought would be to create a more advanced socket appender that uses 
netty.

Ralph

> On Jan 19, 2016, at 5:41 PM, Blake Day <[email protected]> wrote:
> 
> I can send more messages, but for a period of time after the socket closes, 
> messages are discarded. Is there any way to queue (and block) the messages 
> until the socket has been re-established?
> 
> 
> 
> 
>> On 1/19/16, 7:40 PM, "Ralph Goers" <[email protected]> wrote:
>> 
>> This shows the SocketAppender threw an exception because the connection was 
>> closed. The exception was caught by the AppenderControl, which re-threw it 
>> as an AppenderLoggingException.  That exception would have been caught by 
>> the AsyncAppender, which then ignored it.  The SocketAppender then 
>> re-established the connection, so it isn’t dying. You should still be able 
>> to send more messages.
>> 
>>> On Jan 19, 2016, at 5:17 PM, Blake Day <[email protected]> wrote:
>>> 
>>> I’m having trouble getting additional debug messages, but I did get the 
>>> following logs with immediateFail=true on the SocketAppender only.
>>> 
>>> 
>>> By the way, I’m using an AsyncAppender. Would that cause the error 
>>> handling to work differently?
>>> 
>>> 
>>> 2016-01-19 18:30:11,995 AsyncAppender-ASYNC-SYSLOG ERROR Unable to write to 
>>> stream TCP:localhost:601 for appender SYSLOG
>>> 2016-01-19 18:30:11,996 AsyncAppender-ASYNC-SYSLOG ERROR An exception 
>>> occurred processing Appender SYSLOG 
>>> org.apache.logging.log4j.core.appender.AppenderLoggingException: Error 
>>> writing to TCP:localhost:601
>>>    at 
>>> org.apache.logging.log4j.core.net.TcpSocketManager.write(TcpSocketManager.java:140)
>>>    at 
>>> org.apache.logging.log4j.core.appender.OutputStreamManager.write(OutputStreamManager.java:136)
>>>    at 
>>> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:105)
>>>    at 
>>> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:152)
>>>    at 
>>> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:125)
>>>    at 
>>> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:116)
>>>    at 
>>> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
>>>    at 
>>> org.apache.logging.log4j.core.appender.AsyncAppender$AsyncThread.callAppenders(AsyncAppender.java:308)
>>>    at 
>>> org.apache.logging.log4j.core.appender.AsyncAppender$AsyncThread.run(AsyncAppender.java:261)
>>> Caused by: java.net.SocketException: Broken pipe
>>>    at java.net.SocketOutputStream.socketWrite0(Native Method)
>>>    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
>>>    at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
>>>    at 
>>> org.apache.logging.log4j.core.net.TcpSocketManager.write(TcpSocketManager.java:131)
>>>    ... 8 more
>>> 2016-01-19 18:30:52,941 Thread-42 DEBUG Connection to localhost:601 
>>> reestablished.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 1/19/16, 4:59 PM, "Ralph Goers" <[email protected]> wrote:
>>>> 
>>>> Can you enable the debug logging so we can see what is happening in the 
>>>> Appender?
>>>> 
>>>> Ralph
>>>> 
>>>>> On Jan 19, 2016, at 1:32 PM, Blake Day <[email protected]> wrote:
>>>>> 
>>>>> Sorry, on further investigation, it appears that the thread does not die. 
>>>>> But the subsequent log messages are lost from the syslog side.  I found 
>>>>> https://issues.apache.org/jira/browse/LOG4J2-122, but I am not sure what 
>>>>> to make of it.  I’ve also tried playing with immediateFail and 
>>>>> reconnectionDelayMillis, but nothing seems to have the effect I want.
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 1/19/16, 2:36 PM, "Blake Day" <[email protected]> wrote:
>>>>>> 
>>>>>> I’m using SocketAppender to log to syslog-ng.
>>>>>> 
>>>>>> 
>>>>>> When logging a message that exceeds 8192 bytes (a syslog-ng setting), 
>>>>>> syslog-ng gives an error and closes the connection.  What happens 
>>>>>> immediately after is unclear, but it appears that the java thread just 
>>>>>> dies silently.  The thread itself is a quartz scheduler worker thread, 
>>>>>> but I thought I’d ask here to see whether you guys think this is a 
>>>>>> log4j related issue.  There are no java application logs (console or 
>>>>>> otherwise) to suggest what happened.
>>>>>> 
>>>>>> 
>>>>>> Here is the output from syslog-ng’s side:
>>>>>> 
>>>>>> 
>>>>>> 2016-01-19T14:26:34-05:00 ERR syslog-ng[87462]: - Incoming frame larger 
>>>>>> than log_msg_size(); log_msg_size='8192', frame_length='100233'
>>>>>> 
>>>>>> 2016-01-19T14:26:34-05:00 NOTICE syslog-ng[87462]: - Syslog connection 
>>>>>> closed; fd='34', client='AF_INET(127.0.0.1:10142)', 
>>>>>> local='AF_INET(0.0.0.0:601)'
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
> ТÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÐÐ¥FòVç7V'67&–&RÂRÖÖ–âÆösF¢×W6W"×Vç7V'67&–&TÆövv–æræ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖÖ–âÆösF¢×W6W"Ö†VÇÆövv–æræ6†Ræ÷&pÐ
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to