You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Doug Douglass <do...@gmail.com> on 2009/01/22 21:27:14 UTC

understanding SEDA and Thread processor

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

Re: understanding SEDA and Thread processor

Posted by Doug Douglass <do...@gmail.com>.
Thanks Roman for the JIRA link.

My question initially came from experimenting with trying to provide
multiple threads around the http component to increase throughput. I admit
I'm having some general confusion trying to get the thread processor to
behave "the way I think it should". Since I was attempting a premature
performance optimization for my project, I've since removed the thread
processor, but may need to revisit after observing the system with real
world loads.

Cheers,
Doug

On Wed, Feb 4, 2009 at 9:35 AM, Roman Kalukiewicz <
roman.kalukiewicz@gmail.com> wrote:

> 2009/2/3 huntc <hu...@mac.com>:
> >
> > 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.
>
> I even created such a JIRA:
>
> https://issues.apache.org/activemq/browse/CAMEL-1297
>
> In fact it is almost done, but I have to access a box that I was
> working on to commit this thing ;)
>
> Roman
>

Re: understanding SEDA and Thread processor

Posted by Roman Kalukiewicz <ro...@gmail.com>.
2009/2/3 huntc <hu...@mac.com>:
>
> 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.

I even created such a JIRA:

https://issues.apache.org/activemq/browse/CAMEL-1297

In fact it is almost done, but I have to access a box that I was
working on to commit this thing ;)

Roman

Re: understanding SEDA and Thread processor

Posted by huntc <hu...@mac.com>.
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?
-- 
View this message in context: http://www.nabble.com/understanding-SEDA-and-Thread-processor-tp21612576s22882p21817985.html
Sent from the Camel - Users mailing list archive at Nabble.com.