You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Ralph Goers (JIRA)" <ji...@apache.org> on 2012/10/14 17:47:02 UTC
[jira] [Comment Edited] (LOG4J2-96) Error with SocketServer
[ https://issues.apache.org/jira/browse/LOG4J2-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475850#comment-13475850 ]
Ralph Goers edited comment on LOG4J2-96 at 10/14/12 3:45 PM:
-------------------------------------------------------------
It might, but I'm having a hard time reconciling the problem report with the code. If you look at SerializedLayout you will see that it sets the header by opening an ObjectOutputStream and then immediately closing it. It then has a private class that overrides ObjectObjectStream to specifically prevent the header from being written with each object. SocketAppender extends OutputStreamAppender and OutputStreamAppender calls manager.setHeader() which is where the header is actually written to the outputStream. It isn't even stored in a variable.
In addition, the unit test is calling logger.debug twice and is able to get the events from the List where they were placed by the SocketServer so even without eclipse I'm having a hard time understanding how this could happen without a completely new SocketAppender and AppenderManager somehow writing to the stream.
Can you provide a sample app that shows the failure? If not, could you walk through the flow and figure out how the header is being added for the second object?
was (Author: ralph.goers@dslextreme.com):
It might, but I'm having a hard time reconciling the problem report with the code. If you look at SerializedLayout you will see that it sets the header by opening an ObjectOutputStream and then immediately closing it. It then has a private class that overrides ObjectObjectStream to specifically prevent the header from being written with each object. SocketAppender extends OutputStreamAppender and OutputStreamAppender calls manager.setHeader() which is where the header is actually written to the outputStream. It isn't even stored in a variable.
In addition, the unit test is calling logger.debug twice and is able to get the events from the List where they were placed by the SocketServer so even without eclipse I'm having a hard time understanding how this could happen without a completely new SocketAppender and AppenderManager somehow writing to the stream.
Can you provide a sample app that shows the failure?
> Error with SocketServer
> -----------------------
>
> Key: LOG4J2-96
> URL: https://issues.apache.org/jira/browse/LOG4J2-96
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.0-beta1
> Reporter: Robert Breunung
> Assignee: Ralph Goers
> Labels: appender, layout, server, socket
>
> Hello,
> by using your core.appender.SocketAppender and your core.netSocketServer I found a dissent.
> I am using the default setup of the appender with the SerializedLayout. The first send event to the server is properly deserialized. on the second I get an IOException:
> log4j java.io.StreamCorruptedException: invalid type code: AC
> I researched the problem and I found a solution here:
> http://stackoverflow.com/questions/2393179/streamcorruptedexception-invalid-type-code-ac
> The appender creates a new output stream for each log event. It writes every time a header. The listening server don't expect a header the second time. Because of this it crashes.
> Sincerely
> Robert Breunung
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org