The original ticket for this is: CAMEL-501
https://issues.apache.org/activemq/browse/CAMEL-501
On Tue, Jun 23, 2009 at 9:41 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> Hi
> Yeah I think the idea was that it should remember if an exception occurred
> once during a poll.
> And then report it when it was stopping.
>
> But I think it should ignore this and just do as it does log a WARN when
> the poll failed.
>
> So we can do a clean stop. And the logic that stops should try to stop all
> resources and not break at first exception.
>
> There is a ticket somewhere in JIRA to allow some sort of strategy what to
> do when an exception occurred in the poller logic.
>
>
>
> On Mon, Jun 22, 2009 at 6:44 PM, Siegfried.Wirth <
> siegfried.wi...@capgemini-sdm.com> wrote:
>
>>
>> Hi,
>>
>> when testing some ftp functionality I found the following issue which may
>> indicate a bug in ScheduledPollingConsumer:
>>
>> 1) I start a route using FtpConsumer (and thus a ScheduledPollingConsumer)
>> 2) This route encounters an error, because the ftp server is not available
>> and thus an excpetion is logged.
>> 3) Now I try to stop the route (to do some reconfigurations and later i
>> want
>> to start it again) and everything fails...
>>
>> I think there is the following problem in ScheduledPollingConsumer:
>> - When the run-Methods tries to poll and poll throws an exception, the
>> consumer 'remembers' this exception as firstExceptionThrown (there is a
>> variable named so in the polling consumer).
>> - When later on the route is stopped and therefore the
>> ScheduledPollingConsumer is stop the method doStop() is invoked. There is
>> the following code:
>>
>> doStop() {
>> [//call the real implementors to stop]
>> ...
>> if (firstExceptionThrown != null) {
>> throw firstExceptionThrown;
>> }
>> ...
>> }
>>
>> So this will throw an exception even if stopping the route works fine.
>> Therefore an exception is thrown in the context of stopping the route that
>> occured in quite normal situation - but because it is thrown there, it is
>> really thrown and leads to failures.
>>
>> I think every method needs its own variable firstExceptionThrown, to avoid
>> such cross-throwing-exception.
>>
>> Regards,
>> Siegfried Wirth
>> --
>> View this message in context:
>> http://www.nabble.com/Bug-in-ScheduledPollingConsumer--tp24151070p24151070.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
