On Fri, Dec 16, 2011 at 10:14 AM, Kalpak Gadre <[email protected]> wrote: > Hi Claus, > > Thanks for the input. > > If I am not wrong, the JSCH provides a logging interface to the client > application, Camel uses this interface and outputs all the logs starting > with "JSCH ->" > > I looked at the JSCH code to figure where the exception was originating > from, but most of the exceptions are simply logged with exception messages > and without stack trace in JSCH. > > I cannot find out stack trace, unless I make changes in JSCH library and > recompile to improve loggin. Maybe that is the way to go? >
Maybe JSCH itself has additional logging? I wonder if logs from the transport layer is possible? Or maybe you can see anything on the other side (eg from the server). Maybe there is some error code returned there. Also you are welcome to double check the camel code, about the disconnect option. Maybe there is a slight mistake there? Although that may seem a bit odd as invoking disconnect should possible all there is needed. > Thanks, > > Kalpak > > > >> On Wed, Dec 14, 2011 at 1:44 PM, Kalpak Gadre<[email protected]> wrote: >>> >>> Hi, >>> >>> I am working with a route which transfers files over SFTP. The route had >>> trouble in case where there was inactivity for more than SSH session >>> timeout >>> period. Whenever an exchange was initiated after long duration of >>> inactivity, it would fail due to "Connection reset by peer" which I >>> assume >>> is because SSH server dropped the session due to inactivity. >>> >>> To fix this problem, I added disconnect=true to ensure that every >>> transfer >>> reconnects to the SSH session. After adding this though, I am seeing >>> issues >>> transferring files. Here are log snippets, >>> >>> 2011-12-12 18:01:24,159 | DEBUG | Wrote [/tmp/NSE/FILE_20111212.txt] to >>> >>> [Endpoint[sftp://10.0.0.1//tmp/NSE/?disconnect=true&password=******&username=user]] >>> 2011-12-12 18:01:24,159 | TRACE | postWriteCheck disconnect from: >>> >>> Endpoint[sftp://10.0.0.1//tmp/NSE/?disconnect=true&password=******&username=user] >>> 2011-12-12 18:01:24,159 | DEBUG | Disconnecting from: >>> >>> Endpoint[sftp://10.0.0.1//tmp/NSE/?disconnect=true&password=******&username=user] >>> 2011-12-12 18:01:24,159 | INFO | JSCH -> Disconnecting from 10.0.0.1 >>> port >>> 22 >>> 2011-12-12 18:01:24,159 | INFO | JSCH -> Caught an exception, leaving >>> main >>> loop due to socket closed >>> >>> Although the log suggests that the file is written and then route is >>> trying >>> to disconnect as a part of postWriteCheck, the file is not written on the >>> server. Not sure if it is due to unsafe disconnect from the SSH server. >>> >>> Any suggestions what could be wrong? >>> >> I suggest to enable DEBUG/TRACE logging of the JSCH library to see >> more details why it fails, and what the exception is etc. >> >>> Thanks, >>> >>> Kalpak >> >> >> > -- Claus Ibsen ----------------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
