[jcifs] SmbTransport.java

[Dan Dumont]

Ok well...  forgive me but I am having a hard time understanding this.  This
is a snip from the api documentation.

maxMpxCount property.

This client can send and receive messages concurrently over the same socket.
The number of simultaneous outstanding transactions with a given server is
controlled by this property. The default is 10. Under extremely unlikely
circumstances this value may need to be adjusted to achieve optimal
throughput. It is more likely this property would be set to 1 to support a
deficient server.

Now why, is this property responsible for the blocking of threads that are
talking to another server completely?  


-----Original Message-----
From: jcifs-bounces+dan=canofsleep.com at lists.samba.org
[mailto:jcifs-bounces+dan=canofsleep.com at lists.samba.org] On Behalf Of
Michael B.Allen
Sent: Wednesday, April 16, 2003 7:24 PM
To: Dan Dumont
Cc: jcifs at lists.samba.org
Subject: Re: [jcifs] SmbTransport.java

On Wed, 16 Apr 2003 15:42:40 -0400
"Dan Dumont" <Dan at canofsleep.com> wrote:

> On line 233:
> do {
>    try {
>        socket = new NbtSocket( naddr, calledName, port, localAddr,
localPort
> );
>        break;
>    }  
>    catch( NbtException ne ) {
>             if( ne.errorClass == NbtException.ERR_SSN_SRVC &&
>                                 ( ne.errorCode ==
> NbtException.CALLED_NOT_PRESENT ||
>                                 ne.errorCode ==
> NbtException.NOT_LISTENING_CALLED )) {
>                         Log.println( Log.WARNINGS, "smb warning",
> ne.getMessage() );
>             }    
>             else {
>                throw ne;
>             }
>     }
> } while(( calledName = address.nextCalledName()) != null );
> 
> I am noticing that when a try certain hosts, it catches a NbtException and
> the error class is ERRSSN_SRVC && NOT_LISTING_CALLED  so, it matches the
if,
> prints to the log, and trys again!!!!
>
> Why are you trying again if it's not listing on called name?!

Tries again with nextCalledName().

> This relates to my previous message.  The other threads are caught up in
an
> aquire mid
> And this thread marches through this infinite loop.  Never releasing
> decrementing mpxCount.

It should after 1min 15seconds.

Mike