activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: JMS pooling... pool package in activeMQ
Date Tue, 03 Feb 2009 20:28:45 GMT
On Tue, Feb 3, 2009 at 21:07, soody <> wrote:
> Hey
>  Thx for the reply.. after reading ur blog address i realised that i had
> already referred ur blog in this context. I guess the article was some 2
> year old article :)
>  But this tells me that you are exactly the perfect person to have all my
> doubts cleared:)
>  I am trying to implement pooling. As far as I understood from Pooling Code
> of ActiveMq, they are creating some conns, creating multiple sessions on
> them and creating one producer from each of these sessions. Is this the
> correct approach or shud we have multiple producers from each of these
> sessions.So basically this is session pooling. I don't think we are pooling
> our producers anywhere. Does making pool of producers also makes sense or is
> pooling till this level sufficient.

What happens is that a single producer is used for a pooled session.
This producer is wrapped into PooledProducer instances, hence the need
for the synchronized block you referred to.   I guess the reason is
that creating and closing a producer involves sending messages from
the client to the broker, and a producer can be used to send to any
destination (unlike a consumer), so there's no real reason to use
multiple producers.

>>Also what should be my approach for having pooling(or any thing that
> improves performance) for consumers.

That's a totally different question.  Existing things include:
  * JCA connector (using jencks for example)
  * Spring JMS layer, especially the DefaultMessageListenerContainer and related

I'm also working on a kind of message listener container with some
specific stuff inside (such as being able to asynchronously handle the
received jms message).  My work in progress also includes an ActiveMQ
specific version which is more optimized.

The main problem with consumer pooling is that if you don't consume
messages when the broker dispatches them to the consumer, they will
stay there until the consumer is closed.  So you can not really have
consumers waiting in a pool.

>  2) There is this another problem. Sorry for asking so much out of u.
>  There is this thread in nabble where s.1 had asked how to reconnect to
> activeMQ  if their broker goes down.The reply says we need to have
> failover:(tcp://localhost:61616)  as the broker url.
>  I agree with it, but I want to know that in case the broker goes down I
> guess we will be getting JMSException when we try to send messages to it. So
> if we have a exceptionListener registered against the connection then we can
> code the message listener to make sure it tries to get a new connection.
> So if that is the case how does this failover thing works, and if this
> failover thing works and i have a exceptionlistener registered will it still
> get the exception. And in what cases will the registered exception listener
> receive/won't receive the exception.

The ConnectionPool class already registers a listener and when a
problem occurs at the transport level, the connection will be
discarded and a new one will be created next time it is requested from
the pooled connection factory.
For the failover, have a look at

> 3) Also in PooledSesion class in close method why only consumers are being
> closed and not producers.

Consumers are closed to avoid having messages waiting in the consumer
forever.  Producers do not have such problems, so there is no need to
close those when the session is returned to the pool.

> gnodet wrote:
>> The block synchronizes on the message producer, which means it's here
>> in case the *same* producer is used from several different threads, so
>> it should not have much overhead when using multiple producers (which
>> would be recommand afaik).
>> For the pooling part, the first thing is that consuming messages and
>> pooling is quite incompatible usually.  The main problem is that if
>> you keep unused consumers alive, messages can be waiting on the
>> consumer and thus never be actually delivered (if you don't consumer
>> those messages or close the consumer).
>> For session / producer pooling, you should be free to use the pooled
>> connection factory.
>> On Tue, Feb 3, 2009 at 15:55, soody <> wrote:
>>> I am working on JMS pooling and have a few doubts
>>> 1)I was going through the pool package of ActiveMQ. In
>>> PooledMessageProducer
>>> we have like
>>>  // just in case let only one thread send at once
>>>        synchronized (messageProducer) {
>>>            messageProducer.send(destination, message, deliveryMode,
>>> priority, timeToLive);
>>> }
>>> in the send method.
>>> I am not sure why we need to have the send synchronized. AS far as I
>>> understand we can use as many producers from a session and send msgs in
>>> parallel from them to the same destination.... Only thing that can get
>>> messed up is there will be no order in which these msgs are sent. But I
>>> guess when we decided to use multiple threads to send msgs we have
>>> anyways
>>> made our choice to drop the sequencing order.
>>> 2)Also there has been much discussion the pooling thing but there is
>>> nothing
>>> concrete. I guess for any JMS client we can write a wrapper around the
>>> PooledConnectionFactory and other classes and make sure that we have a
>>> number of connections and a pool of sessions associated with it. We can
>>> use
>>> these for pooling.
>>> Does it make any diff if we use this for producing or consumption of
>>> msgs.
>>> Please note I am talking about a standalone JMS Client, no springs
>>> included
>>> and a pretty generic client that can work with any JMS provider.
>>> --
>>> View this message in context:
>>> Sent from the ActiveMQ - User mailing list archive at
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog:
>> ------------------------
>> Open Source SOA
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

Guillaume Nodet
Open Source SOA

View raw message