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

[Paul Gutenbrunner]

it seems that the new jar solves the problem (no errsrv/90 for 3 workdays).

thanks

paul

> -----Ursprungliche Nachricht-----
> Von: Allen, Michael B (RSCH) [mailto:michael_b_allen at ml.com]
> Gesendet: Dienstag, 26. August 2003 04:07
> An: 'Paul Gutenbrunner'
> Cc: jcifs at lists.samba.org
> Betreff: RE: [jcifs] jcifs.smb.SmbException: No description
> available[ERRS RV/90] - 15 Minutes per day
>
>
> 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
>