Latest Maven artifact & thread problem

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Latest Maven artifact & thread problem

Samba - jcifs mailing list

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

 

Reply | Threaded
Open this post in threaded view
|

Re: Latest Maven artifact & thread problem

Samba - jcifs mailing list
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 <[hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|

Re: Latest Maven artifact & thread problem

Samba - jcifs mailing list
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:[hidden email]]
Gesendet: Mittwoch, 26. Juli 2017 01:06
An: Hohl, Gerrit
Cc: [hidden email]
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 <[hidden email]> 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/