You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Jaroslav Chmurny (Created) (JIRA)" <ji...@apache.org> on 2012/04/19 17:18:40 UTC

[jira] [Created] (NET-459) FTPClient.storeFile never returns in active mode if data channel cannot be established

FTPClient.storeFile never returns in active mode if data channel cannot be established
--------------------------------------------------------------------------------------

                 Key: NET-459
                 URL: https://issues.apache.org/jira/browse/NET-459
             Project: Commons Net
          Issue Type: Bug
          Components: FTP
    Affects Versions: 3.1, 3.0.1
            Reporter: Jaroslav Chmurny


FTPClient.storeFile(String, InputStream) method is used to upload a file to the FTP server. Before the upload, active mode is chosen via the FTPClient.enterLocalActiveMode() method. However, the FTP server is not able to establish the data channel to the FTP client (for instance because of firewall). The storeFile method blocks and never returns. When I capture the network traffic with Wireshark, I see that there are two responses to the STOR command: the first one indicates that the data channel is going to be established, the second one indicates that the FTP server cannot establish the data channel. However, the storeFile method remains blocked forever, even if I play around with the various timeouts (setSoTimeout, setDefaultTimeout, setControlKeepAliveTimeout, setControlKeepAliveReplyTimeout).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (NET-459) FTPClient.storeFile never returns in active mode if data channel cannot be established

Posted by "Sebb (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NET-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266986#comment-13266986 ] 

Sebb commented on NET-459:
--------------------------

Looks like that thread dump was from running 3.0.1.

There's currently no way to apply a separate timeout to the accept() call, but if you call the method FTPClient#setDataTimeout(int), the timeout will be applied to the accept call as well.
                
> FTPClient.storeFile never returns in active mode if data channel cannot be established
> --------------------------------------------------------------------------------------
>
>                 Key: NET-459
>                 URL: https://issues.apache.org/jira/browse/NET-459
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 3.0.1, 3.1
>            Reporter: Jaroslav Chmurny
>
> FTPClient.storeFile(String, InputStream) method is used to upload a file to the FTP server. Before the upload, active mode is chosen via the FTPClient.enterLocalActiveMode() method. However, the FTP server is not able to establish the data channel to the FTP client (for instance because of firewall). The storeFile method blocks and never returns. When I capture the network traffic with Wireshark, I see that there are two responses to the STOR command: the first one indicates that the data channel is going to be established, the second one indicates that the FTP server cannot establish the data channel. However, the storeFile method remains blocked forever, even if I play around with the various timeouts (setSoTimeout, setDefaultTimeout, setControlKeepAliveTimeout, setControlKeepAliveReplyTimeout).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (NET-459) FTPClient.storeFile never returns in active mode if data channel cannot be established

Posted by "Sebb (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NET-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258318#comment-13258318 ] 

Sebb commented on NET-459:
--------------------------

Where exactly does the method block?

Can you take a thread dump to see?
                
> FTPClient.storeFile never returns in active mode if data channel cannot be established
> --------------------------------------------------------------------------------------
>
>                 Key: NET-459
>                 URL: https://issues.apache.org/jira/browse/NET-459
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 3.0.1, 3.1
>            Reporter: Jaroslav Chmurny
>
> FTPClient.storeFile(String, InputStream) method is used to upload a file to the FTP server. Before the upload, active mode is chosen via the FTPClient.enterLocalActiveMode() method. However, the FTP server is not able to establish the data channel to the FTP client (for instance because of firewall). The storeFile method blocks and never returns. When I capture the network traffic with Wireshark, I see that there are two responses to the STOR command: the first one indicates that the data channel is going to be established, the second one indicates that the FTP server cannot establish the data channel. However, the storeFile method remains blocked forever, even if I play around with the various timeouts (setSoTimeout, setDefaultTimeout, setControlKeepAliveTimeout, setControlKeepAliveReplyTimeout).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Resolved] (NET-459) FTPClient.storeFile never returns in active mode if data channel cannot be established

Posted by "Sebb (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/NET-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb resolved NET-459.
----------------------

    Resolution: Not A Problem
    
> FTPClient.storeFile never returns in active mode if data channel cannot be established
> --------------------------------------------------------------------------------------
>
>                 Key: NET-459
>                 URL: https://issues.apache.org/jira/browse/NET-459
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 3.0.1, 3.1
>            Reporter: Jaroslav Chmurny
>
> FTPClient.storeFile(String, InputStream) method is used to upload a file to the FTP server. Before the upload, active mode is chosen via the FTPClient.enterLocalActiveMode() method. However, the FTP server is not able to establish the data channel to the FTP client (for instance because of firewall). The storeFile method blocks and never returns. When I capture the network traffic with Wireshark, I see that there are two responses to the STOR command: the first one indicates that the data channel is going to be established, the second one indicates that the FTP server cannot establish the data channel. However, the storeFile method remains blocked forever, even if I play around with the various timeouts (setSoTimeout, setDefaultTimeout, setControlKeepAliveTimeout, setControlKeepAliveReplyTimeout).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (NET-459) FTPClient.storeFile never returns in active mode if data channel cannot be established

Posted by "Jaroslav Chmurny (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NET-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266434#comment-13266434 ] 

Jaroslav Chmurny commented on NET-459:
--------------------------------------

Here is the thread dump produced by jstack (the main thread is the relevant one):

2012-05-02 10:30:02
Full thread dump Java HotSpot(TM) Client VM (20.6-b01 mixed mode, sharing):

"Low Memory Detector" daemon prio=6 tid=0x02bab000 nid=0x1294 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"C1 CompilerThread0" daemon prio=10 tid=0x02ba5000 nid=0x10b4 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"Attach Listener" daemon prio=10 tid=0x02ba3800 nid=0x1330 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"Signal Dispatcher" daemon prio=10 tid=0x02ba2400 nid=0x10a8 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"Finalizer" daemon prio=8 tid=0x02b9c800 nid=0x12f0 in Object.wait() [0x02d2f000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x22911148> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(Unknown Source)
	- locked <0x22911148> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(Unknown Source)
	at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)

   Locked ownable synchronizers:
	- None

"Reference Handler" daemon prio=10 tid=0x02b97c00 nid=0x1088 in Object.wait() [0x02cdf000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x22911048> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:485)
	at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
	- locked <0x22911048> (a java.lang.ref.Reference$Lock)

   Locked ownable synchronizers:
	- None

"main" prio=6 tid=0x00317000 nid=0x14fc runnable [0x0092f000]
   java.lang.Thread.State: RUNNABLE
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(Unknown Source)
	- locked <0x229d0320> (a java.net.SocksSocketImpl)
	at java.net.ServerSocket.implAccept(Unknown Source)
	at java.net.ServerSocket.accept(Unknown Source)
	at org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:693)
	at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:551)
	at org.apache.commons.net.ftp.FTPClient.storeFile(FTPClient.java:1704)
	at FtpUploadClient.put(FtpUploadClient.java:68)
	at FtpUploadClient.main(FtpUploadClient.java:38)

   Locked ownable synchronizers:
	- None

"VM Thread" prio=10 tid=0x02b5ac00 nid=0x1588 runnable 

"VM Periodic Task Thread" prio=10 tid=0x02bb6000 nid=0xd9c waiting on condition 

JNI global references: 987

                
> FTPClient.storeFile never returns in active mode if data channel cannot be established
> --------------------------------------------------------------------------------------
>
>                 Key: NET-459
>                 URL: https://issues.apache.org/jira/browse/NET-459
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 3.0.1, 3.1
>            Reporter: Jaroslav Chmurny
>
> FTPClient.storeFile(String, InputStream) method is used to upload a file to the FTP server. Before the upload, active mode is chosen via the FTPClient.enterLocalActiveMode() method. However, the FTP server is not able to establish the data channel to the FTP client (for instance because of firewall). The storeFile method blocks and never returns. When I capture the network traffic with Wireshark, I see that there are two responses to the STOR command: the first one indicates that the data channel is going to be established, the second one indicates that the FTP server cannot establish the data channel. However, the storeFile method remains blocked forever, even if I play around with the various timeouts (setSoTimeout, setDefaultTimeout, setControlKeepAliveTimeout, setControlKeepAliveReplyTimeout).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira