[jcifs] Re: AW: Starvation of threads while accessing files and directories with jcifs

[Michael B Allen]

On Mon, 2 May 2005 16:26:46 +0000 (UTC)
Donato Marro <marro at e-spirit.de> wrote:

> Michael B Allen <mba2000 <at> ioplex.com> writes:
> 
> > The question is - is the first thread legitimately waiting for a
> > response that simply will never come or is this some kind of concurrency
> > error like the one we fixed in 1.1.8? It's not easy to tell. My
> > understanding is that if everything is properly synchronized the
> > negotiation should timeout after a short time.
> 
> To ensure a timeout of the negotiation wouldn't it be expedient to call
> the wait()-method (SmbTransport.java, line 931) with some timeout
> parameter?

No because negotiate0 just calls start() to get the transport thread
to do the work of connecting so it's within send() that we want to
timeout. Actually I'm not sure about the code paths off the top of my
head. I have rewritten the transport layer in my branch because it's
too complicated. Hopefully I'll reach a stable snapshot that I can put
in the download area. We'll see.

> 
> > Another thing you could try is to reduce the number of threads you're
> > running. It's horribly inefficient to run hundreds of threads and the
> > stress of so many different threads calling into the library at once
> > could be a prerequisite for triggering a concurrency error.
> 
> It seems as it is indeed a concurrency error because running the
> application in a single-threaded modus works fine.

So can you run with fewer threads? At least until the new brach
stablizes? In all my experience with jCIFS I have never found that using
more than a handful of threads (e.g. 5) actually improves proformance
or anything else. It seems running dozens of threads is not good w/
jCIFS (although I have done so many times testing and never managed to
reproduce a problem).

Mike

-- 
IRC - where men are men, women are men, and the boys are FBI agents.