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 <helenkw...@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 >
