[jcifs] Deadlock while cleaning up old sessions in transport
Michael B Allen
miallen at ioplex.com
Mon Aug 13 14:37:15 GMT 2007
Looks like what we had orignally back in 2.0. I wish it were this simple
Felix. But it's not.
Just curious but have you ever experienced this deadlock in the wild or
does it require test apparatus?
Like I said the other day, the only way to fix this problem is to create
a custom lock class and replace all of the synchronized calls so that one
lock can be used and the lock can be *unlocked* deep in hte call-stack.
On Mon, 13 Aug 2007 13:04:45 +0200 (CEST)
"Felix Schumacher" <felix.schumacher at internetallee.de> wrote:
> Sorry for not including the patch. My Mailclient seems to have a problem.
> The interested can find the patch at
> Am Mo, 13.08.2007, 11:15, schrieb Felix Schumacher:
> > Hi all,
> > We hit the deadlock (which haunts the archives since a long time) while
> > cleaning up old sessions in transport, too.
> > When we traced the usage of setupDiscoLock, it became clear, that it was
> > called in different order in some paths to treeConnect.
> > When called from logoff() it would first lock transport and after that it
> > would try to get setupDiscoLock.
> > When someone came into treeConnect without any lock that someone would try
> > to get setupDiscoLock first. (So you get your dining philosopher problem)
> > To stop this problem you would have to always lock setupDiscoLock first,
> > but in that case you could use the transport lock instead and get rid of
> > setupDiscoLock and make the philosophers use only on fork.
> > This is what the attached patch tries to accomplish.
> > With it applied we could not reproduce the deadlock anymore.
> > Bye
> > Felix
> > PS. Why is the cleanup not done in its own thread? The way it is now
> > implemented will punish somone who just tried to login and gets a new
> > session.
Michael B Allen
PHP Active Directory Kerberos SSO
More information about the jcifs