Hello Atsuhiko,

No, I haven't done this yet. I wanted to keep the configuration as is just to make sure the problem would occur again (so I could take the stacktrace). I will activate the serverAliveInterval in the next couple of days and see if that helps. In a few weeks we will also upgrade to Jsch 0.1.48 (part of latest Camel).

But, how is it possible that the read() call can hang for several days? Does Jsch use any default read timeout? If not, how can I configure it? Finally I would hope that the TCPKeepAlive at the socket level would kick in after a while and mark the other end as "dead" and then close the socket.


2012/10/17 Atsuhiko Yamanaka <ymnk@jcraft.com>

   +-From: Bengt Rodehav <bengt@rodehav.com> --
   |_Date: Wed, 17 Oct 2012 09:26:28 +0200 ____

   |I'm using Apache Camel 2.9.1 which in turn uses jsch 0.1.44 for its sftp
   |support. Our application polls a remote sftp server once a minute 24/7.
   |Whenever a file is discovered in a remote folder it is downloaded. We
   |connect and disconnect for every poll.

   |I have previously written about this in the following thread:


   |Yesterday this happened again and our application then stopped polling the
   |remote sftp server. This time I used jconsole to get a stacktrace to see
   |where jsch was stuck. Here it comes:

Have you enabled Session#setServerAliveInterval(int interval) ?

Atsuhiko Yamanaka
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
Skype callto://jcraft/
Twitter: http://twitter.com/ymnk
Facebook: http://facebook.com/aymnk