Re: jcifs.util.transport.TransportException when connection is killed on purpose.

--001a1141bd007cedbb051102b461
Content-Type: text/plain; charset=UTF-8

Marin,

copyTo() is a mess, and I've previously submitted two patches that address
a lot of the issues with it, though not sure if it addresses everything or
what you are seeing. See
https://lists.samba.org/archive/jcifs/2014-June/010165.html and
https://lists.samba.org/archive/jcifs/2013-October/010115.html. Also note
that there is a jcifs property jcifs.smb.client.ignoreCopyToException that
defaults to true, that is part of the equation, and I always set it to
false.

*Shon Vella*
*Identity Automation*
Product Engineer
281-220-0021 x2030 office
281-817-5579 fax
www.identityautomation.com

On Wed, Mar 11, 2015 at 1:24 AM, M. D. <[email protected]> wrote:

>  Hello,
>
> I have found a potential issue that is reproducable every time. Please
> share your thoughts on how that can or should be improved.
>
> Scenario is:
> 1. JCIFS client starts to write a file.
> 2. In the middle of writing, you kill the connection on client or server
> side (I do it using TCP View on client side but it should matter)
> 3. At that point, the jcifs writing thread is probably stuck in the
> wait(timeout) directive in the jcifs.util.Transport#sendrecv() method,
> waiting for a response to arrive.
> 4. The thread that reads the responses is now holding the transport lock
> and executing jcifs.util.transport.Transport#loop() but the doRecv(
> response ) invocation fails with exception "Connection reset by peer" since
> the connection is closed.
> 5. The exception is caught in the loop method and then the looping thread
> calls disconnect. The disconnect procedure calls logoff on the SmbSession
> and the connection state is then changed. The disconnect is then successful
> (as it should be) and then all threads waiting for the transport are
> notified by the looping thread.
> 6. The JCIFS client thread that initially was writing the file exits the
> wait(timeout) since it was notified by the loop thread. But since a
> response wasn't received, another wait(timeout) is issued. After 30 seconds
> (default) the writing threads throws
> jcifs.util.transport.TransportException exception.
>
> Could that be improved somehow? Since the session state is disconnected it
> isn't necessary that the writing thread wait for another 30 seconds and
> then fail with a timeout exception. Additionally, this "Connection reset by
> peer" exception gets swallowed by the loop thread when jcifs.util.loglevel
> < 3 which it is by default. So the jcifs user has no way to learn from the
> logs what caused the timeout.
>
> Please share your thought on the topic.
>
> Thank you in advance!
>
>
> Best regards,
> Marin
>

--001a1141bd007cedbb051102b461
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Marin,<div><br></div><div>copyTo() is a mess, and I&#39;ve=
 previously submitted two patches that address a lot of the issues with it,=
 though not sure if it addresses everything or what you are seeing. See <a =
href=3D"https://lists.samba.org/archive/jcifs/2014-June/010165.html">https:=
//lists.samba.org/archive/jcifs/2014-June/010165.html</a> and=C2=A0<a href=
=3D"https://lists.samba.org/archive/jcifs/2013-October/010115.html">https:/=
/lists.samba.org/archive/jcifs/2013-October/010115.html</a>. Also note that=
 there is a jcifs property=C2=A0jcifs.smb.client.ignoreCopyToException that=
 defaults to true, that is part of the equation, and I always set it to fal=
se.</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div><div dir=3D=
"ltr"><div style=3D"font-size:15px;padding-left:5px"><strong><font color=3D=
"#000000">Shon Vella</font></strong><br></div><div style=3D"font-size:15px;=
color:rgb(229,37,38);padding-left:5px"><b>Identity Automation</b></div><div=
 style=3D"font-size:15px;padding-left:5px"><font color=3D"#000000">Product =
Engineer</font></div><div style=3D"font-size:15px;padding-left:5px"><a href=
=3D"tel:281-220-0021%20x2030" value=3D"+12812200021" target=3D"_blank">281-=
220-0021 x2030</a>=C2=A0<span style=3D"color:rgb(229,37,38)">office</span><=
/div><div style=3D"font-size:15px;padding-left:5px"><a href=3D"tel:281-817-=
5579" value=3D"+12818175579" style=3D"color:rgb(17,85,204)" target=3D"_blan=
k">281-817-5579</a>=C2=A0<span style=3D"color:rgb(229,37,38)">fax</span></d=
iv><div style=3D"font-size:15px;padding-left:5px"><a href=3D"http://www.ide=
ntityautomation.com/" style=3D"color:rgb(17,85,204)" target=3D"_blank">www.=
identityautomation.com</a></div></div></div></div>
<br><div class=3D"gmail_quote">On Wed, Mar 11, 2015 at 1:24 AM, M. D. <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">moder@ab=
v.bg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">=C2=A0Hello,<br>
<br>
I have found a potential issue that is reproducable every time. Please shar=
e your thoughts on how that can or should be improved.<br>
<br>
Scenario is:<br>
1. JCIFS client starts to write a file.<br>
2. In the middle of writing, you kill the connection on client or server si=
de (I do it using TCP View on client side but it should matter)<br>
3. At that point, the jcifs writing thread is probably stuck in the wait(ti=
meout) directive in the jcifs.util.Transport#sendrecv() method, waiting for=
 a response to arrive.<br>
4. The thread that reads the responses is now holding the transport lock an=
d executing jcifs.util.transport.Transport#loop() but the doRecv( response =
) invocation fails with exception &quot;Connection reset by peer&quot; sinc=
e the connection is closed.<br>
5. The exception is caught in the loop method and then the looping thread c=
alls disconnect. The disconnect procedure calls logoff on the SmbSession an=
d the connection state is then changed. The disconnect is then successful (=
as it should be) and then all threads waiting for the transport are notifie=
d by the looping thread.<br>
6. The JCIFS client thread that initially was writing the file exits the wa=
it(timeout) since it was notified by the loop thread. But since a response =
wasn&#39;t received, another wait(timeout) is issued. After 30 seconds (def=
ault) the writing threads throws jcifs.util.transport.TransportException ex=
ception.<br>
<br>
Could that be improved somehow? Since the session state is disconnected it =
isn&#39;t necessary that the writing thread wait for another 30 seconds and=
 then fail with a timeout exception. Additionally, this &quot;Connection re=
set by peer&quot; exception gets swallowed by the loop thread when jcifs.ut=
il.loglevel &lt; 3 which it is by default. So the jcifs user has no way to =
learn from the logs what caused the timeout.<br>
<br>
Please share your thought on the topic.<br>
<br>
Thank you in advance!<br>
<br>
<br>
Best regards,<br>
Marin<br>
</blockquote></div><br></div></div>

--001a1141bd007cedbb051102b461--