...and just to be super clear, though I think it it is mentioned correctly in the docs this time, the 'default group' concept does not apply in the regular / 'non shared' grouping mode. Messages that dont specify a group key value in that mode are simply not grouped in any way.
On 8 January 2014 04:41, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > > On 8 January 2014 04:33, Helen Kwong <helenkw...@gmail.com> wrote: > >> 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. > > > No, I just missed that you said 0.16 and assumed 0.24 was the version you > were using . You could always change it, just in more limited ways in > earlier releases. > > 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? > > > Correct > > >> 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? >> >> > Yes. In the C++/shared-groups mode every message is considered to be in a > group, it is just a case of whether the message specifies that group or > instead gets put into the default group. > > > >> Thanks, >> Helen >> >> >> On Tue, Jan 7, 2014 at 8:22 PM, Robbie Gemmell <robbie.gemm...@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 <helenkw...@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.gemm...@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 <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 >> > > > > >> > > > >> > > >> > >> > >
