[jcifs] Invalid share causes all free connections consumption

Mohan Radhakrishnan mohanr at fss.co.in
Tue Feb 22 23:27:15 MST 2011


Hi,

     Does it mean that we should not use SmbSession.logon even using the latest JCIFS JAR ?


Thanks,
Mohan

-----Original Message-----
From: jcifs-bounces at lists.samba.org [mailto:jcifs-bounces at lists.samba.org] On Behalf Of Michael B Allen
Sent: Wednesday, February 23, 2011 2:35 AM
To: Gergan Dimitrov
Cc: jcifs at lists.samba.org; s.sourkov at bg.seeburger.com
Subject: Re: [jcifs] Invalid share causes all free connections consumption

Hi Gergan,

The SmbSession.logon method is flawed and should no longer be used.
Just do something like (new SmbFile(smb://1.2.3.4/IPC$")).exists().

But if nothing is listening on the other end it will take a while for
the socket to timeout. Lowering the jcifs.smb.client.soTimeout might
help with this but you cannot completely eliminate these waiting
threads. It just takes time for the OS to report the SYN packet has
failed.

Just add logic to slow down the frequency of your attempts. And you
should only use one thread per server. So have one thread try and if
it times out, wait 30 seconds before trying again. If it fails again,
wait 60 seconds, 120, 240 etc to some maximum like 10 minutes. I think
a SYN packet failure takes at most about 90 seconds to timeout so as
long as you wait more than that you should not have a net surplus of
transport threads waiting.

Mike

On Mon, Feb 21, 2011 at 11:08 AM, Gergan Dimitrov
<gergan.dimitrov at gmail.com> wrote:
> Hi All,
>
> I have an windows share listener, which listens for new files on Windows
> share on 1 second interval. I first try to connect to the server with
> SmbSession.logon method and then call the SmbFile.exists() method for the
> directory to listen, both with same user credentials. But if the share name
> is invalid, after a short period I get run out of free connections to the
> server. Since the server ip and credentials are correct, the logon method
> succeeds. Then the exists() method throws exception. It seems that on each
> next logon, more connections are created, while the old are not closed. Of
> course, I could not use the logon method each time, but even if I call it
> from other application for the same credentials, I get the same result. If I
> skip the logon part, the problem does not appear, but as I said - it could
> be called from other application. Please, tell if you have any idea why the
> wrong share causes such behaviour.
>
> The problem can be very easily simulated, but if you need any stack traces
> or thread dumps, please say so. You can see the growing number of IPC$
> connections from the  computer management/ system tools/ shared
> folders/shares tool in Windows. I must add some things:
>
> 1) When the logon succeeds, the SmbTransport created for it is for port 0,
> while the SmbFile is for port 445, and so at leas two connections are
> firstly created. Port was not provided for the logon method, or the smb file
> creation. I tried also with setting port 445 for the logon, but the result
> was the same
> 2) I could not see more than two SmbTransport objects in the CONNECTIONS
> collection.
> 3) when the connection from the SmbFile is successful, but the share cannot
> be found, the flag treeConnected on the SmbTree objects remains to false.
>
> Thank you in advance,
> Gergan.
>



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


More information about the jCIFS mailing list