qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Helen Kwong <helenkw...@gmail.com>
Subject Re: Java broker - message grouping in C++ compatibility mode
Date Wed, 08 Jan 2014 04:33:56 GMT
Oh I see, I thought what you meant was that I could only alter the default
group in shared-groups mode starting with 0.24. To make sure I'm
understanding this correctly -- changing the the default message group name
to something else in C++ mode won't change the serial processing behavior I
saw, right? Messages without a group identifier will still be considered to
be in a group -- rather than no group -- and they cannot be processed by
multiple consumers concurrently?

Thanks,
Helen


On Tue, Jan 7, 2014 at 8:22 PM, Robbie Gemmell <robbie.gemmell@gmail.com>wrote:

> I just noticed you said you were using 0.16, somehow glossed over it
> originally and only noticed the 0.24 in the doc URL (its many hours past
> time I was asleep, I might be getting tired).
>
> Realising that, I should add that prior to 0.22 the only way to alter the
> default group in the shared-groups mode from 'qpid.no-group' to something
> else would have been via the 'qpid.default-message-group' queue declare
> argument when using an AMQP client to create the queue originally, and for
> 0.22 itself only that and the system property approach I mentioned would
> work.
>
> Robbie
>
> On 8 January 2014 04:03, Helen Kwong <helenkwong@gmail.com> wrote:
>
> > Hi Robbie,
> >
> > I see. Thanks for the quick response and explanation!
> >
> > Helen
> >
> >
> > On Tue, Jan 7, 2014 at 7:43 PM, Robbie Gemmell <robbie.gemmell@gmail.com
> > >wrote:
> >
> > > Hi Helen,
> > >
> > > The short answer to your question is that it is the documentation which
> > is
> > > incorrect, and the behaviour you are seeing is expected.
> > >
> > > The long answer is, when that documentation was composed a segment was
> > > missed out indicating this, and needs to be added to the docs. The
> > > behaviour listed for when no group is specified is only true of the
> > > 'non-shared' groups supported by the Java broker, in the C++/shared
> group
> > > mode any messages recieved without an explicit group value are all
> > assigned
> > > to a default group of 'qpid.no-group'. This is as per the behaviour of
> > the
> > > C++ broker itself, which is explained in the C++ broker docs at the end
> > of
> > > the following page
> > >
> > >
> >
> http://qpid.apache.org/releases/qpid-0.24/cpp-broker/book/Using-message-groups.html
> > > .
> > > For the 0.24 Java broker, this default shared group can be changed
> > > broker-wide using the Java system property
> > > 'qpid.broker_default-shared-message-group', or can be overriden for an
> > > individual queue during creation programatically via AMQP clients or
> the
> > > management interfaces through use of the argument
> > > 'qpid.default-message-group' or 'messageGroupDefaultGroup'.
> > >
> > > I coincidentally happened to have fixed a defect with the shared groups
> > > functionality last night on trunk. Its not yet included in the imminent
> > > 0.26 release, though I am about to request whether that is possible.
> > > https://issues.apache.org/jira/browse/QPID-5450
> > >
> > > Robbie
> > >
> > > On 8 January 2014 02:43, Helen Kwong <helenkwong@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > I use the Java broker and client, version 0.16, and am considering
> > using
> > > > the message grouping feature (
> > > >
> > > >
> > >
> >
> http://qpid.apache.org/releases/qpid-0.24/java-broker/book/Java-Broker-Queues.html#Java-Broker-Queues-OtherTypes-Message-Grouping
> > > > ).
> > > > From testing I've done, there seems to be a bug with the C++
> > > compatibility
> > > > model, and I'm wondering if this is a known issue. Specifically, in
> my
> > > test
> > > > I have a queue configured to use a group header field with
> > > > "qpid.group_header_key" and C++ mode with "qpid.shared_msg_group",
> and
> > > have
> > > > multiple listeners to the queue. Each listener will sleep for a short
> > > > amount of time when it receives a message before returning. I then
> > > enqueue
> > > > 10 messages that do not have a value in the group header field to the
> > > > queue. Since the doc says that messages without a value in the
> grouping
> > > > header will be delivered to any available consumer, the behavior I
> > expect
> > > > is that the messages will be processed in parallel, i.e., when
> > listener 1
> > > > is holding on to a message and sleeping, listener 2 can receive
> another
> > > > message from the queue. But what I see is that the messages are
> > processed
> > > > serially -- message 2 won't be received by some thread until message
> 1
> > is
> > > > done. When I use the default mode instead of C++ mode, then I get the
> > > > parallel processing behavior.
> > > >
> > > > Is this is a known bug, and is there a fix for it already?
> > > >
> > > > Thanks,
> > > > Helen
> > > >
> > >
> >
>

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