[
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997785#comment-12997785
]
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: 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
