understanding SEDA and Thread processor

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

understanding SEDA and Thread processor

Doug Douglass-3
Hello all,

I'm looking for some advice regarding SEDA and threads (camel 1.5.0). I'd
like to be able to use multiple threads to pull from a SEDA component.

I've read the SEDA docs[1] including the section about Thread Pools[2], but
I'm not quite able to get the behavior I want/expect.

I've started with the following (simplified) configuration:

<route>
  <from uri="timer://poller?period=10000" />
  <to uri="seda:events" />
</route>

<route>
  <from uri="seda:events"/>
  <idempotentConsumer messageIdRepositoryRef="eventIdRepository">
    <el>${in.body.eventInstanceId}</el>
    <thread name="Event Thread Processor" coreSize="3" maxSize="5">
      ...do some slow stuff...
    </thread>
  </idempotentConsumer>
</route>

This results in only 1 "Event Thread Processor" thread. The polling is
asynchronous, as expected, but the idempotentConsumer only pulls from
seda:events when the thread processor completes.

Per the SEDA Thread Pools section[2] I did try using direct with a thread
pool:

<route>
  <from uri="timer://poller?period=10000" />
  <to uri="direct:events" />
</route>

<route>
  <from uri="direct:events"/>
  <thread name="Event Thread Processor" coreSize="3" maxSize="5">
    <idempotentConsumer messageIdRepositoryRef="eventIdRepository">
      <el>${in.body.eventInstanceId}</el>
        ...do some slow stuff...
    </idempotentConsumer>
  </thread>
</route>

But this results in the polling timer blocking until the thread processor
completes, which I suppose is somewhat expected looking at it now.

Do I need to use both a SEDA component and direct as in
timer->SEDA->direct->thread?

TIA,
Doug

[1] http://camel.apache.org/seda.html
[2] http://camel.apache.org/seda.html/#SEDA-Threadpools
Reply | Threaded
Open this post in threaded view
|

Re: understanding SEDA and Thread processor

huntc
I think that what you're looking for is something akin to the "concurrentConsumers" parameter for a JMS endpoint.

My recommendation is to raise a JIRA request for an enhancement so that the SEDA endpoint can receive a concurrentConsumers parameter. After all seems to me that using SEDA is a poor-mans JMS endpoint.

Anyone agree/disagree?