activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dejan Bosanac <de...@nighttale.net>
Subject Re: Overhead of component creation to send message
Date Fri, 18 Nov 2011 10:27:40 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message