camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: pool thread dies after FTP error
Date Thu, 01 Sep 2011 13:56:55 GMT
On Thu, Sep 1, 2011 at 8:30 AM, Sorin Silaghi <sorin7486@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 <claus.ibsen@gmail.com> wrote:
>
>> On Wed, Aug 31, 2011 at 4:02 PM, Sorin Silaghi <sorin7486@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.ibsen@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 <sorin7486@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.ibsen@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/

Mime
View raw message