camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: Camel's use of jsch/java.io
Date Tue, 01 Oct 2013 19:00:15 GMT
Hello Neil,

I use the sftp component quite a lot. Now and then (perhaps once in a
month) it stops polling. I think the problem to that lies in the Jsch
itself and not in Camel. I'm not sure if it is the same problem you have
though.

I also took stack traces and found that Jsch was stuck in a read operation
but I think that was a socket read operation. It seems like Jsch does not
use TCP keepalive. This means that if the other end disconnects (or someone
in between), Jsch will never be notified and hangs forever in a read.

Instead Jsch relies on a timeout higher up in the protocol level (it might
be part of SSH I'm not sure). This timeout can be set by specifying the
"serverAliveInterval" parameter in the sftp component.

Using a polling delay of 60000 ms, we now set the serverAliveInterval to
10000ms. We haven't had any problems since (no proof though since we've
only been doing it for less than three months).

Although it isn't necessarily the same problem, it might still be worth
trying the serverAliveInterval parameter.

/Bengt


2013/10/1 neil <neil@rackle.com>

> The code that pointed out is in java.io.PipedInputStream.read().
>
> I believe Camel's thread management is triggering an infinite loop in it,
> although I am not certain.
>
> Is there a graceful way to have a Camel polling route completely reset
> itself periodically?  Or is bouncing the container a better option?
>
> Thanks,
> -neil
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Camel-s-use-of-jsch-java-io-tp5740623p5740700.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message