camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Commented] (CAMEL-8757) SO_TIMEOUT not really set on SFTP connections
Date Sat, 09 May 2015 08:25:59 GMT


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 ;)

> SO_TIMEOUT not really set on SFTP connections
> ---------------------------------------------
>                 Key: CAMEL-8757
>                 URL:
>             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 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

View raw message