activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Mielke (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-6519) [doc] re-work section "Pooled Consumers and Prefetch" on prefetch documentation
Date Fri, 25 Nov 2016 12:47:58 GMT

    [ https://issues.apache.org/jira/browse/AMQ-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15695787#comment-15695787
] 

Torsten Mielke commented on AMQ-6519:
-------------------------------------

I forgot to mention, CACHE_CONSUMER is a very much desired configuration in most use cases.
It cannot be used with XA transactions but works fine with local JMS transactions and non-transacted
consumers. 
The reason is that without caching the consumer in Spring, it needs to re-create a new consumer
for every single message it wants to consume.
The call to session.createConsumer() is a synchronous call against the broker, hence slows
down your overall processing performance in the client. 



> [doc] re-work section "Pooled Consumers and Prefetch" on prefetch documentation
> -------------------------------------------------------------------------------
>
>                 Key: AMQ-6519
>                 URL: https://issues.apache.org/jira/browse/AMQ-6519
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 5.14.1
>         Environment: Documentation
>            Reporter: Torsten Mielke
>            Assignee: Torsten Mielke
>            Priority: Critical
>              Labels: documentation
>
> The chapter "Pooled Consumers and Prefetch" on http://activemq.apache.org/what-is-the-prefetch-limit-for.html
is partly incorrect.
> I had a few customers getting uncertain about this section that I really think we need
to correct this. 
> While the first general part is correct:
> {quote}
> Consuming messages from a pool of consumers an be problematic due to prefetch. Unconsumed
prefetched messages are only released when a consumer is closed, but with a pooled consumer
the close is deferred (for reuse) till the consumer pool closes. This leaves prefetched messages
unconsumed till the consumer is reused. This feature can be desirable from a performance perspective.
However, it can lead to out-of-order message delivery when there is more than one consumer
in the pool. For this reason, the org.apache.activemq.pool.PooledConnectionFactory does not
pool consumers.
> {quote}
> the latter part is wrong:
> {quote}
> The problem is visible with the Spring DMLC when the cache level is set to CACHE_CONSUMER
and there are multiple concurrent consumers. One solution to this problem is to use a prefetch
of 0 for a pooled consumer, in this way, it will poll for messages on each call to receive(timeout).
Another option is to enable the AbortSlowAckConsumerStrategy on the broker to disconnect consumers
that have not acknowledged a Message after some configurable time period.
> {quote}
> Springs DMLC does not pool consumers in the sense that it uses its own pool of JMS consumers
for which it grabs an instance when consuming the next message. If it did work that way, then
it would fall under the above category and then it would be a problem.
> However Spring DMLC caches the consumer, i.e. it re-uses the same JMS consumer object
to receive all messages for the life time of the DMLC instance. So it behaves pretty much
like properly hand written JMS code, where you create the JMS connection, session, consumer
and then use this consumer instance to receive all your messages.
> If you run Spring DMLC with multiple consumer threads, then each consumer thread creates
its own JMS consumer instances and uses that to process messages. These JMS consumer instances
are not mixed between threads. 
> So there is no problem with prefetching messages to these consumers, since they are never
placed into a pool of some sort.
> On the contrary Springs CachingConnectionFactory allows to pool consumers (although off
by default) and that kind of pooling of consumers would cause the problems outlined in the
general section. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message