[jcifs] Re: jcifs-1.2.4 stability fixes
Michael B Allen
mba2000 at ioplex.com
Thu Sep 29 21:20:51 GMT 2005
On Thu, 29 Sep 2005 17:10:30 +0200
Lars heete <hel at admin.de> wrote:
> jcifs-threading.diff -
> the biggest one ... there is a big locking problem between
> treeConnect/sessionSetup/sessionExpiration and transport closedown via
> disconnect. Both take the transport-monitor, and if the transport
> socket-connection closes with sessions at a high frequency,
> wrong thread may wait on transport.response_map with transport monitor
> hold, so transport.disconnect will not run, and the transport is unusable
> for a long time (at least REQUEST_TIMEOUT)
> The changes try adress this problem by signalling not only responses but
> also transport state changes via transport.response_map, and setting
> transport.state CLOSING to indicate transport closedown before
> disconnect, so any waiting thread can leave the transport monitor.
>
> the changes are well tested (changing the applications surviving time from 15
> min to at least 2 Weeks)
Lars,
So you're saying Transport.disconnect() is blocked because the transport
is locked by a thread waiting on Transport.response_map. Is the server
closing the socket? And that causes disconnect() to be called. But
because there are outstanding requests the disconnect state is basically
ignored. I don't understand the part about the "wrong thread".
Can you explain this in more detail. Where is the deadlock exactly?
Mike
More information about the jcifs
mailing list