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

[M. D.]

 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