2008/9/2 RobMMS <[EMAIL PROTECTED]>:
>
>
> 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 ;)
Awesome! :) Keep the questions coming!
> 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?
Yeah. We've used the convention so far in Camel that an endpoint
itself can define its own threading policy; whether it has dedicated
Event Based Consumers,
http://activemq.apache.org/camel/event-driven-consumer.html
or a thread pool with Polling Consumers
http://activemq.apache.org/camel/polling-consumer.html
and its up to the endpoint configuration to define the exact threading
size and concurrency limits etc.
However by default the processing of a single message typically takes
place in a single thread to enable the processing to be transacted
using Spring's declarative transactions - unless you use another
endpoint to split the processing into chunks (e.g. moving some of the
processing to a separate SEDA endpoint) or making explicit use of
thread() in the route to split things asynchronously.
> 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?
Yes
> 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?
It depends on the Message Exchange Pattern (to use WSDL terminology).
http://activemq.apache.org/camel/maven/camel-core/apidocs/org/apache/camel/Exchange.html#setPattern(org.apache.camel.ExchangePattern)
http://activemq.apache.org/camel/maven/camel-core/apidocs/org/apache/camel/ExchangePattern.html
an endpoint typically attaches the message exchange pattern - be it
InOnly (a one way message) or InOut etc.
So if a message exchange is InOnly, the default with SEDA BTW - then
it will be a fire and forget. The sending thread will block until its
added to the other SEDA queue, then carry on processing the next
message.
However if you explicitly send an InOut message exchange, the sender
will block until it receives a response.
FWIW we'll probably add more message exchange operations to the DSL in
Camel 2.0 so you can make an explicit one-way or request/response
operation within the DSL to be explicit in those times you really wish
to be definitive about the kind of message exchange.
> And what is actually being processed asynchronous? Only the next
> .process(new someOther())?
Yeah - so things are typically synchronous until the route uses
thread() or a separate endpoint to split a route up into separate
pieces (i.e. the SEDA approach to threading).
> 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?
Its up to an endpoint to decide really. In JMS, they'd be totally
separate competing consumers with whatever concurrency limits and
configuration you wished.
The SEDA endpoint could process each consumer separately using its own
threadpool; or share a threadpool to process both consumers in
parallel, or invoke them both synchronously.
> 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?
Yeah - pretty much everything boils down to a processor really; unless
its an AsyncProcessor which supports asynchronous notification of
successful completion of processing.
> 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.
Great - keep them coming! :)
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
