[jcifs] jcifs.dcerpc.DcerpcPipeHandle: when close() doesn't

[Del Merritt]

On 03/23/2010 03:44 PM, Michael B Allen wrote:
> On Tue, Mar 23, 2010 at 2:23 PM, Del Merritt <del at alum.mit.edu> wrote:
>   
>> In the 1.3.14 version of jcifs.dcerpc.DcerpcHandle's close() method the
>> SmbFileOutputStream "out" is closed but the corresponding
>> SmbFileInputStream "in" is not.  In practice this seems to mean there is
>> no way to guarantee the SmbTransport thread(s) created to handle
>> response data will be closed in a timely manner.
>>     
> Hi Del,
>
> Actually those close methods do not really have any effect on the
> SmbTransport threads. Transport threads are just left running until
> the socket is idle for a while.
>   

Hey Mike -

Transport threads left running is the problem.  In my local copy I have
added:

    if (in != null)
        in.close();

after the comparable close() for out.  Closing the InputStream has the
nice(?) affect of forcing the response thread to handle the
stream-closed exception and exit.


>> This is a problem in a J2ME environment, where thread resources can be
>> limited.
>>     
> You can decrease jcifs.smb.client.soTimeout (the default is 35000
> milliseconds). This will cause transport threads to exit more quickly.
> But you have to adjust jcifs.smb.client.responseTimeout to be less
> accordingly so as not to stop listening before a response has be
> received.
>   

The problem remains that if I want to, say, query multiple hosts in the
current implementation, I can pile up threads that will "linger" and
there is no way to directly control that.  This is why I cobbled in my
in.close().  I don't like it, since it means I can't close() before I
think I'm done reading.  (In my specific instance, this is not a
problem, which is why I can live with it.)

Since I am not sure how best to feed back some of the changes - mostly
to work around classes that are missing in J2ME - it may be a moot
point.  I'm just pointing out that on resource-limited platforms, the
current 1.3.14 behavior allows no reliable control of the thread
resource.  The presence of SSN_LIMIT (and DEFAULT_SSN_LIMIT) is a red
herring, since it doesn't really limit sessions in the CONNECTIONS list.

-Del
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/jcifs/attachments/20100323/58c13e20/attachment.html>