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

 Hello Shon,

Thank you for the tip!=20
I had no idea how nasty this copyTo() method was!

Unfortunately, this isn't the cause of our issues.=20

I think that it is a good idea to add an if statement that checks the sta=
te of the transport after the sendrecv timeout. Something like that:

diff --git a/src/jcifs/util/transport/Transport.java b/src/jcifs/util/tra=
nsport/Transport.java
index fd77a19..9143d00 100644
--- a/src/jcifs/util/transport/Transport.java
+++ b/src/jcifs/util/transport/Transport.java
@@ -1,8 +1,9 @@
 package jcifs.util.transport;
=20
-import java.io.*;
-import java.net.*;
-import java.util.*;
+import java.io.IOException;
+import java.io.InputStream;
+import java.util.HashMap;
+
 import jcifs.util.LogStream;
=20
 /**
@@ -74,6 +75,10 @@
                                 " timedout waiting for response to " +
                                 request );
                     }
+                    if (state !=3D 3 && te !=3D null)
+                    {
+                        throw new TransportException("Exception occured =
while waiting for response to " + request, te);
+                    }
                 }
             } catch( IOException ioe ) {
                 if (log.level > 2)

I will test this for a couple of days and report back if this fixes the p=
roblem.

Best regards,
M.D.

 >-------- =D0=9E=D1=80=D0=B8=D0=B3=D0=B8=D0=BD=D0=B0=D0=BB=D0=BD=D0=BE =D0=
=BF=D0=B8=D1=81=D0=BC=D0=BE --------
 >=D0=9E=D1=82:   Vella, Shon =20
 >=D0=9E=D1=82=D0=BD=D0=BE=D1=81=D0=BD=D0=BE: Re: [jcifs] jcifs.util.tran=
sport.TransportException when connection
 is killed on purpose.
 >=D0=94=D0=BE:  [email protected] =20
 >=D0=98=D0=B7=D0=BF=D1=80=D0=B0=D1=82=D0=B5=D0=BD=D0=BE =D0=BD=D0=B0: =D0=
=A1=D1=80=D1=8F=D0=B4=D0=B0, 2015, =D0=9C=D0=B0=D1=80=D1=82 11 14:49:59 E=
ET
 >
 >
 >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 ever=
ything or what you are seeing. See https://lists.samba.org/archive/jcifs/=
2014-June/010165.html and=C2=A0https://lists.samba.org/archive/jcifs/2013=
-October/010115.html. 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 false.Shon Vella
 >Identity AutomationProduct Engineer281-220-0021 x2030=C2=A0office281-81=
7-5579=C2=A0faxwww.identityautomation.com
 >On Wed, Mar 11, 2015 at 1:24 AM, M. D.  wrote:
 >=C2=A0Hello,
 >
 >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 serve=
r 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 wai=
t(timeout) directive in the jcifs.util.Transport#sendrecv() method, waiti=
ng for a response to arrive.
 >4. The thread that reads the responses is now holding the transport loc=
k and executing jcifs.util.transport.Transport#loop() but the doRecv( res=
ponse ) invocation fails with exception "Connection reset by peer&qu=
ot; since the connection is closed.
 >5. The exception is caught in the loop method and then the looping thre=
ad calls disconnect. The disconnect procedure calls logoff on the SmbSess=
ion and the connection state is then changed. The disconnect is then succ=
essful (as it should be) and then all threads waiting for the transport a=
re notified by the looping thread.
 >6. The JCIFS client thread that initially was writing the file exits th=
e wait(timeout) since it was notified by the loop thread. But since a res=
ponse wasn't received, another wait(timeout) is issued. After 30 seco=
nds (default) the writing threads throws jcifs.util.transport.TransportEx=
ception exception.
 >
 >Could that be improved somehow? Since the session state is disconnected=
 it isn't necessary that the writing thread wait for another 30 secon=
ds and then fail with a timeout exception. Additionally, this "Conne=
ction reset by peer" exception gets swallowed by the loop thread whe=
n jcifs.util.loglevel < 3 which it is by default. So the jcifs user has n=
o way to learn from the logs what caused the timeout.
 >
 >Please share your thought on the topic.
 >
 >Thank you in advance!
 >
 >
 >Best regards,
 >Marin
 >
 >