The camel-jms component can be used to consume and produce msgs. But Camel itself does not pool or cache anything. It depends on the underlying Spring DefaultMessageListenerContainer and connection factory to provide pooling. The Camel installation has a jms example in examples/camel-example-jms-file that can serve as a starting point.
Hope this helps. Torsten Mielke tors...@fusesource.com tmie...@blogspot.com On Nov 22, 2011, at 8:40 PM, Jason Dillon wrote: > Is there any Camel component which could be used here to perform the hand off > of an event to a thread to encode into message and publish to a topic which > would perform optimally? > > --jason > > > On Nov 18, 2011, at 2:27 AM, Dejan Bosanac wrote: > >> Hi Jason, >> >> those operations are costly and if your component must open/close it for >> every message it will affect performances. In those cases it is recommended >> to use pool connection factory which caches those object and improve >> performances. >> >> See http://activemq.apache.org/jmstemplate-gotchas.html for some more info >> on this topic (in case of Spring) >> >> Regards >> -- >> Dejan Bosanac - http://twitter.com/dejanb >> ----------------- >> The experts in open source integration and messaging - http://fusesource.com >> ActiveMQ in Action - http://www.manning.com/snyder/ >> Blog - http://www.nighttale.net >> >> >> On Fri, Nov 18, 2011 at 1:30 AM, Jason Dillon <ja...@planet57.com> wrote: >> >>> I'm wondering what sort of overhead there is to create and then close) the >>> components needed to send a message, specifically after you have a started >>> connection and using a vm:// transport. >>> >>> I'm working on implementing distributed eventing for a server which >>> already has its own eventing built-in (so adapting its events to JMS >>> messages published to topics). The events can come from any thread and be >>> sent to different topics based source event details. That seems to mean >>> that for each local event I have to: >>> >>> 1) reference destination >>> 2) create session >>> 3) create producer >>> 4) build message for event and send >>> 5 ) close producer and session (discard destination) >>> >>> #1 looks like its just object creation, but has some parsing of physical >>> name (quite a few ops as it looks like)... so could potentially cache these >>> (trade a bit of memory for a string lookup over always creating new >>> instance)? >>> >>> Not sure what overhead there is for #2, #3 or #5. Is there any >>> documentation on roughly what these operations cost? >>> >>> The destination + session could change so #3 would have to be done >>> anyways, hopefully its cheap? If #2 is not super cheap, then perhaps its >>> better to have the local event handler queue up the publish in a >>> BlockingQueue (or similar) so that a single thread + session (or >>> potentially small pool of thread+session) could be used to a actually >>> perform the publish? >>> >>> Does anyone have any insight on to what would be best option for least >>> overhead for this use-case? >>> >>> --jason >
