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:
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
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
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
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
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
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:
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
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
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
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 lbarn...@elinemedia.com wrote:
I’m pretty stumped here
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
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
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
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.comwrote:
Hi Helen,
The short answer to your question is that it is the documentation which is
incorrect, and the behaviour you are seeing is
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
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,
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
...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
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:
20 matches
Mail list logo
