Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Fri, 11 Feb 2011 16:53:57 +0000 (UTC)
From: "Bogdan Drozdowski (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <1527033868.10857.1297443237547.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Commented: (NET-258) Implement A Keepalive Mechanism
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

Right. Volatile - yes, you're correct - I forgot that. About the rest: sending NOOPs does nothing to the data transfer (theoretically even closing the control connection politely does nothing). The data transfer is done by Input/OutputStreams, as far as I can see. So we have one thread reading/writing and the other sending NOOPs. The keepalive thread is not started automatically. The user of the class decides if the thread is to be run and when should it be stopped. Worker thread is a good idea, but the problem is that we need a reply immediately, so we can't just queue the command, because it could break the getReply methods. The intention of the patch is that the command sender knows that he/she won't send any commands in the nearest future, so he/she launches the thread. So if any threads the user has won't send any commands, the user may start the thread. I'm not trying to outsmart anything and guess if we should interfere or not. This is just a small solution for a start
 .

> 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