qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Java broker - message grouping in C++ compatibility mode
Date Wed, 08 Jan 2014 04:22:14 GMT
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