| Summary: | TelnetAppender accept()ing on closed socket after reconfiguration | ||
|---|---|---|---|
| Product: | Log4j - Now in Jira | Reporter: | Gavin Panella <panellg> |
| Component: | Appender | Assignee: | log4j-dev <log4j-dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.2 | ||
| Target Milestone: | --- | ||
| Hardware: | Sun | ||
| OS: | Solaris | ||
Thanks the bug is now fixed. |
I'm using log4j-1.2-rc1. I configure log4j using DOMConfigurator.configureAndWatch("foo.xml") to create a TelnetAppender. I happily telnet to this and all is fine. I edit foo.xml to change some small things, and when log4j notices the change and reconfigures, the telnet session is disconnected, but I can reconnect fine. However, the old TelnetAppender appears to be lingering trying to accept() connections on it's, now closed, ServerSocket: java.net.SocketException: Socket is closed at java.net.ServerSocket.accept(ServerSocket.java:405) at org.apache.log4j.net.TelnetAppender$SocketHandler.run (TelnetAppender.java:155) It loops endlessly in a while(true) dumping the stack trace to the console. It's only effect (afaik) is to destroy performance (and potentially disk space if console output is being captured). A obvious fix is to replace the while(true) to while(running), modifying this new flag just before the ServerSocket is closed. This does result in a SocketException if the thread is blocked waiting for a connection, but this can be cleanly hidden by conditionally printing the error based on that same flag. ....... If an IOException other than an InterruptedIOException is thrown from accept() then is it not an indication of a 'broken' ServerSocket? Perhaps allowing IOExceptions to propagate would be a better policy?