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 Wed, 23 Nov 2011 11:16:10 GMT
Sure, take a look at

http://camel.apache.org/activemq.html

especially the part on connection pooling, which essential for efficient
usage of resources.

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 Tue, Nov 22, 2011 at 8:40 PM, Jason Dillon <jason@planet57.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message