Hi Michael,<br><br>unfortunately, I do have other listeners working correctly which connect to the same host, with same credentials, but to correctly defined shares. In this case, I have the problem described above - on each retry of the wrongly configured one, I get one more connection to the server.<br>
<br>I did further investigation and I think I found the problem, but I am not sure.<br><br>The main issue seems to be in the SmbTree.treeConnect method. We have correct host, and correct user/password. This line succeeds:<br>
<br>session.transport.connect();<br><br>At this point, we have a socket open to the remote host. We construct then the request and response and call the session.send( request, response ); But since the share name is wrong, this fails. As a result, the connectionState is never changed to 2 (so, it is considered not connected), and the variable 'tid' is not initialized. If we see what happens in the send() call, the transport.send( request, response ); throws exception and we go in the catch and call logoff(true). Then we go to the the treeDisconnect, the isError is true. But in the treeDisconnect(), we have<br>
if (connectionState != 2) // not-connected<br> return;<br><br>But here the connectionState is not 2, and we actually do not send a disconnection message to the server. Besides, the isError is also true and tid is 0, and thus none of the conditions to call the disconnect is met. This Tree is practically never disconnected, because since other listeners sharing the same SmbTransport still work, we cannot get read timeout exception and the SmbTransport is never removed. This means the SmbTree is always reused, and always does the frist connect and opens new sockets, that are never closed.<br>
<br>So Michael, please tell me<br>1) can you verify this is really the problem. I am still not sure if the upper explains why those connections seem never to close, while there are other running connections to the server.<br>
2) what can be the possible solution here. I am not familiar with the purpose of this SmbComTreeConnectAndX and why it has to be called before we set the state to connected? Also, why not try to disconnect if isError is true on this request? What could be the impact if those checks are removed from the disconnect method?<br>
<br>Any help will be much appreciated.<br><br>Regards,<br>Gergan.<br><br><div class="gmail_quote">2011/2/23 Mohan Radhakrishnan <span dir="ltr"><<a href="mailto:mohanr@fss.co.in">mohanr@fss.co.in</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
Does it mean that we should not use SmbSession.logon even using the latest JCIFS JAR ?<br>
<br>
<br>
Thanks,<br>
<font color="#888888">Mohan<br>
</font><div><div></div><div class="h5"><br>
-----Original Message-----<br>
From: <a href="mailto:jcifs-bounces@lists.samba.org">jcifs-bounces@lists.samba.org</a> [mailto:<a href="mailto:jcifs-bounces@lists.samba.org">jcifs-bounces@lists.samba.org</a>] On Behalf Of Michael B Allen<br>
Sent: Wednesday, February 23, 2011 2:35 AM<br>
To: Gergan Dimitrov<br>
Cc: <a href="mailto:jcifs@lists.samba.org">jcifs@lists.samba.org</a>; <a href="mailto:s.sourkov@bg.seeburger.com">s.sourkov@bg.seeburger.com</a><br>
Subject: Re: [jcifs] Invalid share causes all free connections consumption<br>
<br>
Hi Gergan,<br>
<br>
The SmbSession.logon method is flawed and should no longer be used.<br>
Just do something like (new SmbFile(smb://<a href="http://1.2.3.4/IPC$" target="_blank">1.2.3.4/IPC$</a>")).exists().<br>
<br>
But if nothing is listening on the other end it will take a while for<br>
the socket to timeout. Lowering the jcifs.smb.client.soTimeout might<br>
help with this but you cannot completely eliminate these waiting<br>
threads. It just takes time for the OS to report the SYN packet has<br>
failed.<br>
<br>
Just add logic to slow down the frequency of your attempts. And you<br>
should only use one thread per server. So have one thread try and if<br>
it times out, wait 30 seconds before trying again. If it fails again,<br>
wait 60 seconds, 120, 240 etc to some maximum like 10 minutes. I think<br>
a SYN packet failure takes at most about 90 seconds to timeout so as<br>
long as you wait more than that you should not have a net surplus of<br>
transport threads waiting.<br>
<br>
Mike<br>
<br>
On Mon, Feb 21, 2011 at 11:08 AM, Gergan Dimitrov<br>
<<a href="mailto:gergan.dimitrov@gmail.com">gergan.dimitrov@gmail.com</a>> wrote:<br>
> Hi All,<br>
><br>
> I have an windows share listener, which listens for new files on Windows<br>
> share on 1 second interval. I first try to connect to the server with<br>
> SmbSession.logon method and then call the SmbFile.exists() method for the<br>
> directory to listen, both with same user credentials. But if the share name<br>
> is invalid, after a short period I get run out of free connections to the<br>
> server. Since the server ip and credentials are correct, the logon method<br>
> succeeds. Then the exists() method throws exception. It seems that on each<br>
> next logon, more connections are created, while the old are not closed. Of<br>
> course, I could not use the logon method each time, but even if I call it<br>
> from other application for the same credentials, I get the same result. If I<br>
> skip the logon part, the problem does not appear, but as I said - it could<br>
> be called from other application. Please, tell if you have any idea why the<br>
> wrong share causes such behaviour.<br>
><br>
> The problem can be very easily simulated, but if you need any stack traces<br>
> or thread dumps, please say so. You can see the growing number of IPC$<br>
> connections from the computer management/ system tools/ shared<br>
> folders/shares tool in Windows. I must add some things:<br>
><br>
> 1) When the logon succeeds, the SmbTransport created for it is for port 0,<br>
> while the SmbFile is for port 445, and so at leas two connections are<br>
> firstly created. Port was not provided for the logon method, or the smb file<br>
> creation. I tried also with setting port 445 for the logon, but the result<br>
> was the same<br>
> 2) I could not see more than two SmbTransport objects in the CONNECTIONS<br>
> collection.<br>
> 3) when the connection from the SmbFile is successful, but the share cannot<br>
> be found, the flag treeConnected on the SmbTree objects remains to false.<br>
><br>
> Thank you in advance,<br>
> Gergan.<br>
><br>
<br>
<br>
<br>
--<br>
Michael B Allen<br>
Java Active Directory Integration<br>
<a href="http://www.ioplex.com/" target="_blank">http://www.ioplex.com/</a><br>
</div></div></blockquote></div><br>