[
https://issues.apache.org/jira/browse/CAMEL-4863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181439#comment-13181439
]
Claus Ibsen commented on CAMEL-4863:
------------------------------------
Just to be more clear.
The direct component is *forced* to be synchronous. The DirectConsumer do *not*
implement AsyncProcessor. That means the Camel routing engine will fallback to
being synchronous (there is a latch, which makes the thread block if needed).
So if you edited the source code and let DirectConsumer implement
AsyncProcessor, and implemented the needed logic correctly. Then you could turn
that into async mode.
But again, the point of the direct component is to be *synchronous* and thus
its forced this way.
So that means the direct consumer will wait from this point of execution, until
the async callback is done. The threads EIP will invoke the done method, when
its done processing the exchange. Which mean the direct consumer thread, will
"wake up" (from the latch) and then continue processing.
And in your unit test, you have a for loop, which sends a message to a Camel
route using the direct endpoint. That means, you use the direct component that
is forced to be synchronous. So that mean you can only send in a new message,
when the previous message has been fully processed. So it does not matter if
you use threads, or whatever to process it. It will still wait.
And yes a fully straight through processing using the same thread would be
faster, as there would be no context switching.
> 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
