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 <antoine.dessai...@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: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
