You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by soody <at...@gmail.com> on 2009/02/03 15:55:02 UTC
JMS pooling... pool package in activeMQ
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 s.th 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: http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21811493.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: JMS pooling... pool package in activeMQ
Posted by soody <at...@gmail.com>.
Hey
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 <at...@gmail.com> 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
> http://activemq.apache.org/failover-transport-reference.html
>
>>
>> 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 <at...@gmail.com> 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 s.th 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:
>>>> http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21811493.html
>>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21817781.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
--
View this message in context: http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21827608.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: JMS pooling... pool package in activeMQ
Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, Feb 3, 2009 at 21:07, soody <at...@gmail.com> 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
http://activemq.apache.org/failover-transport-reference.html
>
> 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 <at...@gmail.com> 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 s.th 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:
>>> http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21811493.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>
> --
> View this message in context: http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21817781.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: JMS pooling... pool package in activeMQ
Posted by soody <at...@gmail.com>.
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.
>Also what should be my approach for having pooling(or any thing that
improves performance) for consumers.
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.
3) Also in PooledSesion class in close method why only consumers are being
closed and not producers.
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 <at...@gmail.com> 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 s.th 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:
>> http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21811493.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
--
View this message in context: http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21817781.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: JMS pooling... pool package in activeMQ
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <at...@gmail.com> 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 s.th 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: http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21811493.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com