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 Tue, 22 Feb 2011 13:19:38 GMT


Bogdan Drozdowski commented on NET-258:

These apply mainly to the PUT/GET (or STOR/RETR), but not only. I can imagine a user that
doesn't constantly send data, an issue of type "I'm not sending anything right now, but I
may need to in 5 minutes, so let's not disconnect".

The listener method is nice, but if the user sets the timeout to 10 or 20 minutes, it won't
do any good. This is it's only problem, I think. This is why a Timer/ThreadExecutor would
be requierd, and this leads to the second method.

Now the separate thread method: if we imlpement a mechanism that the user can start and stop,
it doesn't need to be synchronized with GET/PUT, although some general synchronization (like
making sendCommand() synchronized) would be recommended. If sendCommand() is synchronized,
readLine() would never get called by different threads at the same time. Even if we send NOOPs
only on our threads, this wouldn't stop the user from interfering with us by launching a new
thread that sends commands or does anything else (including a user-created keepalive mechanism).
Now, if sendCommand() is synchronized, so is __getReply(), so not only it could be called
by only one thread at a time, but the command-reply pairs wouldn't get messed. The questions
are: is this true (I may be missing something) and is this enough?

> 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