Hi, I also had an earlier post about the SocketHubAppender creating unnecessary Socket object every second while waiting for a client to connect. It appears the reason for this is so the SocketHubAppender could be restarted dynamically.
To fix this, I copied and pasted the code for the SocketHubAppender, removed the setting of the timeouts on the ServerSocket and added a call to serverSocket.close() in the shutdown method on the ServerMonitor inner class. Without calling close on the server socket, the log4j system hangs because the server socket is stuck in the accept() method. This is why they were using the timeout on the socket..to periodically break out of the loop to check if they should shutdown and restart. My fix is working locally and I could send a diff to the group if they wanted to see the changes... - Tim -----Original Message----- From: Bradley, Todd [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 5:43 PM To: [email protected] Subject: SocketHubAppender issues with socket cleanup Hi, I've been using log4j the past month or so, and am fighting an unusually wily problem related to socket shutdown from SocketHubAppender. I've written a class that acts as a socket client and connects to an application using a SocketHubAppender to gather up log events. To unit test my class, I've written a test fixture that I call FileSpewer. It just reads lines from a file and sends them out as log4j log messages. So, when FileSpewer is running, it's a log source and my other class (which is called LogProxy, FWIW) is the log sink. I'm running both in their own thread. When FileSpewer's thread exits, I would expect some sort of exception to be thrown from LogProxy's socket read. Specifically, I'd expect either an EOF exception or a connection reset exception. However, I don't get either. The socket read just waits and waits for a log event that's never going to arrive (because the log source has exited). I've read the note in the docs about "If the JVM hosting the SocketHubAppender exits before the SocketHubAppender is closed either explicitly or subsequent to garbage collection, then there might be untransmitted data in the pipe which might be lost. This is a common problem on Windows based systems." And I thought I might be seeing a similar issue, since I'm on Windows XP. So, I tried explicitly calling my SocketHubAppender's close(). However, it doesn't fix the problem, and causes null pointer exceptions instead (I noticed through the log4j debug messages that SocketHubAppender is trying to call serverMonitor.stopMonitor() on a serverMonitor that is null). A few other bits of info that may be useful: When I run my FileSpewer as a separate app (rather than running as a thread of my JUnit test), my socket client does get a "Connection reset" exception when that separate app closes down. However, when I run FileSpewer in a thread spawned by my JUnit test case, I never do get that exception. Any ideas? I've been debugging this problem all day and am at wit's end. Thanks in advance, Todd. ---- Todd Bradley - Polycom - QA Lead, Super Secret Project Visit me at my WebOffice for IM and app sharing: http://www.polycomweboffice.com/[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]
