AW: [jcifs] Starvation of threads while accessing files and
directories with jcifs
Michael B Allen
mba2000 at ioplex.com
Wed Apr 27 21:40:25 GMT 2005
Marro, Donato said:
> This code will be executed for several different servers on
> several different domains. It is possible that one of these
> servers is a bad domain controller, but shouldn't this be
> catched by the SmbTransport-class?
The thread dump below basically shows that one thread tries to negotiate
with the server and a whole bunch of other threads waiting for the first
one to complete.
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. If these same threads (e.g. tcpConnection-80-209)
persist indefinitely then it is probably a concurrency error. Or it could
be that if the server is accepting the socket connection but the server is
not responding to the negotiate() request that could expose some bad
behavior by the client. Add some debugging to determine the server with
which the client is try to negotiate and run simple example program on
that server to sanity test it. If it's hanging get a capture.
The synchronization in the transport layer is acknowledged to be too
complicated. There has been one report that I believe may actually
demonstrate a flaw although it was a somewhat eccentric application. I
believe your problem could be another example.
The transport layer has been rewritten in my current tree and I posted a
snapshot of it a while back. But it had a totally unrelated bug so I
yanked it from the download area. I'll probably do another 'trans' release
soon. You might want to try it.
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.
But also the problem could just be an unresponsive server.
> A new threaddump provides again the following result:
> 165 threads in the state:
> "tcpConnection-80-209" daemon prio=5 tid=0x03494b30 nid=0x142c waiting for
> monitor entry [ae3f000..ae3fd90]
> at jcifs.smb.SmbTransport.getSmbSession(SmbTransport.java:220)
> - waiting to lock <0x165a5ea8> (a jcifs.smb.SmbTransport)
> at jcifs.smb.SmbFile.connect(SmbFile.java:823)
> at jcifs.smb.SmbFile.connect0(SmbFile.java:797)
> at jcifs.smb.SmbFile.queryPath(SmbFile.java:1202)
> at jcifs.smb.SmbFile.exists(SmbFile.java:1285)
> Exactly one thread that locked the object <0x165a5ea8>:
> "tcpConnection-80-5" daemon prio=5 tid=0x02fe0a00 nid=0xb58 in
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:429)
> at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:931)
> - locked <0x13476da8> (a jcifs.smb.SmbTransport)
> at jcifs.smb.SmbTree.treeConnect(SmbTree.java:119)
> - locked <0x165a5ea8> (a jcifs.smb.SmbTransport)
> at jcifs.smb.SmbTree.send(SmbTree.java:81)
> at jcifs.smb.SmbFile.send(SmbFile.java:725)
> at jcifs.smb.SmbFile.close(SmbFile.java:896)
> at jcifs.smb.SmbFile.close(SmbFile.java:902)
> at jcifs.smb.SmbFile.close(SmbFile.java:906)
> at jcifs.smb.SmbFileInputStream.close(SmbFileInputStream.java:80)
> Donato Marro
> -----Ursprüngliche Nachricht-----
> Von: Michael B Allen [mailto:mba2000 at ioplex.com]
> Gesendet: Dienstag, 26. April 2005 19:58
> An: Marro, Donato
> Cc: jcifs at lists.samba.org
> Betreff: Re: [jcifs] Starvation of threads while accessing files and
> directories with jcifs
> There was a bug that was fixed in 1.1.8 that has this behavior. So either
> you're not really running 1.1.8 or you have a bad domain controller. What
> happends when you run examples/ListDC.java?
> On Tue, 26 Apr 2005 16:55:49 +0200
> "Marro, Donato" <marro at e-Spirit.de> wrote:
>> i have some problems while accessing files and directories
>> with jcifs in a multithreaded environment (running on Resin 2.1.13
>> with jcifs 1.1.8).
>> I've configured a maximum number of 200 possible threads.
>> But after some hours of operating with the application on
>> the file-system, more and more threads are blocked until there
>> are no more free threads to allocate and so there is no more
>> response from our webserver.
>> An extract from a threaddump looks like the following:
>> 170 threads in the state:
>> "tcpConnection-80-xxx" daemon prio=5 tid=0x04f7baa8 nid=0x1420 waiting
>> monitor entry [ae3f000..ae3fd90]
>> at jcifs.smb.SmbTransport.getSmbSession(SmbTransport.java:220)
>> - waiting to lock <0x17596610> (a jcifs.smb.SmbTransport)
>> at jcifs.smb.SmbFile.connect(SmbFile.java:823)
>> at jcifs.smb.SmbFile.connect0(SmbFile.java:797)
>> at jcifs.smb.SmbFile.queryPath(SmbFile.java:1202)
>> at jcifs.smb.SmbFile.exists(SmbFile.java:1285)
> IRC - where men are men, women are men, and the boys are FBI agents.
More information about the jcifs