commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bogdan Drozdowski (JIRA)" <>
Subject [jira] Commented: (NET-258) Implement A Keepalive Mechanism
Date Thu, 17 Feb 2011 12:55:25 GMT


Bogdan Drozdowski commented on NET-258:

You're absolutely right about the different threads updating/reading the same data.

Yes, we could have a single Thread with a loop and make all the command sending on that thread.
If the user enabled keepalives, the thread would periodically send the NOOP and wait for the
answer. The command-sending methods would have to block until the reply has been received
or an Exception occurs (just like they do now).

The java.util.concurrent.Executors class looks nice, especially the newSingleThreadExecutor()
and newSingleThreadScheduledExecutor() methods. The get() method of the Future objects returned
from submit() would allow us to wait for the task to complete without a loop (which would
require another volatile boolean, for example).

This is, however, a serious code change. It would probably had to be done on the base class,
FTP, not on the FTPClient class, so this mechanism doesn't get passed. Something could be
broken by this, for example how to return IOExceptions or how to know if an ExecutionException
we caught should be turned into an IOException or perhaps into something else, or ignored?
I don't know if this idea with Executors is good after all, perhaps there will be a better
solution. I know this solution and I know it works, but I'm starting to think this may not
be the thing we need. Just another solution to think about.

> Implement A Keepalive Mechanism
> -------------------------------
>                 Key: NET-258
>                 URL:
>             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
> * 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:


View raw message