On Wed, Aug 31, 2011 at 4:02 PM, Sorin Silaghi <sorin7...@gmail.com> wrote: > Hi, > > > Ok thanks. I haven't been able to reproduce the problem. It seems > it happens in 2 steps: there is an error on the FTP server(this one might > vary so I don't think it's the cause) , our client then tries to disconnect > and reconnect in order to continue pooling and only after that the error I > linked happens where it looks like the thread dies. We wrote our own read > lock strategy which lists the files on the server and creates and deletes > the lock file. Could that be the cause of this problem? >
It sounds a bit like this issue http://fusesource.com/issues/browse/MR-506 Which just recently have been backported to the 2.6 branch, that fix will be in the next 2.6 release. > > thanks, > Sorin. > > On Wed, Aug 31, 2011 at 3:52 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > >> Hi >> >> It was this ticket >> http://fusesource.com/issues/browse/MR-470 >> >> And yeah it was backported to an earlier release of Fuse 2.6 as well. >> It does a try .. catch in the run method, which ought to keep the tread >> alive. >> >> You may want to set the new runLoggingLevel to something that you can >> see in your regular logs. >> That is logged before/after the doRun method. So if it suddenly stop >> logging, then something weird is going on. >> >> >> >> On Wed, Aug 31, 2011 at 2:32 PM, Sorin Silaghi <sorin7...@gmail.com> >> wrote: >> > Hi Claus, >> > >> > >> > Thanks for the quick reply. Do you happen to know which >> > version that happened in? We're using version 2.6.0-fuse-02-05 and I >> checked >> > now versions 2.7.1 and 2.8.0 and I can't see much difference. The logging >> is >> > the part that has changed the most in these versions. >> > >> > >> > I am currently trying to reproduce the problem using the >> > firewall to try and get an error. It hasn't worked yet though. >> > >> > >> > thank you, >> > Sorin. >> > >> > On Wed, Aug 31, 2011 at 2:38 PM, Claus Ibsen <claus.ib...@gmail.com> >> wrote: >> > >> >> Hi >> >> >> >> The ScheduledPollConsumer have been improved in later releases to be >> >> more resilient and avoid terminating due unhandled exceptions being >> >> thrown. >> >> >> >> >> >> >> >> On Wed, Aug 31, 2011 at 11:24 AM, Sorin Silaghi <sorin7...@gmail.com> >> >> wrote: >> >> > Hi all, >> >> > >> >> > >> >> > >> >> > We have a problem with FTP consumers dying on errors. It >> >> > happened a couple of times on one of our servers but we can't really >> >> > reproduce it. I've looked at the code and I can't figure out why it >> >> happens. >> >> > The only possibilities are that ScheduledPollConsumer throws an >> exception >> >> > that kills the thread or the consumer gets suspended and never goes >> back. >> >> > I'm not sure what this last part means but we'll do some more tests >> and >> >> I'll >> >> > do some debug if we can reproduce it. >> >> > >> >> > >> >> > Here's the stack trace: >> >> > >> >> > http://pastebin.com/niXtXKJ4 >> >> > >> >> > best regards, >> >> > Sorin >> >> > >> >> >> >> >> >> >> >> -- >> >> Claus Ibsen >> >> ----------------- >> >> FuseSource >> >> Email: cib...@fusesource.com >> >> Web: http://fusesource.com >> >> Twitter: davsclaus, fusenews >> >> Blog: http://davsclaus.blogspot.com/ >> >> Author of Camel in Action: http://www.manning.com/ibsen/ >> >> >> > >> >> >> >> -- >> Claus Ibsen >> ----------------- >> FuseSource >> Email: cib...@fusesource.com >> Web: http://fusesource.com >> Twitter: davsclaus, fusenews >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ >> > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
