[jcifs] jcifs.smb.SmbException: No description available[ERRS RV/90] - 15 Minutes per day

[Allen, Michael B (RSCH)]

Paul,

I have prepared a modified jar. Please try this:

    http://users.erols.com/mballen/jcifs/jcifs-0.7.11ssnlim.jar

This distribution accepts an additional property jcifs.smb.client.ssnLimit
which by default is 100. The change was simple; when a session is
requested the existing sessions are examined to determine if one
matches the required credentials. If not, a new session is
created and added to the list. So what I did was to just add a limit to the
number of sessions that can be created. If the session limit is
reached 1/10th of the oldest sessions are logged off. As a test you might
set this value low (e.g. 20) to really provoke the affected code.

    synchronized SmbSession getSmbSession( NtlmPasswordAuthentication auth ) {
        SmbSession ssn;

        ListIterator iter = sessions.listIterator();
        while( iter.hasNext() ) {
            ssn = (SmbSession)iter.next();
            if( ssn.matches( auth )) {
                ssn.auth = auth; 
                return ssn;
            }
        }
        ssn = new SmbSession( this, auth ); 
        sessions.add( ssn );

        if( sessions.size() > ssnLimit ) {
            int nclose = sessions.size() / 10;
            SmbSession s;

            while( nclose-- > 0 ) { 
                s = (SmbSession)sessions.removeFirst();
                s.logoff( false );
            }       
        }

        return ssn;
    }

See more comments below....

> -----Original Message-----
> From:	Paul Gutenbrunner [SMTP:pagu at pagu.at]
> Sent:	Monday, August 25, 2003 7:49 PM
> To:	Allen, Michael B (RSCH)
> Cc:	jcifs at lists.samba.org
> Subject:	AW: [jcifs] jcifs.smb.SmbException: No description available[ERRS RV/90] - 15 Minutes per day
> 
> > 	Hundreds of thousands! Are you sure the 
> > NtlmPasswordAuthentication object is
> > 	being cached in the HttpSession? Or are you using HTTP POST?
> > 
> 
> we are using GET. to mimimize the number of smb-logons, we made 
> a subclass of the filter which checks if if the user's session
> has already been authenticated. if not, the authentication takes place 
> (call the filter-method of the superclass), else nothing happens. 
> 
	This is strange. If you're really caching NPAs you would have to have
	hundreds of thousands of distinct users. The NtlmHttpFilter already
	checks the HttpSession for the NPA. Perhaps what you're doing is
	interferign with that behavior.

> > 	I'll look into a proper solution for this. Ideally I think 
> > the session to the domain
> > 	controller should just timeout after a certain period of 
> > time if the session has been
> > 	idle. 
> 
> but if the frequency of authentication requests is high,
> the smb-session will never be idle (depending on the period 
> of time). 
> 
	By session I mean the logon session. There can be many logon
	sessions multiplexing over a transport (in this case the domain
	controller). The theory is that the server is complaining about too
	many sessions open on the same transport. Currently the way
	sessions are cleaned up is when the *transport* is idle for
	jcifs.smb.client.soTimeout all the sessions and the transport are
	closed. If an HTTP client logs on before jcifs.smb.client.soTimeout
	this will never happen and thus the problem. But the sessions will be
	idle. SmbSessions (think user logon) are multiplexed over
	SmbTransports (think socket) just like SmbTrees (thing map network
	drive) are multiplexed over SmbSessions.

> > Disabling multiplexing over transport or explicitly 
> > closing transport periodically
> > 	is not the correct way to deal with the problem.
> > 
> 
> what about closing the transport if a configurable
> number of user-sessions has been reached?
> 
	That's it! Try the jar....

	Mike