[
https://issues.apache.org/jira/browse/CAMEL-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13991625#comment-13991625
]
Benedikt Waldvogel commented on CAMEL-7411:
-------------------------------------------
Thanks for fixing this so quickly!
Is it also planned to backport this fix on Camel 2.12?
One nit-picky remark on your [commit
f0b8e011|https://git-wip-us.apache.org/repos/asf?p=camel.git;a=commitdiff;h=f0b8e011f29772da7d0da92852b8f70d5b31ad80]:
Why do do you use a {{LinkedBlockingDeque}} instead of a
{{LinkedBlockingQueue}}?
How do you like the idea do add one further option (e.g.
{{pollingConsumerBlockTimeout}}) which could be used to set a max wait time
before it gives up adding an exchange to the internal queue?
> EventDrivenPollingConsumer can lose exchanges when the internal queue is full
> -----------------------------------------------------------------------------
>
> Key: CAMEL-7411
> URL: https://issues.apache.org/jira/browse/CAMEL-7411
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.13.0
> Reporter: Benedikt Waldvogel
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 2.13.2, 2.14.0
>
>
> The exchange processing in the {{EventDrivenPollingConsumer}} can lose
> exchanges when the internal queue is bounded and full.
> The implementation:
> {noformat}
> public void process(Exchange exchange) throws Exception {
> queue.offer(exchange);
> }
> {noformat}
> The reason is that {{BlockingQueue.offer(...)}} is non-blocking and returns a
> boolean which indicates whether the element was added.
> However, the return value is ignored causing the exchange to get lost if it
> could not be added.
> A potential workaround is to use an unbounded BlockingQueue (e.g.
> LinkedBlockingQueue).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
