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