[jcifs] NtlmHttpFilter ERRSRV/89

[Michael B Allen]

Scovetta, Michael V said:
> I posted this not too long ago, but I don't think I specified that it
> had to do with the NtlmHttpFilter--
> I'm getting this
> jcifs.smb.SmbException: No description available [ERRSRV/89]
>         at jcifs.smb.SmbTransport.send(SmbTransport.java:771)
>         at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:140)
>         at jcifs.smb.SmbSession.send(SmbSession.java:103)
>         at jcifs.smb.SmbTree.treeConnect(SmbTree.java:132)
>         at jcifs.smb.SmbSession.logon(SmbSession.java:56)
>         at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:130)

IIRC this was "no resources are available" or similar. That sounds like
the domain controller is just overloaded. How many concurrent users are
you managing on your site?

>         ...
>
> sporadically-- It only seems to occur when the load on the server is over
> 50 sessions-- still not very high. The filter seems to be fine for a
> while,

50 is really low. Is the machine sufficently powered?

There are a few properties of interest in your case:

jcifs.http.loadBalance - This property does not do anything if you set
jcifs.smb.client.domainController (as you have). For "load balancing" to
work you have to use only jcifs.smb.client.domain and jcifs.netbios.wins
to specify the domain by NAME so that querying WINS will return different
results thereby using different domain controllers. Do you have multiple
domain controllers?

jcifs.netbios.cachePolicy - Reducing this time will cause the client to
cycle through domain controller more quickly.

jcifs.smb.client.ssnLimit - Setting this value to a low value like 50 will
cause the client to close 20% of the oldest sessions when new sessions are
required so that the number never exceeds 50. Setting this value would
likely resolve your issue but on a high volume site it may cause other
problems such as frequently opening and closing sessions thereby making
the whole setup slow.




> then everyone gets this exception. If I pass them to another server, they
> don't get the exception, but the load is less on the other server.
>
>>From both, I'm using the same filter settings.
>
> I've tried this one first:
>  <filter>
>   <filter-name>NTLM HTTP Authentication Filter</filter-name>
>   <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
>   <init-param>
>     <param-name>jcifs.http.domainController</param-name>
>     <param-value>domain-controller-ip</param-value>
>   </init-param>
>   <init-param>
>     <param-name>jcifs.smb.client.domain</param-name>
>     <param-value>domain-name</param-value>
>   </init-param>

If you set domainController the domain property is ignored.

>   <init-param>
>     <param-name>jcifs.netbios.wins</param-name>
>     <param-value>wins-server-ip</param-value>
>   </init-param>
> </filter>
>
> I also tried replacing the domainController param
> by loadBalance (true), but that didn't help.

loadBalance is true by defailt.

> Could active-directory be an issue here? I'm not concerned
> about domain groups or the such-- I just want to verify that
> the user's name/pw is correct.
>
> If anyone can give me some insight, it'd be a big help.
> Thanks!

It sounds like your DC is underpowered or the session limits are set very
low. I would take a packet capture of the netbios query for your DC
against WINS and verify that multiple DCs are listed. Then verify that
jCIFS is cycling through them.

You might also try setting jcifs.netbios.lookupRespLimit to 1, 2, or
three. If that works, it would suggest that there is one domain controller
being returned by WINS that is under powered. One bad apple can spoil the
bunch. JCIFS doesn't currently have a way to determine what sort of load
any given DC can handle.

Just some ideas,
Mike