activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From soody <>
Subject Re: JMS pooling... pool package in activeMQ
Date Wed, 04 Feb 2009 10:10:28 GMT


To your response that as ActiveMQConnection will have a ExceptionListener
already registered against it, what will happen if after getting this
activeMQ connection from connection factory I again register a listener
against it. 

Will this exception handler super seed the already registered handler/ will
be a addition to the existing handler. If it superseeds it will I have to
explicitly handle every exception that i get now. In case it is just an
addition then what all JMS Exceptions will I be getting. Will I get an
exception, connection closed(if broker goes down and I had the broker
registered with the failover thing in the ur).

Basically if I have a exception listener registered against my connection,
so shud i be worrying about broker going down if have a faliover thing
specified in my url. I  am sure I don't need to in case I have no exception
listener registered against this connection.

Thanks for bearing with me answering till now. :)

gnodet wrote:
> 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
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message