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
