Discussion around the bug CAMEL-6685

[Antoine DESSAIGNE <an...@gmail.com>]

Hi everyone,

Earlier today I created a new jira issue [1] on something that I consider
is a bug. It was triaged and marked as "Not a problem". I don't agree with
this so I'm starting this discussion either to better understand why it's
not a bug or to reopen it. I thought this mailing list was a better place
for discussion than the comment section of a jira issue.

Let me explain what I did, what happened and what I was expected and why I
was expecting this.

Basically I forced the shutdown of a context that was processing a message.
And by doing that I'm aware that I may lose some data, and it's my expected
behavior.

In the console, after the shutdown you can see that the DefaultTypeConverter
is starting up and then an java.util.concurrent.RejectedExecutionException
is thrown.
But since the context is stopped, I don't want:
* the TypeConverter to start, it has no meaning since I don't want to
process any message and as far I can tell it's not cleared afterwards.
* an exception telling me that it cannot process the message, since it's
what I wanted I shouldn't have any exception.

In more real-world use-case (not this bug simple reproduction use case), I
noticed that after a force shutdown the context was still manipulating data
which I didn't want before crashing

In my opinion, if the context is stopping it should try to finish the
in-processing messages. But if the context is stopped, it shouldn't try at
all to continue.

It may not be easy to stop the processing especially when it's asynchronous
but camel should try to do so. Camel should not even try to go to the next
processor and it shouldn't throw any exception when it cannot go to the
next processor.

But maybe I don't quite understand the force shutdown feature and this is
not a bug. Can you give me your insights on this matter ?

Thanks a lot,

Antoine.

[1] https://issues.apache.org/jira/browse/CAMEL-6685

Re: Discussion around the bug CAMEL-6685

[Claus Ibsen <cl...@gmail.com>]

Hi

As said on the ticket its working as designed. When you shutdown
aggressive (eg set timeout to 1 sec) then there may be messages in
Camel that are not finished.

And if anyhow they are attempted to be continued the routing engine
throws the RejectedExecutionException. So that is why you may see that
in your logs or whatnot.


If you do not want anything to happen after the aggressive attempt to
shutdown Camel, well then your can do a System.exit or something.

There is no clean way of shutting down aggressively. So if you
shutdown then give the system some time to shutdown nicely.






On Fri, Aug 30, 2013 at 1:51 PM, Antoine DESSAIGNE
<an...@gmail.com> wrote:
> Hi everyone,
>
> Earlier today I created a new jira issue [1] on something that I consider
> is a bug. It was triaged and marked as "Not a problem". I don't agree with
> this so I'm starting this discussion either to better understand why it's
> not a bug or to reopen it. I thought this mailing list was a better place
> for discussion than the comment section of a jira issue.
>
> Let me explain what I did, what happened and what I was expected and why I
> was expecting this.
>
> Basically I forced the shutdown of a context that was processing a message.
> And by doing that I'm aware that I may lose some data, and it's my expected
> behavior.
>
> In the console, after the shutdown you can see that the DefaultTypeConverter
> is starting up and then an java.util.concurrent.RejectedExecutionException
> is thrown.
> But since the context is stopped, I don't want:
> * the TypeConverter to start, it has no meaning since I don't want to
> process any message and as far I can tell it's not cleared afterwards.
> * an exception telling me that it cannot process the message, since it's
> what I wanted I shouldn't have any exception.
>
> In more real-world use-case (not this bug simple reproduction use case), I
> noticed that after a force shutdown the context was still manipulating data
> which I didn't want before crashing
>
> In my opinion, if the context is stopping it should try to finish the
> in-processing messages. But if the context is stopped, it shouldn't try at
> all to continue.
>
> It may not be easy to stop the processing especially when it's asynchronous
> but camel should try to do so. Camel should not even try to go to the next
> processor and it shouldn't throw any exception when it cannot go to the
> next processor.
>
> But maybe I don't quite understand the force shutdown feature and this is
> not a bug. Can you give me your insights on this matter ?
>
> Thanks a lot,
>
> Antoine.
>
> [1] https://issues.apache.org/jira/browse/CAMEL-6685



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: Discussion around the bug CAMEL-6685

[Claus Ibsen <cl...@gmail.com>]

I logged a ticket about adding a new option to shutdown strategy to
configure it to suppress logging after context is shutdown.

https://issues.apache.org/jira/browse/CAMEL-6688

On Fri, Aug 30, 2013 at 2:16 PM, Claus Ibsen <cl...@gmail.com> wrote:
> If you do not want the RejectedExcutionException to be logged in the
> logs after the camelcontext has been attempted to shutdown.
>
> Then we could consider adding a new option to shutdown strategy to
> allow end users to configure that Camel should suppress logging after
> camel context has been attempted to shutdown.
>
> And to re-iterate Camel does not try to "go to the next processor"
> that is why the routing engine throws the rejected exception.
>
> On Fri, Aug 30, 2013 at 1:51 PM, Antoine DESSAIGNE
> <an...@gmail.com> wrote:
>> Hi everyone,
>>
>> Earlier today I created a new jira issue [1] on something that I consider
>> is a bug. It was triaged and marked as "Not a problem". I don't agree with
>> this so I'm starting this discussion either to better understand why it's
>> not a bug or to reopen it. I thought this mailing list was a better place
>> for discussion than the comment section of a jira issue.
>>
>> Let me explain what I did, what happened and what I was expected and why I
>> was expecting this.
>>
>> Basically I forced the shutdown of a context that was processing a message.
>> And by doing that I'm aware that I may lose some data, and it's my expected
>> behavior.
>>
>> In the console, after the shutdown you can see that the DefaultTypeConverter
>> is starting up and then an java.util.concurrent.RejectedExecutionException
>> is thrown.
>> But since the context is stopped, I don't want:
>> * the TypeConverter to start, it has no meaning since I don't want to
>> process any message and as far I can tell it's not cleared afterwards.
>> * an exception telling me that it cannot process the message, since it's
>> what I wanted I shouldn't have any exception.
>>
>> In more real-world use-case (not this bug simple reproduction use case), I
>> noticed that after a force shutdown the context was still manipulating data
>> which I didn't want before crashing
>>
>> In my opinion, if the context is stopping it should try to finish the
>> in-processing messages. But if the context is stopped, it shouldn't try at
>> all to continue.
>>
>> It may not be easy to stop the processing especially when it's asynchronous
>> but camel should try to do so. Camel should not even try to go to the next
>> processor and it shouldn't throw any exception when it cannot go to the
>> next processor.
>>
>> But maybe I don't quite understand the force shutdown feature and this is
>> not a bug. Can you give me your insights on this matter ?
>>
>> Thanks a lot,
>>
>> Antoine.
>>
>> [1] https://issues.apache.org/jira/browse/CAMEL-6685
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Re: Discussion around the bug CAMEL-6685

[Claus Ibsen <cl...@gmail.com>]

If you do not want the RejectedExcutionException to be logged in the
logs after the camelcontext has been attempted to shutdown.

Then we could consider adding a new option to shutdown strategy to
allow end users to configure that Camel should suppress logging after
camel context has been attempted to shutdown.

And to re-iterate Camel does not try to "go to the next processor"
that is why the routing engine throws the rejected exception.

On Fri, Aug 30, 2013 at 1:51 PM, Antoine DESSAIGNE
<an...@gmail.com> wrote:
> Hi everyone,
>
> Earlier today I created a new jira issue [1] on something that I consider
> is a bug. It was triaged and marked as "Not a problem". I don't agree with
> this so I'm starting this discussion either to better understand why it's
> not a bug or to reopen it. I thought this mailing list was a better place
> for discussion than the comment section of a jira issue.
>
> Let me explain what I did, what happened and what I was expected and why I
> was expecting this.
>
> Basically I forced the shutdown of a context that was processing a message.
> And by doing that I'm aware that I may lose some data, and it's my expected
> behavior.
>
> In the console, after the shutdown you can see that the DefaultTypeConverter
> is starting up and then an java.util.concurrent.RejectedExecutionException
> is thrown.
> But since the context is stopped, I don't want:
> * the TypeConverter to start, it has no meaning since I don't want to
> process any message and as far I can tell it's not cleared afterwards.
> * an exception telling me that it cannot process the message, since it's
> what I wanted I shouldn't have any exception.
>
> In more real-world use-case (not this bug simple reproduction use case), I
> noticed that after a force shutdown the context was still manipulating data
> which I didn't want before crashing
>
> In my opinion, if the context is stopping it should try to finish the
> in-processing messages. But if the context is stopped, it shouldn't try at
> all to continue.
>
> It may not be easy to stop the processing especially when it's asynchronous
> but camel should try to do so. Camel should not even try to go to the next
> processor and it shouldn't throw any exception when it cannot go to the
> next processor.
>
> But maybe I don't quite understand the force shutdown feature and this is
> not a bug. Can you give me your insights on this matter ?
>
> Thanks a lot,
>
> Antoine.
>
> [1] https://issues.apache.org/jira/browse/CAMEL-6685



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen