activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Overhead of component creation to send message
Date Thu, 08 Dec 2011 05:10:10 GMT
Does the activemq-pool stuff cope with pooling connections, sessions and producers?  Such that
a component could access create and use these normally + close them, and under the covers
activemq-pool will do the smart thing and reuse/avoid-close?   Consumers are not pooled in
similar fashion? 

I believe ^^^ is the case, but I just wanted to confirm incase I'm misunderstanding something.


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 for some more info
> on this topic (in case of Spring)
> Regards
> -- 
> Dejan Bosanac -
> -----------------
> The experts in open source integration and messaging -
> ActiveMQ in Action -
> Blog -
> On Fri, Nov 18, 2011 at 1:30 AM, Jason Dillon <> 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

View raw message