[jcifs] Thread leak problem on connect timeout
datashock at hotmail.com
Wed Jul 1 16:26:51 GMT 2009
> I don't understand. What does this fix?
This fixes a thread leak. You must have missed the first e-mail I sent on June 25. In that e-mail I described the leak in detail and provided example code to reproduce it.
>> 3) In jcifs.util.transport.Transport at line 172 I removed the timeout argument from the wait command:
>> thread.wait(); /* wait for doConnect */
> That's definitely not right. If you don't wait, connect could return
> before the transport has been fully connected!
But it does wait. I didn't remove the thread.wait, just the timeout parameter. It still waits for the Transport thread. It just doesn't give up before the Transport thread has reached some sort of result. Since the timeout is now handled on the socket connect, the main thread no longer needs a timeout for its wait.
>> Is there any reason why this approach would not be valid for the JCIFS library?
> I don't know. You don't explain what the problem is.
The problem is a bad thread leak if the library consumer continues to retry when the original connect times out. When the target server never replies to the SYN, the socket connect can hang around for 3 minutes (default connect timeout on my Linux machine). This is different from a "Connection denied", or "No Route To Host" type error. See my original e-mail for specifics.
> You do know that we do not explicitly close sockets and that they're
> closed when soTimeout expires right?
With this problem, the soTimeout does not have any relevance to the problem. If the socket connect fails, soTimeout is never set, as the socket connect throws an IOException before the setSoTimeout method is called. The soTimeout only applies to blocking IO calls after the socket is established. With this particular thread leak problem, the socket connection never establishes (IE, no SYN-ACK).
I can re-send my original e-mail if you want to see it. It is available on the GMANE archive.
Windows Live™: Keep your life in sync.
More information about the jcifs