James.Strachan wrote:
>
> 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
>
>
It seems I will have to implement this for my diploma thesis, which starts
january, so if you're willing to wait till then, you'll get your
contribution ;)
But first some more questions, regarding threading in Camel...
if you've got a route like:
from("activemq:test.start").process(new someProcessor()).to(direct.foo);
from("direct.foo").process(new someOther()).to(activemq:test.end);
So here you'll have 1 Thread working down the whole route for every message
that comes in at test.start, right?
if you change the route to:
from("activemq:test.start").process(new someProcessor()).to(seda.foo);
from("seda.foo").process(new someOther()).to(activemq:test.end);
You still have 1 Thread for the route, but (currently only) one additional
thread for the seda component, that does the async processing? And what will
the Camel thread actually do? Will it block until it gets the callback from
the seda-thread, or will it continue to put exchanges in the seda's
blockingqueue and then starts doing all the things after the seda-component
when it gets a callback?
And what is actually being processed asynchronous? Only the next
.process(new someOther())? What if I have 2 processors attached to the
seda-endpoint, like
from("seda:foo").process(new ProcessorA()).process(new
ProcessorB()).to("activemq:test.end");
Will they both be processed async or only ProcessorA?
What if I use a bean-component instead of a processor, like
from("seda:foo").bean(MyBean).to("activemq:test.end"); Is the bean treated
like a processor?
I've got some more question, but for now i stick with this. I just need to
get a closer look on the mechanics inside Camel.
thx for your answers,
Rob
--
View this message in context:
http://www.nabble.com/SEDA-with-Apache-Camel-tp19107574s22882p19265633.html
Sent from the Camel - Users mailing list archive at Nabble.com.
