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 Sat, 12 Feb 2011 16:28:57 GMT

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

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

Yes, the keepalive thread could see the end-of-transfer message, but then completePendingCommand()
would see the reply to the NOOP, which is always positive (as the NOOP is mandatory to implement),
so it probably wouldn't choke on this. Now, if the code would be re-written to expect exactly
226, we have a problem.

Is there something particular in the thread-safety we need to worry about? We're assuming
that the thread is launched only when the user has no commands to send. So, the input and
output buffers (on the control channel) won't have any interleaved data from different threads.
If we assume that the thread is used as it was meant to be used (which means not sending any
commands while it's running), then I don't know if anything could happen. The server is "passive"
- it's the client who sends commands and since the client isn't sending any (the assumption
when running the thread), nothing will appear on the control channel. Furthermore, no other
methods or fields are used. Perhaps the only thing that could happen is a disconnection warning
(code 421), but the thread would catch it and terminate.

If the user sends other commands while the thread is running - then yes, we could get a mess
like assigning wrong replies to commands sent. But it wouldn't be our problem, because the
mechanism wasn't assumed to work like this (it's the user that is using the client incorrectly)
and this won't work.

I don't know what will happen when different threads access the client and send commands even
with the current code, not to mention the patch. If we want to be safe under all circumstances,
work every time (even if the user wants to break the program), correctly queue the replies
and commands, we need a very different solution - this patch won't make this happen. This
is a simple example solution (perhaps it's what the users are doing already) and it's manually-started,
so it won't harm existing code. To make the whole thing perfect, perhaps a bigger refactoring
would be required, but right now I haven't got an idea how to do it well (both queues of the
commands and replies, with the replies returned immediately to the caller).

> 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