You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Sorin Silaghi <so...@gmail.com> on 2011/08/31 11:24:39 UTC
pool thread dies after FTP error
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
Re: pool thread dies after FTP error
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Sep 1, 2011 at 8:30 AM, Sorin Silaghi <so...@gmail.com> wrote:
> OK that is great news. Any idea when the next version will be released? Is
> there an announcement mailing list for Fuse we could folow?
>
It unfortunately just missed a new 2.6 release which we did recently.
The user forum is where announcements would go. However I think we are
not always consistent and remembering to post there.
You can always just keep an eye from time to time on the fuse maven
repo where all the public releases is.
If you are a fuse subscriber, then I suggest to use that channel to
get hold of a release with those fixes.
And you may consider asking in the fuse source forum, as this question
is not Apache specific.
> thanks
>
> On Wed, Aug 31, 2011 at 6:48 PM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Wed, Aug 31, 2011 at 4:02 PM, Sorin Silaghi <so...@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 <cl...@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 <so...@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 <cl...@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 <sorin7486@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: cibsen@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: cibsen@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: cibsen@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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: pool thread dies after FTP error
Posted by Sorin Silaghi <so...@gmail.com>.
OK that is great news. Any idea when the next version will be released? Is
there an announcement mailing list for Fuse we could folow?
thanks
On Wed, Aug 31, 2011 at 6:48 PM, Claus Ibsen <cl...@gmail.com> wrote:
> On Wed, Aug 31, 2011 at 4:02 PM, Sorin Silaghi <so...@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 <cl...@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 <so...@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 <cl...@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 <sorin7486@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: cibsen@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: cibsen@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: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
Re: pool thread dies after FTP error
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Aug 31, 2011 at 4:02 PM, Sorin Silaghi <so...@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 <cl...@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 <so...@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 <cl...@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 <so...@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: cibsen@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: cibsen@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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: pool thread dies after FTP error
Posted by Sorin Silaghi <so...@gmail.com>.
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 <cl...@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 <so...@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 <cl...@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 <so...@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: cibsen@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: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
Re: pool thread dies after FTP error
Posted by Claus Ibsen <cl...@gmail.com>.
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 <so...@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 <cl...@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 <so...@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: cibsen@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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: pool thread dies after FTP error
Posted by Sorin Silaghi <so...@gmail.com>.
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 <cl...@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 <so...@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: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
Re: pool thread dies after FTP error
Posted by Claus Ibsen <cl...@gmail.com>.
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 <so...@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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/