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?
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/
>
