[
https://issues.apache.org/jira/browse/CAMEL-4863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180839#comment-13180839
]
Aaron Whiteside edited comment on CAMEL-4863 at 1/5/12 9:06 PM:
----------------------------------------------------------------
As per http://camel.apache.org/async.html
{quote}
*Camel 2.4 onwards behavior*
The threads DSL leverages the JDK concurrency framework for multi threading. It
can be used to turn a synchronous route into Async. What happens is that from
the point forwards from threads the messages is routed asynchronous in a new
thread. Camel leverages the asynchronous routing engine, which was
re-introduced in Camel 2.4, to continue routing the Exchange asynchronously.
{quote}
I have attached an example which shows how using threads() DSL seems to result
in the route being executed in a single thread from the thread pool and that
the initial thread waits for the thread in the thread pool to finish before
returning...
However the example using the seda endpoint is much faster and results in all
threads in the thread pool executing the work, without the initiating thread
waiting for them to complete (except in the obvious case where the queue is
full and the initiating thread waits for a spot in the queue).
was (Author: aaronjwhiteside):
As per http://camel.apache.org/async.html
{quote}
*Camel 2.4 onwards behavior*
The threads DSL leverages the JDK concurrency framework for multi threading. It
can be used to turn a synchronous route into Async. What happens is that from
the point forwards from threads the messages is routed asynchronous in a new
thread. Camel leverages the asynchronous routing engine, which was
re-introduced in Camel 2.4, to continue routing the Exchange asynchronously.
{quote}
I have attached an example which shows how using threads() DSL seems to result
in the route being executed in a single thread from the thread pool and that
the initial thread waits for the thread in the thread pool to finish before
returning...
However the example using the seda endpoint is much faster and results in all
threads in the thread pool executing the work, without the initiating thread
waiting for them to complete.
> 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
> Priority: Critical
> Labels: performance, seda, threading, threads
> 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
