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?
---
Rob
--
View this message in context:
http://www.nabble.com/SEDA-with-Apache-Camel-tp19107574s22882p19140167.html
Sent from the Camel - Users mailing list archive at Nabble.com.
