[
https://issues.apache.org/jira/browse/NET-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098138#comment-13098138
]
Bogdan Drozdowski commented on NET-419:
---------------------------------------
Checking if the abort command was issued could be implemented the same way as
the current NOOP sending, but it has a flow (just ilke the NOOP sending) - the
listener classes that are registered on the transfers are called when bytes are
transferred. This means that if we wait with sending the ABOR command until
some bytes are received, we're defeating the purpose of the ABOR command
itself. And if we send it immediately, we have synchronization problems. If we
receive data often, then the ABOR will be sent not very long after calling the
abort() method. If not (including slow or already disconnected servers), the
method won't do nothing. So, sure, we may try it, but this fix won't be perfect.
Maybe we could stop waiting for additional replies, so that each method that
sends a command could have a synchronized block within which the command would
be sent and one reply read. This way the BufferredReaders/Writers would be
synchronized and other threads could send commands. This won't make the whole
FTPClient thread-safe, but perhaps this would be enough for both the NOOP and
ABOR to work properly during transfers. The drawback is that we're changing the
behavious of some methods in an incompatible way.
I'd look for synchronized line-wise readers and writers (probably outside of
the Java core classes, perhaps even somewhere in Apache) and make command
sending and reply parsing synchronized methods, this could fix our problems.
Finding such classes is one thing. The FTP, FTPClient, FTPSClient and maybe
other classes would have to be changed. Unfortunately, currently I don't have
the time to look at this closer, but I'll look into the problem later. If you
have any other ideas, share them!
> Not possible to call FTPClient.abort() method correctly
> -------------------------------------------------------
>
> Key: NET-419
> URL: https://issues.apache.org/jira/browse/NET-419
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 3.0
> Environment: java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
> Linux cattie 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011
> x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Tomas Mysik
>
> Unfortunately, it seems that there are difficulties of using FTPClient.abort()
> method [1][2]. Also, it is really not clear how the abort() method should be
> called/used at all - if from another thread (as I would expect) then there is
> a problem with
> thread-safety: FTPClient itself is not thread-safe so it means that some
> custom lock/monitor must be used; but this lock will prevent calling abort()
> on
> the FTPClient while it is downloading/uploading file since file
> upload/download
> itself is blocking...
> If I'm wrong and the abort() method works then an example in Javadoc would be
> more than welcome.
> Thanks a lot.
> [1]
> http://apache-commons.680414.n4.nabble.com/Net-FTPClient-abort-problem-td739542.html
> [2] http://www.tikalk.com/java/forums/apache-ftp-client-abort-transfer
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
