[jcifs] Re: Deadlock in SmbTree.treeConnect()

[Ronny Schuetz]

Hi Mike,

 > I just want to reiterate my position on this bug. Search through the
 > archives for details.
 >
 > There is no way to fix this issue with more locks. You can easily add
 > enough locks to get it to pass your tests but you will never really
 > fix it. The problem is a fundamental issue between Java's synchronized
 > primitive and how JCIFS works - you can't unlock the transport but leave
 > the session / tree locked. For that we need a condition variable class
 > (Java 1.5's ReentrantLock looks like it might work - although the bloated
 > nature of the concurrency api is worrisome).

I agree, the currently existing fix works fine for us.

 > Also, my current understanding is that this deadlock has never been
 > triggered without using a contrived test specifically designed for the
 > purpose of triggering a deadlock. If your application really tries to
 > crawl over the same resource with 50 threads at the same time, it's
 > broken. The only use-case that comes close to this behavior would be

Actually we had the issue before the additional locks got introduces 
even with less threads (IIRC 10, pulling files in parallel). Thats why I 
found it at all, testing with 200 threads was done only to find all the 
places I had to synchronize. I'm pretty sure that the deadlock can occur 
with 2 threads only, but the likelihood gets of course lower and lower 
the fewer threads are used; however, it won't reach 0% as long there is 
more than 1 thread.

Best regards,
Ronny