[jcifs] Wrong SMB port leads to using all free connections

Michael B Allen ioplex at gmail.com
Thu Jan 20 10:41:00 MST 2011


Hi Gergan,

First, almost no one uses port 139 anymore so this is a very low
priority issue. You really should not specify a port at all. That
might even solve your issue because I believe the port will change
internally and then matches() will work as expected. It's only because
you supply the port explicitly that you have a problem.

Throwing an exception if 445 is blocked is obnoxious. I think silently
failing over to 139 is the only reasonable thing to do.

One possibility would be to allow the port to be retrieved from the
SmbFile. Then you could detect that the port changed and update your
parameters accordingly.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/


On Thu, Jan 20, 2011 at 7:25 AM, Gergan Dimitrov
<gergan.dimitrov at gmail.com> wrote:
> Hi all,
>
> I found a problem when using port different from the default 445. If the
> specified port is wrong, and the actual server accepts connections on the
> default 445 port, due to this code:
>
> try {
>       negotiate( port, resp );
> } catch( ConnectException ce )  {
>       port = (port == 0 || port == DEFAULT_PORT) ? 139 : DEFAULT_PORT;
>       negotiate( port, resp );
> }
>
> the connection is successful and the fact the port is wrong is hidden from
> the user. But since the port is changed to the default, and the user is not
> aware, when later other operation is performed on smb file configured with
> the wrong port, the already opened session cannot be reused, since the
> 'matches' method on the SmbTransport class fails because of this: (port == 0
> || port == this.port). Port here is the wrong one, while this.port is
> actually the default. As a result, a new SmbTransport is created. Thus, on
> each file operation, a new transport is created and after a short time on
> extensive operations, we get run out of free connections.
>
> I think this silent port change is not correct - I prefer thwrowing the
> exception here, so that we know there is a problem. I suggest this to be
> fixed. Also, a configuration property can be added to modify this behaviour
> - to throw exception or not.
>
> Regards,
> Gergan.
>


More information about the jCIFS mailing list