<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 03/23/2010 03:44 PM, Michael B Allen wrote:
<blockquote
 cite="mid:78c6bd861003231244v4e989191jbc4e343cd44832df@mail.gmail.com"
 type="cite">
  <pre wrap="">On Tue, Mar 23, 2010 at 2:23 PM, Del Merritt <a class="moz-txt-link-rfc2396E" href="mailto:del@alum.mit.edu">&lt;del@alum.mit.edu&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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. &nbsp;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.
    </pre>
  </blockquote>
  <pre wrap="">
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.
  </pre>
</blockquote>
<br>
Hey Mike -<br>
<br>
Transport threads left running is the problem.&nbsp; In my local copy I have
added:<br>
<blockquote><tt>if (in != null)</tt><br>
  <tt>&nbsp;&nbsp;&nbsp; in.close();</tt><br>
</blockquote>
after the comparable close() for out.&nbsp; Closing the InputStream has the
nice(?) affect of forcing the response thread to handle the
stream-closed exception and exit.<br>
<br>
<br>
<blockquote
 cite="mid:78c6bd861003231244v4e989191jbc4e343cd44832df@mail.gmail.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">This is a problem in a J2ME environment, where thread resources can be
limited.
    </pre>
  </blockquote>
  <pre wrap="">
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.
  </pre>
</blockquote>
<br>
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.&nbsp; This is why I cobbled in my
in.close().&nbsp; I don't like it, since it means I can't close() before I
think I'm done reading.&nbsp; (In my specific instance, this is not a
problem, which is why I can live with it.)<br>
<br>
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.&nbsp; I'm just pointing out that on resource-limited platforms, the
current 1.3.14 behavior allows no reliable control of the thread
resource.&nbsp; The presence of SSN_LIMIT (and DEFAULT_SSN_LIMIT) is a red
herring, since it doesn't really limit sessions in the CONNECTIONS list.<br>
<br>
-Del<br>
</body>
</html>