[
https://issues.apache.org/jira/browse/CAMEL-16791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17469468#comment-17469468
]
Karen Lease commented on CAMEL-16791:
-------------------------------------
I had a look at this, using the test AggregateConcurrentPerCorrelationKeyTest
as a basis. In the current 3.15-SNAPSHOT, I don't find any behavior like
[~jeremyross] described:
{quote}I'm seeing behavior in which the aggregate appears to be absorbing
around 1,000 exchanges before letting them go. Does this pool have a queue,
perhaps of size 1,000? Or is something else causing this?
{quote}
The thread pool and its queue don't actually play a role in deciding how many
exchanges to aggregate; only the completed exchange for each aggregate is
queued via the thread pool for further processing, and this doesn't appear to
be significantly different in 3.11.0 and 3.15.
At least in the test case, the thread pool runs the completed aggregate tasks
immediately if the worker thread is not busy or queues them until the worker
thread is available. If I modify the test to specify a thread pool with a queue
size of 1 and the CallerRunsPolicy, I notice that a significant number of the
completed aggregates are in fact processed in the calling thread and not in the
thread pool, since this test generates events quickly. So I think using a
default queue of 1 is not a good idea.
> camel-core - Aggregate EIP defaults to a worker queue size of 1000
> ------------------------------------------------------------------
>
> Key: CAMEL-16791
> URL: https://issues.apache.org/jira/browse/CAMEL-16791
> Project: Camel
> Issue Type: Improvement
> Components: came-core
> Affects Versions: 3.11.0
> Reporter: Jeremy Ross
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 3.15.0
>
>
> Perhaps should default to 1, or make it easily globally configured.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
