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

[Vella, Shon]

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 Automation*
Product Engineer
281-220-0021 x2030 office
281-817-5579 fax
www.identityautomation.com

On Wed, Mar 11, 2015 at 1:24 AM, M. D. <moder at abv.bg> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/jcifs/attachments/20150311/233dee21/attachment.html>