[jcifs] Why logoff after failed SmbComTreeConnectAndX?

[Shon Vella]

I’ve been chasing a couple of issues for several days now and finally tracked both of them down to a couple of lines in the exception handler for SmbSession.send():

            if (request instanceof SmbComTreeConnectAndX) {
                logoff(true);
            }

in my case, the SmbComTreeConnectAndX is failing because the share doesn’t exist, in which case the logoff() seems extreme. The logoff does a tree disconnect on all the trees associated with the session, which in turn closes any open files, including named pipes. The initial issue I was trying to track down was named pipe that was being used in another thread that was randomly getting closed prematurely.

The second issue I was trying to track down was sudden spikes in the number of sessions open on the server. I was finally able to duplicate the spikes with a little loop like this:

        SmbFile badShare = null;
        try {
            badShare = new SmbFile("smb://MYSERVER/BOGUS", new NtlmPasswordAuthentication(“MYDOMAIN", "Administrator", “mypassword"));
            for (int i = 0; i < 1000; i++) {
                try {
                    System.err.println(i);
                    badShare.exists();
                } catch (SmbException e) {
                }
            }
        } catch (MalformedURLException e) {
        }

Which will very quickly cause 1000 sessions to be opened on the server and will cause many other operations to fail with SMB Error 0xC0000205 (STATUS_INSUFF_SERVER_RESOURCES)

I’m not sure why doing the logout on failure of SmbComTreeConnectAndX leaks connections, but by commenting it out, the session count remains steady at 1 from the client machine.

So the big question is why/when would a logoff() be the right thing to do? What is going to break of I remove it completely? Are there specific error codes that would be a good indication that the logoff() is really necessary?


Shon Vella
Developer
iDENTiTYAUTOMATiON
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/jcifs/attachments/20131203/27133651/attachment.html>