[
https://issues.apache.org/jira/browse/CAMEL-4863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181408#comment-13181408
]
Aaron Whiteside edited comment on CAMEL-4863 at 1/6/12 4:00 PM:
----------------------------------------------------------------
That I was not aware of... Nor is it documented..
http://camel.apache.org/async.html
What is the point of waiting for the Exchange to process if you are queuing it
to a thread pool? You might as well process the exchange in the calling thread.
The end result would be the same, in fact it would be more efficient to just
process the Exchange in the calling thread... less context switches.
http://camel.apache.org/seda.html
{quote}
*Concurrent consumers*
By default, the SEDA endpoint uses a single consumer thread, but you can
configure it to use concurrent consumer threads. So instead of thread pools you
can use:
{code:lang=java}
from("seda:stageName?concurrentConsumers=5").process(...)
{code}
*Difference between thread pools and concurrent consumers*
The thread pool is a pool that can increase/shrink dynamically at runtime
depending on load, whereas the concurrent consumers are always fixed.
*Thread pools*
Be aware that adding a thread pool to a SEDA endpoint by doing something like:
{code:lang=java}
from("seda:stageName").thread(5).process(...)
{code}
Can wind up with two BlockQueues: one from the SEDA endpoint, and one from the
workqueue of the thread pool, which may not be what you want. Instead, you
might want to consider configuring a Direct endpoint with a thread pool, which
can process messages both synchronously and asynchronously. For example:
{code:lang=java}
from("direct:stageName").thread(5).process(...)
{code}
You can also directly configure number of threads that process messages on a
SEDA endpoint using the concurrentConsumers option.
{quote}
Why does the SEDA endpoint documentation recommend the usage of threads EIP as
an alternative to seda. Indeed it states that:
{quote}
The thread pool is a pool that can increase/shrink dynamically at runtime
depending on load, whereas the concurrent consumers are always fixed.
{quote}
I am very confused by your answers and the documentation. Your answer seems to
match what the test case is reproducing. But that doesn't match what the
documentation says/infers.
was (Author: aaronjwhiteside):
That I was not aware of... Nor is it documented..
http://camel.apache.org/async.html
What is the point of waiting for the Exchange to process if you are queuing it
to a thread pool? You might as well process the exchange in the calling thread.
The end result would be the same, in fact it would be more efficient to just
process the Exchange in the calling thread... less context switches.
http://camel.apache.org/seda.html
{quote}
*Concurrent consumers*
By default, the SEDA endpoint uses a single consumer thread, but you can
configure it to use concurrent consumer threads. So instead of thread pools you
can use:
from("seda:stageName?concurrentConsumers=5").process(...)
*Difference between thread pools and concurrent consumers*
The thread pool is a pool that can increase/shrink dynamically at runtime
depending on load, whereas the concurrent consumers are always fixed.
*Thread pools*
Be aware that adding a thread pool to a SEDA endpoint by doing something like:
{code:lang=java}
from("seda:stageName").thread(5).process(...)
{code}
Can wind up with two BlockQueues: one from the SEDA endpoint, and one from the
workqueue of the thread pool, which may not be what you want. Instead, you
might want to consider configuring a Direct endpoint with a thread pool, which
can process messages both synchronously and asynchronously. For example:
{code:lang=java}
from("direct:stageName").thread(5).process(...)
{code}
You can also directly configure number of threads that process messages on a
SEDA endpoint using the concurrentConsumers option.
{quote}
Why does the SEDA endpoint documentation recommend the usage of threads EIP as
an alternative to seda. Indeed it states that:
{quote}
The thread pool is a pool that can increase/shrink dynamically at runtime
depending on load, whereas the concurrent consumers are always fixed.
{quote}
I am very confused by your answers and the documentation. Your answer seems to
match what the test case is reproducing. But that doesn't match what the
documentation says/infers.
> Using <threads>/threads() is ALOT slower than using the seda:endpoint
> ---------------------------------------------------------------------
>
> Key: CAMEL-4863
> URL: https://issues.apache.org/jira/browse/CAMEL-4863
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.9.0
> Environment: JBoss 7.1 CR1b
> Reporter: Aaron Whiteside
> Assignee: Claus Ibsen
> Priority: Critical
> Labels: performance, seda, threading, threads
> Fix For: 2.10
>
> Attachments: camel-threads-vs-seda-testcase.tar.gz
>
>
> Snippets from my routing file:
> {code:xml}
> <threads maxPoolSize="10" maxQueueSize="10">
> <to uri="jms:queue:testQueue?deliveryPersistent=true"/>
> </threads>
> {code}
> compared to:
> {code:xml}
> <to uri="seda:test?concurrentConsumers=10&size=10"/>
> {code}
> {code:xml}
> <from uri="seda:test?concurrentConsumers=10&size=10"/>
> <to uri="jms:queue:testQueue?deliveryPersistent=true"/>
> {code}
> Using <threads> I get about 600 requests/per second.
> Using seda endpoint I get about 3000 requests/per second.
> Looking at the thread pools created by Camel in jconsole: I can see that the
> one created by <threads> is mostly idle as compared to the one created by the
> seda endpoint which is always busy.
> Also in the MBean Camel creates for it's managed thread pools, for the
> ThreadPool created by <threads> the TaskQueueSize attribute is almost always
> 0 and never more than 1. This is in contrast to the TaskQueueSize attribute
> on ThreadPool created by the seda endpoint which is always 10 (the seda queue
> size, and obviously until all the tasks have completed).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
