activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dejan Bosanac <>
Subject Re: Message Groups and long running transactions
Date Fri, 06 May 2011 07:59:12 GMT

the broker should process the message with -1 group id and release the
group. However, the problem you might have is that consumer is full doing a
long tx (as prefetch is 1) and in that case the message wouldn't be
processed until tx ends.

Dejan Bosanac -
The experts in open source integration and messaging -
ActiveMQ in Action -
Blog -

Connect at CamelOne <> May 24-26

The Open Source Integration Conference

On Thu, May 5, 2011 at 10:59 PM, rbolen <> wrote:

> We are looking at using message groups (activeMQ V5.5.0).  We are using an
> external broker also.  We have a use case where a consumer could be
> processing a long running transaction (multiple hours).
> My understanding of message groups is that a group is initially assigned to
> a specific consumer and then stays on that consumer until a message comes
> through with a -1 group sequence.  But in the case where a consumer is
> processing a long transaction for group A and the consumer also has group B
> assigned, messages for group B will have to wait for the long running group
> A message to complete.  We'd like to avoid this.
> Is it true that even if we send a group B message with sequence -1, it
> would
> only be processed after the long running transaction is complete anyway,
> thus defeating the purpose of the -1 sequence?  Or does the broker process
> it while the work on the client is being done thus freeing Group B to run
> on
> another consumer.  (We're using prefetch of 1 but we could set it to 0 if
> it
> would help.)
> Is there a recommended way to avoid this situation?  Detect the large
> payload and pre-emptively send -1 messages?  Create a new consumer
> dynamically for large loads?
> Thanks,
> Rich
> --
> View this message in context:
> Sent from the ActiveMQ - Dev mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message