You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@camel.apache.org by "Siegfried.Wirth" <si...@capgemini-sdm.com> on 2009/06/22 18:44:17 UTC

Bug in ScheduledPollingConsumer?

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.

Re: Bug in ScheduledPollingConsumer? (Unit-Test added)

Posted by "Siegfried.Wirth" <si...@capgemini-sdm.com>.

Wrote a small unit test demonstrating the issue:

http://www.nabble.com/file/p24151188/ScheduledPollingConsumerIssueTest.java
ScheduledPollingConsumerIssueTest.java

Hi,

when testing some ftp functionality I found the following issue which may
indicate a bug in ScheduledPollingConsumer:

doStop() {
[//call the real implementors to stop]
...
if (firstExceptionThrown != null) {
throw firstExceptionThrown;
}
...
}

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--tp24151070p24151188.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Bug in ScheduledPollingConsumer?

Posted by "Siegfried.Wirth" <si...@capgemini-sdm.com>.

Hi,

when I read JIRA-501 and its follow-up JIRA-1260
(http://issues.apache.org/activemq/browse/CAMEL-1260) I was not sure, if
implementing this ticket really would help in this situation. The reason is
that 'polling-failed-exception' would still be thrown from 'stop-consumer'
and so the exception would be seen as critical. It woill only help if the
whole logic from 501 is replaced by sending every exception to the endpoint
/ some strategy and if no out-of-the-box support for the poller is
supported? (Basically different stragetegies are neccessary for different
mehtods and exceptions.)

Regards,
Siegfried Wirth

Claus Ibsen-2 wrote:
> 
> The original ticket for this is: CAMEL-501
> https://issues.apache.org/activemq/browse/CAMEL-501
> 

-- 
View this message in context: http://www.nabble.com/Bug-in-ScheduledPollingConsumer--tp24151070p24162039.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Bug in ScheduledPollingConsumer?

Posted by Claus Ibsen <cl...@gmail.com>.

Hi
I created a new ticket to track changing this behavior
https://issues.apache.org/activemq/browse/CAMEL-1744


On Tue, Jun 23, 2009 at 10:24 AM, Claus Ibsen <cl...@gmail.com> wrote:

> 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 <cl...@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.wirth@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
>
>


-- 
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

Re: Bug in ScheduledPollingConsumer?

Posted by Claus Ibsen <cl...@gmail.com>.

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 <cl...@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.wirth@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

Re: Bug in ScheduledPollingConsumer?

Posted by Claus Ibsen <cl...@gmail.com>.

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.wirth@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

Re: Bug in ScheduledPollingConsumer?

Posted by Claus Ibsen <cl...@gmail.com>.

Hi

I have improved this recently.
- Camel will not throw exception when stopping
- A new pluggable API for providing you own logic what to do in case
of excpetions: PollingConsumerPollStrategy

See more at:
    http://camel.apache.org/polling-consumer.html
mind that it takes 1-2 hours for the static html pages to be updated
with the dynamic wiki changes I just do



On Mon, Jun 22, 2009 at 6:44 PM,
Siegfried.Wirth<si...@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