jms:endpoint, jms:consumer

[Learn Learn <vi...@gmail.com>]

Hi,

We are trying to use a JMS binding component within ServiceMix and have come
up with a tricky issue..We were told that the <jms:consumer> binding
component was better than a <jms:endpoint> binding component in terms of
memory usage etc...<jms:consumer> component take in concurrentConsumers and
cacheLevel attributes and they give it a huge performance boost. But, the
problem with using <jms:consumer> is that we cannot give it a defaultMep and
defaultOperation attributes that are necessary if an Apache ODE engine is
used as the next point of communication. Is there any way we can add
1) concurrentConsumers, cacheLevel attributes to a <jms:endpoint> 
OR
2) defaultMep, defaultOperation attributes to a <jms:endpoint> 

I am looking at non-programmatic ways of doing the same. We figured out how
to do it programmatically ...but that would be tweaking with binding
component code which I am not highly in favor of..

Really wonder why we should have <jms:endpoint>, <jms:consumer> to do jms
operations? Why can't it all the options just be available for
<jms:endpoint>....am i missing something?

Thanks for your help.
-- 
View this message in context: http://www.nabble.com/jms%3Aendpoint%2C-jms%3Aconsumer-tf4250483s12049.html#a12097098
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Re: jms:endpoint, jms:consumer

[mary-r <ma...@sabre.com>]

Learn Learn wrote:
> 
> Very good information there Michal..Thanks for the info..i like the EIP
> idea of turning an in-only message into a in-out message :)..
> 

The servicemix-jms BC in ServiceMix 3.1 uses temporary destinations to
handle InOut MEPs.
A temporary destination is created for a given JBI endpoint and is set in
the JMSReplyTo header. The server should honor this header and sent the
response to the specified queue. Correlation is performed using the
JMSCOrrelationId header which is set by the client and must be copied by the
server on the request. THis way, the client and the server can handle
multiple requests concurrently.
-- 
View this message in context: http://www.nabble.com/jms%3Aendpoint%2C-jms%3Aconsumer-tf4250483s12049.html#a12205145
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Re: jms:endpoint, jms:consumer

[Learn Learn <vi...@gmail.com>]

Very good information there Michal..Thanks for the info..i like the EIP idea
of turning an in-only message into a in-out message :)..
Btw, do you know of a way where we can get a multi-threaded feel to a
<jms:endpoint>? From your post, it looks like concurrentConsumers and
cacheLevel wouldn't make much sense to a jms:endpoint configuration...would
i have to manipulate the servicemix.xml/activemq.xml file for that?
Thanks again..
Vijay


Michal wrote:
> 
> I would recommend to worry about the performance in the latest stage.
> First of all you need to make sure if the given implementation meets your
> requirements. If it does not then no performance boost will recompensate
> it.
> Its hard to compare both settings cause they have many options which lead
> to many different implementations. 
> One of the difference between jms:endpoint and jms:consumer is that the
> first is mostly implemented by SM team and the latter delegates most of
> the work to Spring classes. 
> 
> Endpoint:
> ----------
> the most important parameter here is processorName. you can read about
> them here: http://incubator.apache.org/servicemix/servicemix-jms.html
> 
> consumer:
> -----------
> important ones are 'type' (or smt similar) which defines the spring
> implementation that will be used (default, simple, server). Another
> important parameter is transaction. That is actually important cause for
> example setting cache level to CONSUMER and using other than 'none' tx
> mode does not make any sense.
> 
> What I meant by saying that you should check if implementation meets your
> requirements is f.e. do you require reconnecting (f.e. if jms server is
> temporarily down)? If yes then f.e. jms:consumer with default type
> supports it. Of course, for reconnecting you might also use a
> connectionfactory which supports it (f.e. some connfactory pool that
> checks if conn is still valid).
> 
> 
> If you are a developer then the best way is to dive into the source code
> and see how the stuff works.
> 
> I hope I helped a bit
> Oh, BTW, if you want to specify mep maybe instead of doing it on jms
> endpoint you could pipe the flow using some EIP component? Thus, changing
> in-only message to in-out.
> 
> Michal
> 
> 
> 
> Learn Learn wrote:
>> 
>> Hi,
>> 
>> We are trying to use a JMS binding component within ServiceMix and have
>> come up with a tricky issue..We were told that the <jms:consumer> binding
>> component was better than a <jms:endpoint> binding component in terms of
>> memory usage etc...<jms:consumer> component take in concurrentConsumers
>> and cacheLevel attributes and they give it a huge performance boost. But,
>> the problem with using <jms:consumer> is that we cannot give it a
>> defaultMep and defaultOperation attributes that are necessary if an
>> Apache ODE engine is used as the next point of communication. Is there
>> any way we can add
>> 1) concurrentConsumers, cacheLevel attributes to a <jms:endpoint> 
>> OR
>> 2) defaultMep, defaultOperation attributes to a <jms:endpoint> 
>> 
>> I am looking at non-programmatic ways of doing the same. We figured out
>> how to do it programmatically ...but that would be tweaking with binding
>> component code which I am not highly in favor of..
>> 
>> Really wonder why we should have <jms:endpoint>, <jms:consumer> to do jms
>> operations? Why can't it all the options just be available for
>> <jms:endpoint>....am i missing something?
>> 
>> Thanks for your help.
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/jms%3Aendpoint%2C-jms%3Aconsumer-tf4250483s12049.html#a12099923
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Re: jms:endpoint, jms:consumer

[Michal <ca...@yahoo.com>]

I would recommend to worry about the performance in the latest stage. First
of all you need to make sure if the given implementation meets your
requirements. If it does not then no performance boost will recompensate it.
Its hard to compare both settings cause they have many options which lead to
many different implementations. 
One of the difference between jms:endpoint and jms:consumer is that the
first is mostly implemented by SM team and the latter delegates most of the
work to Spring classes. 

Endpoint:
----------
the most important parameter here is processorName. you can read about them
here: http://incubator.apache.org/servicemix/servicemix-jms.html

consumer:
-----------
important ones are 'type' (or smt similar) which defines the spring
implementation that will be used (default, simple, server). Another
important parameter is transaction. That is actually important cause for
example setting cache level to CONSUMER and using other than 'none' tx mode
does not make any sense.

What I meant by saying that you should check if implementation meets your
requirements is f.e. do you require reconnecting (f.e. if jms server is
temporarily down)? If yes then f.e. jms:consumer with default type supports
it. Of course, for reconnecting you might also use a connectionfactory which
supports it (f.e. some connfactory pool that checks if conn is still valid).


If you are a developer then the best way is to dive into the source code and
see how the stuff works.

I hope I helped a bit
Oh, BTW, if you want to specify mep maybe instead of doing it on jms
endpoint you could pipe the flow using some EIP component? Thus, changing
in-only message to in-out.

Michal



Learn Learn wrote:
> 
> Hi,
> 
> We are trying to use a JMS binding component within ServiceMix and have
> come up with a tricky issue..We were told that the <jms:consumer> binding
> component was better than a <jms:endpoint> binding component in terms of
> memory usage etc...<jms:consumer> component take in concurrentConsumers
> and cacheLevel attributes and they give it a huge performance boost. But,
> the problem with using <jms:consumer> is that we cannot give it a
> defaultMep and defaultOperation attributes that are necessary if an Apache
> ODE engine is used as the next point of communication. Is there any way we
> can add
> 1) concurrentConsumers, cacheLevel attributes to a <jms:endpoint> 
> OR
> 2) defaultMep, defaultOperation attributes to a <jms:endpoint> 
> 
> I am looking at non-programmatic ways of doing the same. We figured out
> how to do it programmatically ...but that would be tweaking with binding
> component code which I am not highly in favor of..
> 
> Really wonder why we should have <jms:endpoint>, <jms:consumer> to do jms
> operations? Why can't it all the options just be available for
> <jms:endpoint>....am i missing something?
> 
> Thanks for your help.
> 

-- 
View this message in context: http://www.nabble.com/jms%3Aendpoint%2C-jms%3Aconsumer-tf4250483s12049.html#a12098081
Sent from the ServiceMix - User mailing list archive at Nabble.com.