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

[Michael B Allen]

On Wed, 23 Apr 2008 18:20:52 +0200
Ronny Schuetz <Usenet.r96 at gishpuppy.com> wrote:

>  > 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.

Sure, in theory it can happen with fewer threads. Just as it can with
your extra locks. It just doesn't seem to happen in practice.

Incedentally, if you look at the throughput of pulling files from the
same server with 10 threads vs 2 or 3 I think you'll find there's no
difference. Or, if there is a difference I would not be surprised to
find that 10 threads is actually slower than using 2 or 3.

Multiplexing is a feature of JCIFS. Right now, if you push it, it
will break.

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/