Thanks for the reply, Tim. Tim Mullé replied: > > I also had an earlier post about the SocketHubAppender > creating unnecessary Socket object every second while waiting > for a client to connect.
Hmm, sorry I didn't see your post. I looked through the archives but didn't see anything relevant. > 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... I would sure be interested in trying them out to see if it helps my problem. I've further narrowed down the problem to be in log4j somewhere (most likely the SocketHubAppender). From talking to a couple coworkers yesterday afternoon, they suggested that maybe Java 5 was treating in-JVM socket connections differently than out-of-JVM connections, and that there's a Java bug. To test that hypothesis, I wrote a simple socket server and client and did an A/B comparison of what happens when a server in a thread of your main process exits, compared to when the server is in its own separate process. In both cases, I got an java.io.EOFException, as I'd expect. So, it doesn't appear to be a Java bug. In my A case with SocketHubAppender being a thread within the same JVM as my socket client, I don't get java.io.EOFException when the server process closes. Todd. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
