RE: Can you please help to clarify my doubts in HA cluster managing
Hi Steve, Thanks a lot for your clarifications. It is much clearer now. On top of the QPID HA Cluster, we will manage our service utilities for their own HA. Thanks & regards, Xiong -- View this message in context: http://qpid.2158936.n2.nabble.com/Can-you-please-help-to-clarify-my-doubts-in-HA-cluster-managing-tp7602265p7602368.html Sent from the Apache Qpid users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Java broker - message grouping in C++ compatibility mode
...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 wrote: > > On 8 January 2014 04:33, Helen Kwong 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 > >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 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 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
Re: Java broker - message grouping in C++ compatibility mode
On 8 January 2014 04:33, Helen Kwong 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 >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 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 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 a
Re: Java broker - message grouping in C++ compatibility mode
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 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 wrote: > > > Hi Robbie, > > > > I see. Thanks for the quick response and explanation! > > > > Helen > > > > > > On Tue, Jan 7, 2014 at 7:43 PM, Robbie Gemmell > >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 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 > > > > > > > > > >
Re: Java broker - message grouping in C++ compatibility mode
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 wrote: > Hi Robbie, > > I see. Thanks for the quick response and explanation! > > Helen > > > On Tue, Jan 7, 2014 at 7:43 PM, Robbie Gemmell >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 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 > > > > > >
Re: Java broker - message grouping in C++ compatibility mode
Hi Robbie, I see. Thanks for the quick response and explanation! Helen On Tue, Jan 7, 2014 at 7:43 PM, Robbie Gemmell 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 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 > > >
Request for inclusion in 0.26
Hi Justin, I would like to request the following fix for 0.26, to resolve a defect with the Java brokers shared message group functionality. https://issues.apache.org/jira/browse/QPID-5450 https://svn.apache.org/r1556096 The change is trivial, having the net effect of moving an existing method call inside an existing synchronized block solely when using the shared message group functionality that is misbehaving. The JIRA is currently sitting RTR with Rob but he actually indicated to me that he had already looked at it several hours before I actually asigned it to him to click the button...I'll prod him in the morning to do so :) Robbie
Re: Java broker - message grouping in C++ compatibility mode
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 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 >
Java broker - message grouping in C++ compatibility mode
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
Re: Qpid topic sessions linger
Hi Logan,
unfortunately the mailing list strips off attachments - can you raise a
JIRA for this issue (go to: https://issues.apache.org/jira/browse/QPID) and
attach your code to that?
thanks,
Rob
On 7 January 2014 22:27, Logan Barnett wrote:
> I’m pretty stumped here - I’ve went through the docs/wiki/jira as best I
> could, but couldn’t find anything on it at all - so I must be doing
> something really wrong here, apologies if I missed the doc that would have
> sorted this out.
>
> I’m trying to test various JMS features in Qpid so I can demo/pitch it to
> the rest of my team. My problem is that server-side sessions appear to
> linger long after my sessions are closed gracefully on the client side.
>
> I’ve attached my current code, which has the test for durable
> subscriptions as the active test. I’ve left commented various permutations
> I’ve tried to make things work so what I’ve attempted can be seen.
>
> When running the program, it completes successfully and demonstrates
> durable subscriptions do indeed work. No surprise there. When running the
> program again, the session.createDurableSubscriber call stalls for a while.
> Eventually it times out with this message:
>
> Exception in thread "main" javax.jms.JMSException: Error registering
> consumer: org.apache.qpid.AMQException: timed out waiting for sync:
> complete = 4, point = 9 [error code 541: internal error]
>
> On the server side, this is what I get during a failing run:
>
> 2014-01-07 12:51:06,805 INFO [IoReceiver - /127.0.0.1:51065]
> (connection.open) - [con:124(/127.0.0.1:51065)] CON-1001 : Open
> 2014-01-07 12:51:06,809 INFO [IoReceiver - /127.0.0.1:51065]
> (connection.open) - [con:124(/127.0.0.1:51065)] CON-1001 : Open :
> Protocol Version : 0-10
> 2014-01-07 12:51:07,266 INFO [IoReceiver - /127.0.0.1:51065]
> (connection.open) - [con:124(guest@/127.0.0.1:51065/default)] CON-1001 :
> Open : Client ID : subscriber : Protocol Version : 0-10 : Client Version :
> 0.24
> 2014-01-07 12:51:07,305 INFO [IoReceiver - /127.0.0.1:51065]
> (channel.create) - [con:124(subscriber@/127.0.0.1:51065/default)/ch:0]
> CHN-1001 : Create
> 2014-01-07 12:52:07,358 INFO [IoReceiver - /127.0.0.1:51065]
> (channel.close_forced) - [con:124(subscriber@/
> 127.0.0.1:51065/default)/ch:0] [con:124(subscriber@/
> 127.0.0.1:51065/default)/ch:0] CHN-1003 : Close : 405 - Cannot declare
> queue('subscriber:DurableTestSession'), as exclusive queue with same name
> declared on another session
> 2014-01-07 12:52:07,698 INFO [IoReceiver - /127.0.0.1:51065]
> (connection.close) - [Broker] [con:124(subscriber@/127.0.0.1:51065/default)]
> CON-1002 : Close
>
>
> If I go into the web manager and delete the exchanges, queues, and
> sessions, I can run everything again successfully. I can also get a
> successful rerun if I bounce the server - which I’ve seen the unit tests
> also demonstrate. If something happens to the client and it needs to
> reconnect in a short period of time, it will fail to subscribe until Qpid
> releases the session.
>
> Based on this topic name, why would it be exclusive in the first place?
> test-topic / test-durable; {create: always, assert: never, node: { type:
> topic, durable: True, x-declare: { auto-delete: True, exclusive: False}}}
>
> Thanks in advance!
>
> -Logan
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
Qpid topic sessions linger
I’m pretty stumped here - I’ve went through the docs/wiki/jira as best I could,
but couldn’t find anything on it at all - so I must be doing something really
wrong here, apologies if I missed the doc that would have sorted this out.
I’m trying to test various JMS features in Qpid so I can demo/pitch it to the
rest of my team. My problem is that server-side sessions appear to linger long
after my sessions are closed gracefully on the client side.
I’ve attached my current code, which has the test for durable subscriptions as
the active test. I’ve left commented various permutations I’ve tried to make
things work so what I’ve attempted can be seen.
When running the program, it completes successfully and demonstrates durable
subscriptions do indeed work. No surprise there. When running the program
again, the session.createDurableSubscriber call stalls for a while. Eventually
it times out with this message:
Exception in thread "main" javax.jms.JMSException: Error registering consumer:
org.apache.qpid.AMQException: timed out waiting for sync: complete = 4, point =
9 [error code 541: internal error]
On the server side, this is what I get during a failing run:
2014-01-07 12:51:06,805 INFO [IoReceiver - /127.0.0.1:51065] (connection.open)
- [con:124(/127.0.0.1:51065)] CON-1001 : Open
2014-01-07 12:51:06,809 INFO [IoReceiver - /127.0.0.1:51065] (connection.open)
- [con:124(/127.0.0.1:51065)] CON-1001 : Open : Protocol Version : 0-10
2014-01-07 12:51:07,266 INFO [IoReceiver - /127.0.0.1:51065] (connection.open)
- [con:124(guest@/127.0.0.1:51065/default)] CON-1001 : Open : Client ID :
subscriber : Protocol Version : 0-10 : Client Version : 0.24
2014-01-07 12:51:07,305 INFO [IoReceiver - /127.0.0.1:51065] (channel.create)
- [con:124(subscriber@/127.0.0.1:51065/default)/ch:0] CHN-1001 : Create
2014-01-07 12:52:07,358 INFO [IoReceiver - /127.0.0.1:51065]
(channel.close_forced) - [con:124(subscriber@/127.0.0.1:51065/default)/ch:0]
[con:124(subscriber@/127.0.0.1:51065/default)/ch:0] CHN-1003 : Close : 405 -
Cannot declare queue('subscriber:DurableTestSession'), as exclusive queue with
same name declared on another session
2014-01-07 12:52:07,698 INFO [IoReceiver - /127.0.0.1:51065]
(connection.close) - [Broker] [con:124(subscriber@/127.0.0.1:51065/default)]
CON-1002 : Close
If I go into the web manager and delete the exchanges, queues, and sessions, I
can run everything again successfully. I can also get a successful rerun if I
bounce the server - which I’ve seen the unit tests also demonstrate. If
something happens to the client and it needs to reconnect in a short period of
time, it will fail to subscribe until Qpid releases the session.
Based on this topic name, why would it be exclusive in the first place?
test-topic / test-durable; {create: always, assert: never, node: { type: topic,
durable: True, x-declare: { auto-delete: True, exclusive: False}}}
Thanks in advance!
-Logan
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
RE: Can you please help to clarify my doubts in HA cluster managing
Hi Xiong, > Thanks a lot Steve and Alan, appreciate your prompt helps. You're welcome. > I guess I have not posted my ideas clearly. Let me describe it below for your > better information. > > After going through the link provided by Alan, I realize that HA is only to > group two nodes into a cluster for high availability. Clients or Exchanges > need > to connect to virtual IP for message communication. QPID Messaging Bus > itself is HA, but Clients or Exchanges connect to QPID are not automatically > HA ready. Please correct me if my understanding is wrong. That's basically right, but Exchanges don't connect to Qpid - an Exchange is a AMQP 0-10 artifact that is managed by Qpid broker. The client connects to the broker and sends messages to an exchange. As such, the Exchange is part of the HA broker. > What we are intended to achieve is that we have two physical boxes, one > box shall have a server instance, for example a billing utility, running as > primary service provider, another box shall have an identical billing utility > running which is a hot-backup of the primary one. Messages passed to > primary instance will be processed as normal, while messages duplicated to > backup instance will be processed and update its internal status only. Once > Primary instance or primary box is down, backup instance or box will take > over. Is there any existing mechanism provided by QPID to achieve this > purpose to ease our effort? First, to run an HA cluster that can continue to function when one dies you should have at least 3 nodes. (That's a clustering issue, not limited to Qpid). Assuming you have a cluster that can continue to function when one node dies, one of the passive brokers will be promoted to primary/active and continue to provide service. Your client (billing utility) would see the connection to the broker go down. It could then be re-established when the new broker becomes active. If you are running the client on the same node as the broker, you will need to design an HA solution for the client as well. You could take advantage of the clustering facilities for this. I would recommend you study the RH clustering docs for information on your options. -Steve - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid Dispatch building dependencies
Sascha, The Python bindings for Proton are only needed for running the tests and for running the qdstat utility. Since qdstat uses AMQP, it can be installed on a separate system and used to manage/monitor dispatch over the network. So the Python Proton bindings are not needed to run Dispatch. However, Dispatch does need the python interpreter to be installed to run since it uses embedded Python code to manage the configuration and to do route computation. The fast path is pure C but the control plane (route computation) is embedded Python. -Ted On 01/07/2014 10:29 AM, Sascha Kattelmann wrote: Hi, I'm currently thinking about using the Qpid Dispatch Router in context of embedded systems. To keep the memory footprint as low as possible I'd like to avoid installing Python for running the dispatch router. The release note http://svn.apache.org/repos/asf/qpid/dispatch/trunk/doc/book/release-0.1.md states that "Qpid Proton version 0.6 must be installed (including the Python bindings) to build Qpid Dispatch". I just want to get sure that Python (and less important: Proton) is just a building dependency. Is that true? -Sascha - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Initial Release of Dispatch (0.1 RC5)
On Tue, Jan 07, 2014 at 09:42:39AM -0500, Ted Ross wrote: > I am re-starting the vote on the initial release of the Qpid > Dispatch message router. This vote is to use RC5 as the official > 0.1 release. > > Source location: > > http://people.apache.org/~tross/qpid-dispatch-0.1rc5/ > > Documentation: > > http://qpid.apache.org/components/dispatch-router/index.html > > Notes for version 0.1: > > http://qpid.apache.org/components/dispatch-router/release-0.1.html > > Please note that this version of Dispatch requires Proton 0.6 and > will be released pending this vote and the successful release of > Proton 0.6. > > Please register your vote. I will keep the voting open for at least > 72 business hours. > > [X] Yes, release Dispatch 0.1 RC5 as 0.1 > [ ] No, do not release for the following reasons: > > -Ted > -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpEReD1lox_d.pgp Description: PGP signature
RE: Ubuntu packages for Qpid 0.24
I have some experience with supporting a customer with fairly demanding messaging needs and they were using the active-active cluster mechanism. They're very happy to be on active-passive now. If you'd like to talk further about why you think active-active is a better choice, I'd be happy to discuss here or privately - whichever you prefer. -Steve > -Original Message- > From: Listas@Adminlinux [mailto:lis...@adminlinux.com.br] > Sent: Tuesday, January 07, 2014 9:03 AM > To: users@qpid.apache.org > Subject: Re: Ubuntu packages for Qpid 0.24 > > > In my company we chose Qpid because your active-active cluster feature. > This is important in our environment. But the Qpid-0.24 only supports active- > passive cluster. > > Does support for active-active cluster will come back in the future? > Thanks! > > Em 02-01-2014 17:51, Andrew Stitcher escreveu: > > On Thu, 2014-01-02 at 16:54 -0200, Listas@Adminlinux wrote: > >> Hi, > >> > >> I'm trying to generate Qpid-0.24 packages for Ubuntu 12.04. > >> > >> It was configured as follows: > >>./configure --with-sasl --with-xml --with-rdma --with-ssl > >> --with-swig --libexecdir='/usr/lib' --enable-fast-install > >> --enable-deprecated-autotools > >> > >> But some plugins are not compiled: sslconnector.so for client; > >> acl.so, cluster.so, replicating_listener.so, replication_exchange.so, > >> ssl.so and watchdog.so for daemon. > >> > > These changes are what you should expect for 0.24: > > > > The ssl and acl plugins have been directly subsumed by the qpidd > > executable and so are no longer plugins. > > > > The old active-active clustering has been replaced with active-passive > > in a completely new implementation. This removed the other plugins and > > added a new plugin - ha.so > > > > If you are generating new packages you will need to adjust the > > packaging specification it to take account of this change in files. > > > > Andrew > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For > > additional commands, e-mail: users-h...@qpid.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional > commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Qpid Dispatch building dependencies
Hi, I'm currently thinking about using the Qpid Dispatch Router in context of embedded systems. To keep the memory footprint as low as possible I'd like to avoid installing Python for running the dispatch router. The release note http://svn.apache.org/repos/asf/qpid/dispatch/trunk/doc/book/release-0.1.md states that "Qpid Proton version 0.6 must be installed (including the Python bindings) to build Qpid Dispatch". I just want to get sure that Python (and less important: Proton) is just a building dependency. Is that true? -Sascha - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Does support for active-active cluster will come back in the future?
On 01/07/2014 09:02 AM, Listas@Adminlinux wrote: Hi, In my company we have a "ubuntu12.04 + qpidd-0.14-2 + qpidd-msgstore-0.14-1" cluster. We chose Qpid because your active-active cluster feature. This is important in our environment. But the Qpid-0.24 only supports active-passive cluster. Does support for active-active cluster will come back in the future? At the moment there is no plan to bring back the active-active cluster feature as it was. Can you give a bit more detail on what you are trying to do? Perhaps there is a way to address your use case with the active-passive cluster or some extension of it. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[VOTE] Initial Release of Dispatch (0.1 RC5)
I am re-starting the vote on the initial release of the Qpid Dispatch message router. This vote is to use RC5 as the official 0.1 release. Source location: http://people.apache.org/~tross/qpid-dispatch-0.1rc5/ Documentation: http://qpid.apache.org/components/dispatch-router/index.html Notes for version 0.1: http://qpid.apache.org/components/dispatch-router/release-0.1.html Please note that this version of Dispatch requires Proton 0.6 and will be released pending this vote and the successful release of Proton 0.6. Please register your vote. I will keep the voting open for at least 72 business hours. [ ] Yes, release Dispatch 0.1 RC5 as 0.1 [ ] No, do not release for the following reasons: -Ted
Re: Ubuntu packages for Qpid 0.24
In my company we chose Qpid because your active-active cluster feature. This is important in our environment. But the Qpid-0.24 only supports active-passive cluster. Does support for active-active cluster will come back in the future? Thanks! Em 02-01-2014 17:51, Andrew Stitcher escreveu: On Thu, 2014-01-02 at 16:54 -0200, Listas@Adminlinux wrote: Hi, I'm trying to generate Qpid-0.24 packages for Ubuntu 12.04. It was configured as follows: ./configure --with-sasl --with-xml --with-rdma --with-ssl --with-swig --libexecdir='/usr/lib' --enable-fast-install --enable-deprecated-autotools But some plugins are not compiled: sslconnector.so for client; acl.so, cluster.so, replicating_listener.so, replication_exchange.so, ssl.so and watchdog.so for daemon. These changes are what you should expect for 0.24: The ssl and acl plugins have been directly subsumed by the qpidd executable and so are no longer plugins. The old active-active clustering has been replaced with active-passive in a completely new implementation. This removed the other plugins and added a new plugin - ha.so If you are generating new packages you will need to adjust the packaging specification it to take account of this change in files. Andrew - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Does support for active-active cluster will come back in the future?
Hi, In my company we have a "ubuntu12.04 + qpidd-0.14-2 + qpidd-msgstore-0.14-1" cluster. We chose Qpid because your active-active cluster feature. This is important in our environment. But the Qpid-0.24 only supports active-passive cluster. Does support for active-active cluster will come back in the future? Thanks! -- Thiago Henrique www.adminlinux.com.br - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
