[jcifs] Thread leak problem on connect timeout

[Michael B Allen]

On Wed, Jul 1, 2009 at 11:32 AM, Data Shock<datashock at hotmail.com> wrote:
>
> Has anyone had a chance to look into this yet?  It's very easy to reproduce.
>
> I
> modified my local copy of the source code to use the Socket.connect
> method and no longer have the leak.  (Note, I only changed SMB related
> code so other code paths may still leak threads)
>
>
> Here are the modifications I made to the 1.3.10 code:
>
> 1) In jcifs.smb.SmbTransport at line 181 in the ssn139 method, I changed the socket creation code to:
>
>            socket = new Socket();
>            if (localAddr != null) {
>                socket.bind(new InetSocketAddress(localAddr, localPort));
>            }
>            socket.connect(new InetSocketAddress(address.getHostAddress(), 139), RESPONSE_TIMEOUT);
>
>
> 2) In jcifs.smb.SmbTransport at line 248 in the negotiate method, I changed the socket creation code to:
>
>            socket = new Socket();
>            if (localAddr != null) {
>                socket.bind(new InetSocketAddress(localAddr, localPort));
>            }
>            socket.connect(new InetSocketAddress(address.getHostAddress(), port), RESPONSE_TIMEOUT);

I don't understand. What does this fix?

> 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!

> 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.

You do know that we do not explicitly close sockets and that they're
closed when soTimeout expires right?

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/