jcifs-1.2.5 fails on bad domain controller; does not try others

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

jcifs-1.2.5 fails on bad domain controller; does not try others

Oliver Schoett
In message <[hidden email]> dated Tue, 15
Mar 2005 13:37:39 -0500, Michael B Allen writes:
> CIFS should handle this automatically. When jcifs rotates to a new
> DC it tries to negotiate with it to see if it's "good". If it isn't it
> removes it from the list. This process should not "hang".
However, the 1.2.5 NtlmHttpFilter still fails when the first DC in the
list returned from WINS is bad (stack trace at the end). Apparently, it
does *not* proceed to the other DCs in the list, as suggested above.

We have a customer that wants resilience against a DC failure.  How can
I provide that to him using jcifs?

Regards,

Oliver Schoett


java.net.SocketTimeoutException: Receive timed out
        at java.net.PlainDatagramSocketImpl.receive(Native Method)
        at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:129)
        at java.net.DatagramSocket.receive(DatagramSocket.java:701)
        at jcifs.netbios.NameServiceClient.run(NameServiceClient.java:184)
        at java.lang.Thread.run(Thread.java:568)
Failed validate DC: ******<1C>/***.***.197.200
jcifs.smb.SmbException:
jcifs.util.transport.TransportException: Connection timeout
        at jcifs.util.transport.Transport.connect(Transport.java:174)
        at jcifs.smb.SmbTransport.connect(SmbTransport.java:270)
        at jcifs.smb.SmbSession.interrogate(SmbSession.java:74)
        at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:111)
        at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150)
        at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114)
        at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:604)
        at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317)
        at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
        at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:208)
        at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:125)
        at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
        at java.lang.Thread.run(Thread.java:568)

        at jcifs.smb.SmbTransport.connect(SmbTransport.java:272)
        at jcifs.smb.SmbSession.interrogate(SmbSession.java:74)
        at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:111)
        at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150)
        at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114)
        at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:604)
        at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317)
        at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
        at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:208)
        at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:125)
        at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
        at java.lang.Thread.run(Thread.java:568)
05/12/30 10:45:48 java.net.SocketException: Connection timed out:could be due to invalid address
05/12/30 10:45:48 at java.net.PlainSocketImpl.socketConnect(Native Method)
05/12/30 10:45:48 at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:329)
05/12/30 10:45:48 at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:194)
05/12/30 10:45:48 at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:181)
05/12/30 10:45:48 at java.net.Socket.connect(Socket.java:459)
05/12/30 10:45:48 at java.net.Socket.connect(Socket.java:409)
05/12/30 10:45:48 at java.net.Socket.<init>(Socket.java:315)
05/12/30 10:45:48 at java.net.Socket.<init>(Socket.java:143)
05/12/30 10:45:48 at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:240)
05/12/30 10:45:48 at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:282)
05/12/30 10:45:48 at jcifs.util.transport.Transport.run(Transport.java:214)
05/12/30 10:45:48 at java.lang.Thread.run(Thread.java:568)




Reply | Threaded
Open this post in threaded view
|

Re: jcifs-1.2.5 fails on bad domain controller; does not try others

Oliver Schoett
Oliver Schoett wrote:
> In message <[hidden email]> dated Tue, 15
> Mar 2005 13:37:39 -0500, Michael B Allen writes:
>> CIFS should handle this automatically. When jcifs rotates to a new
>> DC it tries to negotiate with it to see if it's "good". If it isn't it
>> removes it from the list. This process should not "hang".
> However, the 1.2.5 NtlmHttpFilter still fails when the first DC in the
> list returned from WINS is bad (stack trace at the end). Apparently,
> it does *not* proceed to the other DCs in the list, as suggested above.
I should add that the error message in the browser (talking to an OC4J
server with jcifs 1.2.5) is the following:

500 Internal Server Error
500 Internal Server Error
java.net.UnknownHostException: Failed to negotiate with a suitable domain controller for ******
 at jcifs.smb.SmbSession.getChallengeForDomain(SmbSession.java:126)
 at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:150)
 at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114)
 at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:604)
 at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317)
 at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
 at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.AJPRequestHandler.run(AJPRequestHandler.java:208)
 at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.AJPRequestHandler.run(AJPRequestHandler.java:125)
 at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
 at java.lang.Thread.run(Thread.java:568)


Regards,

Oliver Schoett

Reply | Threaded
Open this post in threaded view
|

SOLVED: jcifs-1.2.5 fails on bad domain controller; does not try others

Oliver Schoett
Oliver Schoett wrote:

> Oliver Schoett wrote:
>> In message <[hidden email]> dated Tue, 15
>> Mar 2005 13:37:39 -0500, Michael B Allen writes:
>>> CIFS should handle this automatically. When jcifs rotates to a new
>>> DC it tries to negotiate with it to see if it's "good". If it isn't it
>>> removes it from the list. This process should not "hang".
>> However, the 1.2.5 NtlmHttpFilter still fails when the first DC in
>> the list returned from WINS is bad (stack trace at the end).
>> Apparently, it does *not* proceed to the other DCs in the list, as
>> suggested above.
> I should add that the error message in the browser (talking to an OC4J
> server with jcifs 1.2.5) is the following:
>
> 500 Internal Server Error
> 500 Internal Server Error
> java.net.UnknownHostException: Failed to negotiate with a suitable
> domain controller for ******
Sorry, the customer configuration had the setting

    jcifs.netbios.lookupRespLimit=1

This means that only the first entry in the DC list is tried and
precisely explains the observed behaviour; there is no problem.

Regards,

Oliver Schoett