2008/8/22 RobMMS <[EMAIL PROTECTED]>:
>
> Hi there,
> I've got a few questions regarding SEDA and the SEDA Component in Apache
> Camel, because we want to convert our current architecture into a SEDA-based
> one, using Apache Camel. Since I'll probably going to do this as my diploma
> thesis, I'm not yet that deep into Camel and especially Spring, so please
> excuse if i might ask some "stupid" questions ;-)
>
> So what we're planning to do is to have multiple stages where we want to do
> some processing. These stages should actually be Spring Beans. We want to
> link those processing steps/stages event based (-> SEDA). Here is where
> Camel comes in.
>
> So, first question is: is it possible to do something like
> from("seda:someBean").process(new
> MyProcessingBean()).to("seda:someOtherBean");,
> where MyProcessingBean is our Spring Bean used as a processor?

Yes, definitely!

Its easier to use the bean binding - then you effectively hide the
camel APIs from your spring beans.

e.g.

from("seda:someQueue").bean("myBeanName").to("seda:AnotherQueue");

http://activemq.apache.org/camel/bean-integration.html

Where your bean looks something like

public class Bar {

    public String doSomething(String body) {
      return "Hello " + body;
   }
}

> Next question is, how is the internal seda processing actually done, because
> for me, the seda-component looks like some kind of black box, where i can
> just define a size parameter for the queue.
> As far as I know about seda each stage should consist of the following:
> - Incoming Event Queue (which can be sized by the size-parameter?)
> - Admission Controller
> - Dynamically sized Thread Pool
> - Event Handler (this would be the processor?)
> - Ressource Controller

Endpoints in Camel are all configurable; they typically inherit the
default thread pool - but you can customize that. However I note that
the current SedaConsumer assumes a single thread for processing :)
We're not yet using a threadpool for a single consumer. We should add
that :)



> Do these components really exist here, so i can control them, maybe even
> through Java DSL? or do I have to implement them on my own? and if so how
> could/should I do that?

The main missing bit is the current SEDA component assumes all
messages will be processed; there's no 'Resource Controller'. If you
want some kind of resource controller you could put a route before or
after the invocation of your bean to route the message to different
endpoints based on the message payload or whatever.

e.g. from("seda:a").filter().xpath("/whatever").bean("myBean").to("seda:b");

Similarly error handling is decoupled from the SEDA component as well
- you can attach error handlers at any point in your route - or
customize a global error handler etc.
http://activemq.apache.org/camel/error-handler.html


> So being concrete, is it possible to (dynamically) change the queue size
> and/or to restrict access to the queue and do some handling to those events
> being rejected? (this is what the Admission Controller would do).

Currently there's no support for dynamically resizing of the queue
size - but mostly thats due to the default implementation of
BlockingQueue we use - but its easy to create a different
implementation using whatever Queue implementation you want.

e.g. see the constructor

    public SedaEndpoint(String endpointUri, BlockingQueue<Exchange> queue) {



> Is it possible to notify a Ressource Controller about the queue size, so
> that he could react by, e.g. increasing the Thread Pool?
> Or is this just done internally by the SEDA-component, and I actually don't
> have to concern about that?

Its probably best to do this inside the component/endpoint
implementation; e.g. the producer can notify the queue/threadpool when
a new message has been added to the queue which could prompt an
increase of the pool.


> Would it be possible override default behaviour? (i.e. to override the
> Seda-Component)

Maybe we should have 2 implementations; the current simple 1 thread
per consumer option and another better - dynamic threadpool option?

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

Reply via email to