[jcifs] pile up of Transport threads in BLOCKED state
Adam Morgan
adam.morgan at Q1Labs.com
Mon Dec 20 13:20:30 MST 2010
Even proposed diffs? Okiedoke.
thx
-----Original Message-----
From: Michael B Allen [mailto:ioplex at gmail.com]
Sent: Monday, December 20, 2010 4:18 PM
To: Adam Morgan
Cc: jcifs at samba.org
Subject: Re: [jcifs] pile up of Transport threads in BLOCKED state
Please send all replies to the JCIFS mailing list (unless your sending
me a capture).
On Fri, Dec 17, 2010 at 8:35 AM, Adam Morgan <adam.morgan at q1labs.com> wrote:
> Hi Mike
>
> 1 - the interrupt I just put in there for good measure. If the thread is blocked it will pop it out of that state, but no, I cannot show that to be necessary conclusively.
>
> 2 - The problem with using setSoTimeout() is that the existing code calls it AFTER new Socket() is called. In this case, the default timeout of 'infinity' is used and the socket creation will spin indefinitely if the IP is unreachable, thereby making the setSoTimeout() call unreachable. This is why I changed the code to define the local and endpoint InetSocketAddress objects and pass those into bind() and connect() respectively with separate calls, passing the timeout value in the connect() call.
>
> Does that make it clearer? If you need proof, set up a simple transport thread to point at an unreachable IP and you'll see that it never comes back from the new Socket() call.
Hi Adam,
Yes. That makes perfect sense and it's clearly an improvement to the
code. I still don't know when the fix will be applied but I did move
it toward the top of the TODO.
Thanks for the feedback,
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
More information about the jCIFS
mailing list