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.
