Sure, take a look at http://camel.apache.org/activemq.html
especially the part on connection pooling, which essential for efficient usage of resources. 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 Tue, Nov 22, 2011 at 8:40 PM, Jason Dillon <ja...@planet57.com> 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 > >
