Discussion:
[Twisted-Python] Hanging SFTP client operations on server disconnection
Adi Roiban
2017-02-02 10:43:12 UTC
Permalink
Hi,

t.conch.ssh.filetransfer.FileTransferClient._sendRequest keeps a
mapping with active SFTP requests in self.openRequests

The self.openRequests is only updated when the server is responding
for that request.

They are not cleared/cancelled on connection lost.

In the case in which the client send a request in the exact same time
in which the server closes the connect , the client will send the
request as there is no way to know that the server is gone... but
since the server is gone it will not reply to the response... and the
deferred is never called.

To solve this issue, I went for cancelling the open requests when the
connection is close.

I assume that this is also an issue with bad behaved servers which
will just ignore a request... so instead of a simple deferred, there
is the need to use a timeout deferred.

Is this a bug?
I am wondering if I am doing something wrong and these type of errors
should be handled in a different way.

Thanks!

PS: There is a stray release notes fragment in conch
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/8791.feature
--
Adi Roiban
Glyph Lefkowitz
2017-02-15 06:56:29 UTC
Permalink
Post by Adi Roiban
Hi,
t.conch.ssh.filetransfer.FileTransferClient._sendRequest keeps a
mapping with active SFTP requests in self.openRequests
The self.openRequests is only updated when the server is responding
for that request.
They are not cleared/cancelled on connection lost.
In the case in which the client send a request in the exact same time
in which the server closes the connect , the client will send the
request as there is no way to know that the server is gone... but
since the server is gone it will not reply to the response... and the
deferred is never called.
To solve this issue, I went for cancelling the open requests when the
connection is close.
That sounds correct. Is there a ticket for this?
Post by Adi Roiban
I assume that this is also an issue with bad behaved servers which
will just ignore a request... so instead of a simple deferred, there
is the need to use a timeout deferred.
Is this a bug?
I am wondering if I am doing something wrong and these type of errors
should be handled in a different way.
Generally speaking, any Deferred attached to a connection object (regardless of protocol) should be failed with a connection failure error of some kind when the connection is dropped.
Post by Adi Roiban
Thanks!
PS: There is a stray release notes fragment in conch
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/8791.feature <https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/8791.feature>
Oops!

Wait; why do you say this is "stray"?

-glyph
Tristan Seligmann
2017-02-15 08:39:33 UTC
Permalink
Post by Adi Roiban
PS: There is a stray release notes fragment in conch
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/8791.feature
Oops!
Wait; why do you say this is "stray"?
It appears to be in the wrong directory (should be in
src/twisted/conch/topfiles/).
Glyph Lefkowitz
2017-02-15 08:43:59 UTC
Permalink
Post by Glyph Lefkowitz
Post by Adi Roiban
PS: There is a stray release notes fragment in conch
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/8791.feature <https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/8791.feature>
Oops!
Wait; why do you say this is "stray"?
It appears to be in the wrong directory (should be in src/twisted/conch/topfiles/).
Oh, whoops.

-g

Loading...