2008/8/25 RobMMS <[EMAIL PROTECTED]>:
>
> Hi guys, thanks for your answers so far...
>
>
> James.Strachan wrote:
>>
>>
>> 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;
>> }
>> }
>>
>
> That was exactly what i was looking for!
>
>
>
> James.Strachan wrote:
>>
>>
>> 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 :)
>>
>>
>
> So, is it planned to be added for one of the next releases?
> Or could you give me some hints how this could be implemented? I guess the
> main issue here is to synchronize the concurrent polling of the
> BlockingQueue?
>
>
>
> James.Strachan wrote:
>>
>>
>> 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
>>
>>
>
> Ok, but we could "simulate" a Ressource Controller somehow with using Camel
> routing/error handling.
>
>
>
> James.Strachan wrote:
>>
>>
>> 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)
>> {
>>
>>
>
> Ok, basically this would be possible, too, I guess.
>
>
>
> James.Strachan wrote:
>>
>>
>>> 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?
>>
>
>
> Maybe we can conclude that there is quite a bit of work to do to get a
> "real" SEDA thing running ;-)
> Nevertheless I think it's worth investing some time into that, or do you
> have any alternatives that would serve as well as SEDA here?
I don't think it'd be that much work to create a SEDA endpoint
implementation that was capable of using a thread pool to support
concurrent processing of requests; I can see folks wanting it. Fancy
taking a stab at trying to implement it? :)
http://activemq.apache.org/camel/contributing.html
we love contributions! :)
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
