[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