[jcifs] Latest Maven artifact & thread problem

g.hohl at aurenz.de g.hohl at aurenz.de
Wed Jul 26 07:23:34 UTC 2017


Hello Mike,

the funny thing is: In most of our installations it seems that the Broadcast Option is used as in almost all cases the DNS resolution doesn't work.
E.g. we had one installation yesterday and they didn't configure the DNS suffix for the DNS search in their Linux system.
And they configured the Windows Server only with its name, but not full-qualified.
So jCIFS used the Broadcast option all the time and it worked quiet well.
The only problem is really the hundreds of threads which are created.

As changing the resolve order only to DNS would cause trouble for many installations. I guess my only option is too branch jCIFS and overwrite the thread-using part, so it is possible to pass a thread-pool, a thread-factory or whatever, so the number of parallel threads can be limited somehow.

Thanks anyway. :) 

Regards,
Gerrit
-----Ursprüngliche Nachricht-----
Von: Michael B Allen [mailto:ioplex at gmail.com] 
Gesendet: Mittwoch, 26. Juli 2017 01:06
An: Hohl, Gerrit
Cc: jcifs at lists.samba.org
Betreff: Re: [jcifs] Latest Maven artifact & thread problem

Hi Gerrit,

That QueryThread business is only used when trying to do a NetBIOS server / workgroup lookup and the caller must wait() while the request is in flight so you must have many threads trying to call into UniAddress.getAllByName and the queries are simply failing (takes about 6 seconds by default).

Meaning it will only be triggered if the SMB URL is like "smb://something/" and it has to try to discover if that is a server or a workgroup. If jcifs.netbios.wins is not set correctly or if NetBIOS is in part or whole not available, that could cause timeouts and callers will backup.

Look at the log and see what's failing. Looks like basic name service lookup failure to me.

In practice I don't think the NetBIOS browser service can be relied on anymore so I'm not sure you will ever get it to work consistently.
Look at the jcifs.resolveOrder property on the Setting Client Properties page. Setting it to jcifs.resolveOrder=DNS would bypass NetBIOS completely of course. But if you know that "smb://something/"
is always a server you could try jcifs.resolveOrder=DNS,WINS.

But in practice you probably need to stick to DNS only.

Mike

On Tue, Jul 25, 2017 at 8:47 AM, Gerrit via jCIFS <jcifs at lists.samba.org> wrote:
> Hello everyone,
>
>
>
>
>
>
>
> I noticed that the homepage of jCIFS states that version 1.3.18 was 
> released in October 2014.
>
> But in the Maven Central Repository the most current version is 1.3.17 
> of March 2012.
>
> Any change that this will change in the future?
>
>
>
>
>
>
>
> I also faced an issue regarding the use / creation of threads within 
> the jCIFS library.
>
> From time to time I have more than 500 threads created by the library 
> also I don't access that many shares and files at once (only one-by-one).
>
> The stack trace of all of these threads looks like this:
>
>
>
> JCIFS-QueryThread: <MYDOMAIN>:
>
>                 java.lang.Object.wait(Native Method)
>
>                 java.lang.Object.wait(Object.java:502)
>
>
> jcifs.netbios.NbtAddress.checkLookupTable(NbtAddress.java:332)
>
>                 
> jcifs.netbios.NbtAddress.doNameQuery(NbtAddress.java:305)
>
>                 
> jcifs.netbios.NbtAddress.getByName(NbtAddress.java:422)
>
>                 jcifs.UniAddress$QueryThread.run(UniAddress.java:147)
>
>
>
> <MYDOMAIN> is of course a placeholder.
>
> Is it possible that a name lookup is done for every access (means 
> method
> call) of the jcifs.smv.SmbFile class?
>
> Or at least almost every access, like the #exist(), #delete(), 
> #isFile() methods.
>
> Is it possible to do an address caching so the?
>
> Or to define a thread pool, so I can limit the number of threads, 
> let's say to 20?
>
> Is it somehow possible to prevent the call of the methods which lead 
> to the creation of the threads?
>
>
>
>
>
>
>
> Regards,
>
> Gerrit
>
>



--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/


More information about the jCIFS mailing list