commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bogdan Drozdowski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NET-419) Not possible to call FTPClient.abort() method correctly
Date Tue, 06 Sep 2011 16:26:10 GMT

    [ 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

        

Mime
View raw message