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
