[jcifs] jcifs.util.transport.TransportException when connection is killed on purpose.

[M. D.]

 Hello Shon,

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

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

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

diff --git a/src/jcifs/util/transport/Transport.java b/src/jcifs/util/transport/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;
 
-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;
 
 /**
@@ -74,6 +75,10 @@
                                 " timedout waiting for response to " +
                                 request );
                     }
+                    if (state != 3 && te != 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 problem.

Best regards,
M.D.

 >-------- Оригинално писмо --------
 >От:   Vella, Shon  
 >Относно: Re: [jcifs] jcifs.util.transport.TransportException when connection
 is killed on purpose.
 >До:  jcifs at lists.samba.org  
 >Изпратено на: Сряда, 2015, Март 11 14:49:59 EET
 >
 >
 >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 AutomationProduct Engineer281-220-0021 x2030 office281-817-5579 faxwww.identityautomation.com
 >On Wed, Mar 11, 2015 at 1:24 AM, M. D.  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
 >
 >