Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of bengt.rodehav@gmail.com
 designates 209.85.160.45 as permitted sender)
MIME-Version: 1.0
Sender: bengt.rodehav@gmail.com
In-Reply-To: <1380639324281-5740700.post@n5.nabble.com>
References: <1380602772071-5740623.post@n5.nabble.com>
	<CAGB5yNmGO=j4fLf_MRAqkW0Vwc5pYGKPc85wA8u7_-aweJ-SQQ@mail.gmail.com>
	<1380639324281-5740700.post@n5.nabble.com>
Date: Tue, 1 Oct 2013 21:00:15 +0200
Message-ID: 
 <CAJ0TPG+0twVPrx=hSnu479dPRubGCYuVZSbhUKs_EfskqTVzEg@mail.gmail.com>
Subject: Re: Camel's use of jsch/java.io
From: Bengt Rodehav <bengt@rodehav.com>
To: users@camel.apache.org
Content-Type: multipart/alternative; boundary=047d7b33cf642bc68204e7b290a4

--047d7b33cf642bc68204e7b290a4
Content-Type: text/plain; charset=ISO-8859-1

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.
>

--047d7b33cf642bc68204e7b290a4--