You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by bu...@apache.org on 2019/02/24 11:59:52 UTC

[Bug 48711] FTP task hangs when given incorrect configuration

https://bz.apache.org/bugzilla/show_bug.cgi?id=48711

Eugène Adell <eu...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eugene.adell@gmail.com

--- Comment #2 from Eugène Adell <eu...@gmail.com> ---
Not possible to reproduce this problem, and I don't believe this hangs forever.
If really someone is able to reproduce, he should add the debugging option to
see where it hangs and also provide a network capture.

A grep on java.org.apache.commons.net shows it uses the java.net.Socket class
but there is not one single call to the only method that could set the
connection timeout (
https://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#connect(java.net.SocketAddress,%20int)
). It's not likely the commons-net version is responsible of this behaviour,
but I can't grep all the code of all the versions.

This means it uses the default connection timeout, which is a system setting.
On Linux this is ETIMEDOUT that is documented in this man page :
http://man7.org/linux/man-pages/man2/connect.2.html
Even if set to 0 (infinite), it will be considered as the system default, which
will never be an infinite value.

When trying to connect to a server that is dropping connections, I can confirm
this connection timeout raises after 2 minutes :

11:35:54.779644 IP ***.54364 > ***.21: Flags [S], seq 459687467, win 14600,
options [mss 1460,sackOK,TS val 1303060844 ecr 0,nop,wscale 7], length 0
11:35:55.781232 IP ***.54364 > ***.21: Flags [S], seq 459687467, win 14600,
options [mss 1460,sackOK,TS val 1303061846 ecr 0,nop,wscale 7], length 0
11:35:57.783194 IP ***.54364 > ***.21: Flags [S], seq 459687467, win 14600,
options [mss 1460,sackOK,TS val 1303063848 ecr 0,nop,wscale 7], length 0
11:36:01.791172 IP ***.54364 > ***.21: Flags [S], seq 459687467, win 14600,
options [mss 1460,sackOK,TS val 1303067856 ecr 0,nop,wscale 7], length 0
11:36:09.807170 IP ***.54364 > ***.21: Flags [S], seq 459687467, win 14600,
options [mss 1460,sackOK,TS val 1303075872 ecr 0,nop,wscale 7], length 0
11:36:25.839250 IP ***.54364 > ***.21: Flags [S], seq 459687467, win 14600,
options [mss 1460,sackOK,TS val 1303091904 ecr 0,nop,wscale 7], length 0
11:36:57.903196 IP ***.54364 > ***.21: Flags [S], seq 459687467, win 14600,
options [mss 1460,sackOK,TS val 1303123968 ecr 0,nop,wscale 7], length 0

This StackOverflow answer can help (
https://stackoverflow.com/a/13266764/7748072 ) for those who want to read more.

I think that not being able to reproduce or give debug trace, this bug should
be closed.

-- 
You are receiving this mail because:
You are the assignee for the bug.