if DefaultMessageListenerContainer caches consumer, will it occurs situation of PooledConnectionFactory doc said

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

if DefaultMessageListenerContainer caches consumer, will it occurs situation of PooledConnectionFactory doc said

peter
In PooledConnectionFactory doc of activemq, it is said they don't cache
consumer, the reason as following:

When a consumer is complete, it is best to close it rather than return it to
a pool for later reuse: this is because, even if a consumer is idle,
ActiveMQ will keep delivering messages to the consumer's prefetch buffer,
where they'll get held until the consumer is active again.


Spring DefaultMessageListenerContainer allows you set consumer cache.

if DefaultMessageListenerContainer caches consumer, will it occurs situation
of PooledConnectionFactory doc said ?



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: if DefaultMessageListenerContainer caches consumer, will it occurs situation of PooledConnectionFactory doc said

paulgale
>if DefaultMessageListenerContainer caches consumer, will it occurs situation of PooledConnectionFactory doc said?

I don't know - or more to the point it doesn't really matter as one
should never use a pooled connection factory of any kind in
conjunction with the DMLC.

The DMLC is designed such that for it to function correctly requires
that any connection created for it by its connection factory be a
plain connection, or put another way a connection that's not pooled,
wrapped, proxied or cached. That's because the DMLC expects to be able
to manage the full lifecycle of the single connection it owns, as
created for it by its factory. This single connection, created when
the DMLC initializes, is held singleton style, for the life of the
container instance, which is typically the same as that of the
application. To manage the connection's lifecycle successfully the
DMLC must be able to receive any and all JMSExceptions raised by the
connection. When caught the DMLC will decide for itself when/how to
create a replacement connection.

However, if the connection created by the DMLC's connection factory
were a pooled connection then its possible/likely that the connection
(or the pool of which it is a member) will contain wrapping logic that
will intercept any JMSException. In part that's what a pooling
mechanism should do, in order to be self-managing, as it were. As a
result the DMLC won't see the JMSException. Instead the pooling logic
will quietly replace the bad connection with a new shiny one. This can
cause the DMLC to become confused possibly resulting in undefined
behavior, e.g., stalled consumption.

Perhaps that's not the answer you were looking for. However, once one
understands how the DMLC expects to operate one no longer has to worry
how a pooled connection factory should be used with it - just don't.
Just pass the DMLC a plain ActiveMQConnectionFactory.

Thanks,
Paul


On Fri, Jan 12, 2018 at 3:29 AM, peter <[hidden email]> wrote:

> In PooledConnectionFactory doc of activemq, it is said they don't cache
> consumer, the reason as following:
>
> When a consumer is complete, it is best to close it rather than return it to
> a pool for later reuse: this is because, even if a consumer is idle,
> ActiveMQ will keep delivering messages to the consumer's prefetch buffer,
> where they'll get held until the consumer is active again.
>
>
> Spring DefaultMessageListenerContainer allows you set consumer cache.
>
> if DefaultMessageListenerContainer caches consumer, will it occurs situation
> of PooledConnectionFactory doc said ?
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html