[jcifs] jcifs.dcerpc.DcerpcPipeHandle: when close() doesn't
Del Merritt
del at alum.mit.edu
Tue Mar 23 14:01:47 MDT 2010
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>
More information about the jCIFS
mailing list