[
https://issues.apache.org/jira/browse/CAMEL-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14536295#comment-14536295
]
Claus Ibsen commented on CAMEL-8757:
------------------------------------
Thanks Stephan. Are you able to edit the documentation yourself? If not I
suggest you read this page, and get things setup so you can do this. We love
help. Also the ICLA signing is needed for becoming a committer. So that is just
a step closer towards that ;)
http://camel.apache.org/how-do-i-edit-the-website.html
> 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)
