[Bug 105] New: SocketAppenderBase - ObjectOutputStream is not closed in case of an IOException.
http://bugzilla.qos.ch/show_bug.cgi?id=105 Summary: SocketAppenderBase - ObjectOutputStream is not closed in case of an IOException. Product: logback-core Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: Appender AssignedTo: logback-dev@qos.ch ReportedBy: joern@huxhorn.de I think this is the cause of "hanging connections" in case of webserver restarts that I sometimes experience in lumberjack. Anyway, the stream should be closed in case of exception. -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.qos.ch/show_bug.cgi?id=105 ------- Comment #1 from joern@huxhorn.de 2007-10-05 20:39 ------- Created an attachment (id=10) --> (http://bugzilla.qos.ch/attachment.cgi?id=10&action=view) oos.close() in case of exception. -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.qos.ch/show_bug.cgi?id=105 noreply.ceki@qos.ch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Comment #2 from noreply.ceki@qos.ch 2008-03-04 19:41 ------- Joern, I had a similar problem with hanging sockets in a different but very similar context. I has a web-app named SINK which contained the equivalent of SocketServer and numerous clients using the equivalent of SocketAppender. Moreover, it was a *hard* requirement for the clients to send messages to the SINK. For example, if the SINK web-app was not available, the clients would simply stop working. Thus, it was important that the clients successfully *reconnect* to the SINK web-app as soon as it became available. In turns out that the solution was to properly close all the sockets opened on the SINK (including the serverSocket). There was no need to close the socket on the client side after an exception as you are suggesting in your patch. Does the above apply or make sense in your case? Obviously, your patch is still applicable notwithstanding the above discussion. I am looking into it. -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.qos.ch/show_bug.cgi?id=105 ------- Comment #3 from joern@huxhorn.de 2008-03-05 00:23 ------- What you say both applies and makes sense. In our case the webapp had several instances of SocketAppender with numerous SocketServers as clients (my logging app used by several people). Whenever one of the clients just vanished, for example by closing the lid of a laptop, the webapp would grind to a halt! I was a little shocked :) So I implemented my own appender using a TimeoutOutputStream to solve the problem of server blocking. But I still have another problem where the client doesn't realize that he has been disconnected from the server, for example by pulling the network cable. I think I'll implement a server heartbeat to solve this... My implementation is a multiplexing appender that sends events to a configurable list of event receivers. The events are serialized only once and optionally gzipped. But to get back on topic: I think it's a valid general rule to close every resource that is opened, if possible/necessary inside a finally. That way it's closed in either way, both in case of exception and without, and you just don't have to care about it anymore. (OK, I didn't do that in the test case but it's just a test case ;)) I'm especially "suspicious" towards ObjectOutputStream because it partially caches the serialized objects. -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.qos.ch/show_bug.cgi?id=105 noreply.ceki@qos.ch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Comment #4 from noreply.ceki@qos.ch 2008-03-11 20:46 ------- Patch applied in revision 1635. More generally, SimpleSocketServer is much more careful to track open client connections and to close them. A relevant test case has also been added. See also http://svn.qos.ch/viewvc?view=rev&revision=1635 -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.qos.ch/show_bug.cgi?id=105 ------- Comment #5 from joern@huxhorn.de 2008-03-11 22:47 ------- Looks good. -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
participants (1)
-
bugzilla-daemon＠pixie.qos.ch