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

 Hello,

I have found a potential issue that is reproducable every time. Please sh=
are 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( respo=
nse ) invocation fails with exception "Connection reset by peer" since th=
e 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 SmbSessio=
n and the connection state is then changed. The disconnect is then succes=
sful (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 respo=
nse wasn't received, another wait(timeout) is issued. After 30 seconds (d=
efault) the writing threads throws jcifs.util.transport.TransportExceptio=
n exception.

Could that be improved somehow? Since the session state is disconnected i=
t 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.log=
level < 3 which it is by default. So the jcifs user has no way to learn f=
rom the logs what caused the timeout.

Please share your thought on the topic.

Thank you in advance!


Best regards,
Marin