<div dir="ltr">Marin,<div><br></div><div>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 <a href="https://lists.samba.org/archive/jcifs/2014-June/010165.html">https://lists.samba.org/archive/jcifs/2014-June/010165.html</a> and <a href="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 jcifs.smb.client.ignoreCopyToException that defaults to true, that is part of the equation, and I always set it to false.</div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div style="font-size:15px;padding-left:5px"><strong><font color="#000000">Shon Vella</font></strong><br></div><div style="font-size:15px;color:rgb(229,37,38);padding-left:5px"><b>Identity Automation</b></div><div style="font-size:15px;padding-left:5px"><font color="#000000">Product Engineer</font></div><div style="font-size:15px;padding-left:5px"><a href="tel:281-220-0021%20x2030" value="+12812200021" target="_blank">281-220-0021 x2030</a> <span style="color:rgb(229,37,38)">office</span></div><div style="font-size:15px;padding-left:5px"><a href="tel:281-817-5579" value="+12818175579" style="color:rgb(17,85,204)" target="_blank">281-817-5579</a> <span style="color:rgb(229,37,38)">fax</span></div><div style="font-size:15px;padding-left:5px"><a href="http://www.identityautomation.com/" style="color:rgb(17,85,204)" target="_blank">www.identityautomation.com</a></div></div></div></div>
<br><div class="gmail_quote">On Wed, Mar 11, 2015 at 1:24 AM, M. D. <span dir="ltr"><<a href="mailto:moder@abv.bg" target="_blank">moder@abv.bg</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Hello,<br>
<br>
I have found a potential issue that is reproducable every time. Please share 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 side (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(timeout) 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 and executing jcifs.util.transport.Transport#loop() but the doRecv( response ) invocation fails with exception "Connection reset by peer" since the connection is closed.<br>
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.<br>
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.<br>
<br>
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.<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>