[jcifs] Deadlock while cleaning up old sessions in transport

[Felix Schumacher]

Am Mo, 13.08.2007, 16:37, schrieb Michael B Allen:
> Looks like what we had orignally back in 2.0. I wish it were this simple
> Felix. But it's not.
Is there any possibility to see the original changes for the setupDiscoLock
I haven't found them googling for setupDiscoLock.
>
> Just curious but have you ever experienced this deadlock in the wild or
> does it require test apparatus?
Well, I have done some tests with 2 threads logging in about 500 Users,
who are just logging in, doing some work and logging out. This ran in a
loop, so that all in all about 2000 work units were done. We will not use
jcifs, if it will lock up in tests, so we are not experiencing it in the
wild, and hopefully never will. (The tests are not that far from reality,
since we are considering using jcifs as a means to implement a
fileexplorer for about 4000 concurrent users. So the cleanup job will be
called and possibility is, that two people will work at that same time)
With the patch the tests are running fine and will not deadlock.
I would like to point out, that there is one more transport lock around
ssn.logoff() which was not there without the patch.
>
> 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.
So given an implementation of concurrent.ReentrantLock (with which one
could start to have a known working implementation), how would you decide
when to unlock the transport and where?

Bye
 Felix
>
> Mike
...
> --
> Michael B Allen
> PHP Active Directory Kerberos SSO
> http://www.ioplex.com/
>