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.
