[ 
https://issues.apache.org/jira/browse/CAMEL-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14537620#comment-14537620
 ] 

Stephan Siano commented on CAMEL-8757:
--------------------------------------

Hi Claus, 
I am not able to edit the documentation. I will check the ICLA signing with my 
employer (but this may take some time because I have to find out how that 
process works first).

There are some general questions remaining:
1. Does it make sense to set a general default for the soTimeout (e.g. 300000 
(5 minutes))? This would change the behaviour for all endpoints, which is 
probably not so good (at least not in a patch). On the other hand having an 
SFTP (or FTP) poller that hangs forever on a stuck socket also doesn't make too 
much sense for me.
2. I am unsure about what is the best way to change the documentation. A 
potential approach would be:
a) remove the sentence "Note SFTP will automatic use the connectTimeout as the 
soTimeout." now. It is not really true.
b) once the patch is applied and released change the documentation again, 
however, I am not sure what would be the best here:
"FTP and FTPS Only: Camel 2.4, SFTP: Camel 2.14.3, 2.15.3: Is the 
SocketOptions.SO_TIMEOUT value in millis."?

What do you think?
Stephan

> SO_TIMEOUT not really set on SFTP connections
> ---------------------------------------------
>
>                 Key: CAMEL-8757
>                 URL: https://issues.apache.org/jira/browse/CAMEL-8757
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-ftp
>    Affects Versions: 2.14.2, 2.15.2, 2.16.0
>            Reporter: Stephan Siano
>            Priority: Minor
>         Attachments: 0001-CAMEL-8757-Set-soTimeout-on-SFTP-endpoints.patch
>
>
> The documentation for the soTimeout parameter in the camel-ftp option says:
> FTP and FTPS Only: Camel 2.4: Is the SocketOptions.SO_TIMEOUT value in 
> millis. Note SFTP will automatic use the connectTimeout as the soTimeout.
> The last statement is unfortunately not entirely true. JSCH's 
> Session.connect(int connectTimeout) method will initially set the SO_TIMEOUT 
> of the underlying socket to connectTimeout, however once the connection phase 
> is finished, it will change this value to the provided timeout value.
> We have an incredibly broken SFTP server. On that connections sometimes hang 
> after the connect phase, which causes polling consumer endpoints to hang in a 
> Socket.read() forever (which means that they stop polling).
> IMO the fix for that is twofold:
> 1. I attach a (trivial one-line) fix for the camel-ftp component, which will 
> set the soTimeout parameter to the timeout parameter of the JSCH session.
> 2. Someone with the access rights should modify the camel-ftp documentation
> 3. It might make sense to set the default for the soTimeout parameter to 
> something more sane than 0 (forever) but I don't do that in the patch (as it 
> may change the existing behaviour).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to