AW: [jcifs] Starvation of threads while accessing files and direc tories with jcifs

[Marro, Donato]

I checked the jcifs-jar and it is even 1.1.9.

examples/ListDC.java can't be run because of an incorrect
class-name (the class is named CheckAllDC). Instead I will
try to run examples/CheckAllDC on the test-environment (at
the moment I have no access to it).

In the example there is a query over a specific domain,
but in my application I don't go over a speific domain,
I directly create the UniAdresses with the name
of the server my files or directories belong to, like:

String servername = extractServerNameFromFileName(filename);
dc = UniAddress.getByName(servername, true);
challenge = SmbSession.getChallenge(dc);
ntlm = AUTH.doAuthentication(request, response, challenge);

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?

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 Object.wait()
[431f000..431fd90]
	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)


Greetings,
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:

> Hello,
> 
> 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 for
> 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.