[jcifs] Re: Deadlock in SmbTree.treeConnect()
Usenet.r96 at gishpuppy.com
Wed Apr 23 16:20:52 GMT 2008
> 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.
More information about the jcifs