commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bogdan Drozdowski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (NET-258) Implement A Keepalive Mechanism
Date Wed, 23 Feb 2011 13:08:38 GMT

    [ https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998359#comment-12998359
] 

Bogdan Drozdowski commented on NET-258:
---------------------------------------

The timeouts don't have to be the same order - if the control timeout is 30 seconds, but the
data timeout is 10 minutes, we have the same problem. Yes, it's not something like 1ms vs.
100 minutes, but generally if the control timeout is less than the data timeout, there is
a problem. Not only with the socket timeout itself, but the server-side timeout (the higher-level
timeout), too.

I don't see how synchronizing a command and its reply would prevent the NOOPs from being sent,
assuming everything is working fine. The server sends a reply immediately, so we leave the
synchronized method as soon as we get the reply (which is usually soon). Even for RETR/STOR/LIST/...
the server first sends a 150 (which makes us leave __getReply() and sendCommand()) and after
the transfer the server sends a 226. Util.copyStream() (the long-lasting operation) is called
outside of the synchronized block (synchronization is in _openDataConnection_()). CompletePendingCommand()
is left unsynchronized right now, however.

I'm not saying "no" to sending NOOPs only during transfers. On the contrary, it's a good solution,
because we have everything under control. But the user-settable and server timeouts make me
think that we need something working independently of the transfer-handling thread.

> Implement A Keepalive Mechanism
> -------------------------------
>
>                 Key: NET-258
>                 URL: https://issues.apache.org/jira/browse/NET-258
>             Project: Commons Net
>          Issue Type: Improvement
>    Affects Versions: 2.0
>            Reporter: Rory Winston
>            Assignee: Rory Winston
>         Attachments: ftp-keepalive.diff
>
>
> For routers/firewalls that terminate idle connections, a separate heartbeat mechanism
may need to be implemented to keep the control connection active.
> Some potential issues:
> * Synchronization between a heartbeat write and a __getReply() on an active control connection
command;
> * Should use the NOOP command as a heartbeat signal;
> * Make the timeout configurable;
> * Default SocketImpl::setKeepAlive() wont do here.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message