activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Overhead of component creation to send message
Date Tue, 22 Nov 2011 19:40:50 GMT
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 <jason@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


Mime
View raw message