Hi Michael,<br><br>I tested again, and I agree the SmbTransport is reused and no other sockets are created. The problem seem to be rather with the SmbSession.<br><br>The logoff() call I meant is in the SmbSession.send() method, line 268 (version 1.3.15). It is called just in the case when the share name is incorrect. So, when you do treeConnect(), on line 162 a call is made to session.send(). Then there is a call to the SmbSession.sessionSetup method. In this method, line 385, we send some request, which purpose is not very clear to me. So the first time, we go through those calls, and since the share name is wrong, we go here (the SmbSession.send()) :<br>
<br> try {<br> transport.send( request, response );<br> } catch (SmbException se) {<br> if (request instanceof SmbComTreeConnectAndX) {<br> logoff(true);<br> }<br>
request.digest = null;<br> throw se;<br> }<br><br><br>We go here in the catch, and logoff is called. As a result, the flag sessionSetup is set to false in the logoff method. On the next time, the whole cycle repeats, and the check in the SmbSession.sessionSetup() for the flag sessionSetup fails and the whole session setup is done again. <br>
<br>So I rarther think this continous session setup for the wrong share causes the free connections error message, because it is caught just in this method.<br><br>I also attach a very simple testing program - you have one thread, that connects to a share on a cycle of 1 second and just calls the exists() method. You can start also a second thread in parallel, which is for the same credentials, but for correct host. Actually, I managed to get the error with only a Single, wrongly configured thread. To run the application, just provide the correct host and user/pass and share name settings in the main method. <br>
<br>So please, take a look at this issue and please give advise - will it be correct to logoff the whole session in case of wrong share name?<br><br>Regards,<br>Gergan.<br><br><br><br><div class="gmail_quote">2011/2/25 Michael B Allen <span dir="ltr"><<a href="mailto:ioplex@gmail.com">ioplex@gmail.com</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;">On Wed, Feb 23, 2011 at 10:10 AM, Gergan Dimitrov<br>
<div class="im"><<a href="mailto:gergan.dimitrov@gmail.com">gergan.dimitrov@gmail.com</a>> wrote:<br>
</div><div class="im">> Hi Michael,<br>
><br>
> unfortunately, I do have other listeners working correctly which connect to<br>
> the same host, with same credentials, but to correctly defined shares. In<br>
> this case, I have the problem described above - on each retry of the wrongly<br>
> 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<br>
> sure.<br>
><br>
> The main issue seems to be in the SmbTree.treeConnect method. We have<br>
> 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.<br>
<br>
</div>Hi Gergan,<br>
<br>
If you have other resources open with that transport, the same<br>
transport will be reused and therefore additional sockets should NOT<br>
be created. If they are, that is a bug which should be investigated<br>
and fixed.<br>
<br>
Note that the code is organized so that:<br>
<br>
SmbFiles share SmbTrees with the same share name<br>
SmbTrees share SmbSessions with the same credentials<br>
SmbSessions share SmbTransports with the same network address<br>
<div class="im"><br>
> We construct then<br>
> the request and response and call the session.send( request, response ); But<br>
> since the share name is wrong, this fails. As a result, the connectionState<br>
> is never changed to 2 (so, it is considered not connected), and the variable<br>
> 'tid' is not initialized. If we see what happens in the send() call, the<br>
> transport.send( request, response ); throws exception and we go in the catch<br>
> and call logoff(true).<br>
<br>
</div>There is no logoff() call in treeConnect. When the exception is<br>
caught, it calls treeDisconnect and sets connectionState back to 0. At<br>
least this is what is supposed to happen.<br>
<div class="im"><br>
> Then we go to the the treeDisconnect, the isError is<br>
> 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<br>
> disconnection message to the server.<br>
<br>
</div>That is correct. The tree connect never succeeded and therefore no<br>
disconnect message should be sent.<br>
<br>
In CIFS, to get a connection to a file (or share) you must first do a<br>
"tree connect" which first requires a "session setup" which first<br>
requires a regular socket. Each socket can have multiple sessions and<br>
each session can have multiple trees and each tree can have multiple<br>
files.<br>
<div class="im"><br>
> Besides, the isError is also true and<br>
> tid is 0, and thus none of the conditions to call the disconnect is met.<br>
> This Tree is practically never disconnected, because since other listeners<br>
> sharing the same SmbTransport still work, we cannot get read timeout<br>
> exception and the SmbTransport is never removed. This means the SmbTree is<br>
> always reused, and always does the frist connect and opens new sockets, that<br>
> are never closed.<br>
<br>
</div>Once the SmbTree object is created, it will remain associated with the<br>
SmbSession and reused. But when you do a treeConnect and it fails, the<br>
state should be reset back to 0. Because the existing socket is used,<br>
there should be no new sockets created and because the connectionState<br>
should always be reset back to 0 on failure, trying to call<br>
treeConnect again should go through submitting the<br>
SmbComTreeConnectAndX message again. At least this is what is supposed<br>
to happen.<br>
<div class="im"><br>
><br>
> So Michael, please tell me<br>
> 1) can you verify this is really the problem. I am still not sure if the<br>
> upper explains why those connections seem never to close, while there are<br>
> other running connections to the server.<br>
<br>
</div>No. But if you are actually finding that new sockets are being created<br>
when treeConnect is called on an existing transport that already has<br>
an open socket, that is an error that should be fixed. But you will<br>
need to provide evidence that there are multiple sockets being created<br>
in this scenario.<br>
<br>
Create a minimalistic test program that opens a file on a good share<br>
and then have it try to open a file on a non-existant share 10 times<br>
(with try / catch inside the loop of course). Then post the code and a<br>
backtrace to show that multiple threads blocked trying to create<br>
sockets or whatever it is that is being created that you think JCIFS<br>
should not be creating.<br>
<div class="im"><br>
> 2) what can be the possible solution here. I am not familiar with the<br>
> purpose of this SmbComTreeConnectAndX and why it has to be called before we<br>
> set the state to connected? Also, why not try to disconnect if isError is<br>
> true on this request? What could be the impact if those checks are removed<br>
> from the disconnect method?<br>
<br>
</div>I think I answered this above.<br>
<br>
Mike<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Michael B Allen<br>
Java Active Directory Integration<br>
<a href="http://www.ioplex.com/" target="_blank">http://www.ioplex.com/</a><br>
<br>
<br>
<br>
> 2011/2/23 Mohan Radhakrishnan <<a href="mailto:mohanr@fss.co.in">mohanr@fss.co.in</a>><br>
>><br>
>> Hi,<br>
>><br>
>> Does it mean that we should not use SmbSession.logon even using the<br>
>> latest JCIFS JAR ?<br>
>><br>
>><br>
>> Thanks,<br>
>> Mohan<br>
>><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>]<br>
>> 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<br>
>> > the<br>
>> > directory to listen, both with same user credentials. But if the share<br>
>> > name<br>
>> > is invalid, after a short period I get run out of free connections to<br>
>> > the<br>
>> > server. Since the server ip and credentials are correct, the logon<br>
>> > method<br>
>> > succeeds. Then the exists() method throws exception. It seems that on<br>
>> > each<br>
>> > next logon, more connections are created, while the old are not closed.<br>
>> > Of<br>
>> > course, I could not use the logon method each time, but even if I call<br>
>> > it<br>
>> > from other application for the same credentials, I get the same result.<br>
>> > If I<br>
>> > skip the logon part, the problem does not appear, but as I said - it<br>
>> > could<br>
>> > be called from other application. Please, tell if you have any idea why<br>
>> > the<br>
>> > wrong share causes such behaviour.<br>
>> ><br>
>> > The problem can be very easily simulated, but if you need any stack<br>
>> > 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<br>
>> > 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<br>
>> > file<br>
>> > creation. I tried also with setting port 445 for the logon, but the<br>
>> > 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<br>
>> > cannot<br>
>> > be found, the flag treeConnected on the SmbTree objects remains to<br>
>> > 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>
><br>
><br>
</div></div></blockquote></div><br>