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

Michael B Allen miallen at ioplex.com
Wed Apr 23 16:06:27 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).

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
an HTTP / CIFS gateway where the stateless nature of HTTP causes many
separate threads to independently access the same resource.

The fix is largely an issue of time and money and so far none of the
sponsors have asked me to fix it so ... life goes on.


On Wed, 23 Apr 2008 13:16:45 +0200
Ronny Schuetz <Usenet.r96 at gishpuppy.com> wrote:

> Hi,
> I ran into several deadlock issues some time ago and the only solution 
> was to add one more lock object to the library to avoid deadlock 
> situations by synchronizing on this object first. This change has been 
> incorporated into the official library version later, but IIRC before 
> 1.2.13.
> However, looks like I missed some places ... You could try to change
>   SmbTransport#getSmbSession(NtlmPasswordAuthentication)
> in the following way: Remove the synchronized method modifier of the 
> method and enclose the original body of the method into
>       synchronized(setupDiscoLock) {
>       synchronized(this) {
>       [... original body ...]
>       }}
> Removing the synchronized method modifier from
>   SmbTransport#getSmbSession()
> might be a good idea as well.
> However, this is entirely untested. If you can somehow reproduce the 
> issue, you could try to test if this change fixes the bug.
> Best regards,
> Ronny

Michael B Allen
PHP Active Directory SPNEGO SSO

More information about the jcifs mailing list