Trying to understand ServiceMix Pojos, onMessageExchange, and Threading

[William Blackburn <wj...@mac.com>]

My application is a series of Servicemix 'Pojo' components. Each  
component receives a message exchange and operates on the content  
using a synchronous call to a Spring managed service-provider wired  
into the component in servicemix.xml

I am trying to understand how this arrangement will scale, especially  
on multi-cpu servers. I guess I'm a bit out of my depth in the  
source, 'cause I can't figure out if the 'onMessageExchange' events  
are fired from separate, individual threads, a pool of threads, or a  
single message-processing thread. I want to take advantage of multi- 
processing, and certainly don't want calls to heavily loaded  
components queuing up if they don't have to.

Can anyone clarify this for me? Should I implement my own multi- 
threading within my components, or is it built in to the underlying  
message handling/routing system?

Thanks,

BJ

Re: Trying to understand ServiceMix Pojos, onMessageExchange, and Threading

[Guillaume Nodet <gn...@gmail.com>]

Components implementing MessageExchangeListener
need to be thread safe, like servlets for example.
The onMessageExchange method will be called
from multiple threads.

Components that do not implement MessageExchangeListener
need to poll the delivery channel for JBI exchanges, so they
control their own threading model.

On 9/22/06, William Blackburn <wj...@mac.com> wrote:
> My application is a series of Servicemix 'Pojo' components. Each
> component receives a message exchange and operates on the content
> using a synchronous call to a Spring managed service-provider wired
> into the component in servicemix.xml
>
> I am trying to understand how this arrangement will scale, especially
> on multi-cpu servers. I guess I'm a bit out of my depth in the
> source, 'cause I can't figure out if the 'onMessageExchange' events
> are fired from separate, individual threads, a pool of threads, or a
> single message-processing thread. I want to take advantage of multi-
> processing, and certainly don't want calls to heavily loaded
> components queuing up if they don't have to.
>
> Can anyone clarify this for me? Should I implement my own multi-
> threading within my components, or is it built in to the underlying
> message handling/routing system?
>
> Thanks,
>
> BJ
>


-- 
Cheers,
Guillaume Nodet