[
https://issues.apache.org/jira/browse/CAMEL-9153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904558#comment-14904558
]
Michael Riedel edited comment on CAMEL-9153 at 9/23/15 2:09 PM:
----------------------------------------------------------------
Hi [~davsclaus], thanks for your lightning-fast reply. Yes, I had the suspicion
that Camel might have some other mechanisms in place that would justify that
behavior. However, it is possible that clients will use the thread-pool as is,
and submit {{Runnable}} tasks that do not implement the {{Rejectable}}
interface.
I for instance used the Camel Spring to as a convenient way to instantiate an
{{ExecutorService}} that I then injected into my Camel
{{DefaultProducerTemplate}}. This is the Spring configuration that I had:
{code}
<threadPool id="executorService" threadName="..." rejectedPolicy="Reject" ... />
{code}
When invoking {{asyncSend(...)}} on a {{DefaultProducerTemplate}} with such an
{{ExecutorService}}, I expected an Exception would be raised when the
{{ExecutorService}} rejects the new Exchange. However, that never happened.
I worked around that by using a different {{ExecutorService}}, which I
configured without using Camel. However, I still think the behavior described
above is kind of confusing.
As a compromise, wouldn't it be possible to throw an Exception if the
{{Runnable}} task does not implement {{Rejectable}}? See my new patch...
was (Author: meeque):
Hi [~davsclaus], thanks for your lightning-fast reply. Yes, I had the suspicion
that Camel might have some other mechanisms in place that would justify that
behavior. However, it is possible that clients will use the thread-pool as is,
and submit {{Runnable}} tasks that do not implement the {{Rejectable}}
interface.
I for instance used the Camel Spring to as a convenient way to instantiate an
{{ExecutorService}} that I then injected into my Camel
{{DefaultProducerTemplate}}. This is the Spring configuration that I had:
{code}
<threadPool id="executorService" threadName="..." rejectedPolicy="Discard" ...
/>
{code}
When invoking {{asyncSend(...)}} on a {{DefaultProducerTemplate}} with such an
{{ExecutorService}}, I expected an Exception would be raised when the
{{ExecutorService}} rejects the new Exchange. However, that never happened.
I worked around that by using a different {{ExecutorService}}, which I
configured without using Camel. However, I still think the behavior described
above is kind of confusing.
As a compromise, wouldn't it be possible to throw an Exception if the
{{Runnable}} task does not implement {{Rejectable}}? See my new patch...
> ThreadPoolRejectedPolicy does not implement Abort as expected
> -------------------------------------------------------------
>
> Key: CAMEL-9153
> URL: https://issues.apache.org/jira/browse/CAMEL-9153
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: Michael Riedel
> Attachments: ThreadPoolRejectedPolicy-Abort.patch,
> ThreadPoolRejectedPolicy-AbortNonRejectable.patch
>
>
> Not sure if this is a bug or just a documentation flaw (in fact I could not
> find documentation for it). Nevertheless, as a naive user, I kind of expected
> that the {{RejectedExecutionHandler}} of {{ThreadPoolRejectedPolicy.Abort}}
> would have similar semantics as Java's {{ThreadPoolExecutor.AbortPolicy}}.
> That is, I expected it to throw an {{Exception}}.
> Currently (that is in the 2.15.2 release, and on the master branch in git)
> that is not the case. In fact, {{Abort}} seems to work exactly the same way
> as {{Discard}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
