Hi Ted,
That's great - I must admit I was getting a bit paranoid as I've not had
any feedback on this.
I think that it is quite a way ahead of the C++ QMF2 stuff, unless
things have changed recently the C++ QMF2 stuff didn't seem to follow
the QMF2 API at all, though clearly it was using the
On 01/04/2012 12:03 PM, wolfwolfswinkel wrote:
The patch fixes my first issue (the broker not sending heartbeats).
Unfortunately the second issue persists. Now I trigger a heartbeat timeout
in the client by disconnecting a network cable. The client notices the
missing heartbeat (shows the debug
On 04/01/12 19:51, Rob Godfrey wrote:
On 4 January 2012 18:55, Ted Rosstr...@redhat.com wrote:
Users and Devs,
I'd like to make a proposal and start a discussion about the future of QMF
and Qpid broker management.
QMF (Qpid Management Framework) started out as a way to remotely manage
the
+1 - totally agree with this proposal.
- Original Message -
Users and Devs,
I'd like to make a proposal and start a discussion about the future
of
QMF and Qpid broker management.
QMF (Qpid Management Framework) started out as a way to remotely
manage
the Qpid C++ broker using
I also think that if any moves are being done, I would go further than
just bumping them into the extras directory. That still isnt all that
visible or seperate from Qpid in itself, I think the core QMF
components would collectively warrant at least sub project status with
their own release
On 05/01/12 16:28, Robbie Gemmell wrote:
I also think that if any moves are being done, I would go further than
just bumping them into the extras directory. That still isnt all that
visible or seperate from Qpid in itself, I think the core QMF
components would collectively warrant at least sub
Just to jump in on this thread.
Re
but my opinion
is that if you have millions of messages then a Message Broker is the
wrong solution to your problem - you want a Database.
I can't say I agree with Rob's assertion here!!
Well maybe that's a reasonable comment if the *intention* is to have
On 4 January 2012 22:56, Rob Godfrey rob.j.godf...@gmail.com wrote:
In terms of BDB vs. Derby performance, I wouldn't be surprised if for a
single producer / single consumer case the performance is very similar. As
Robbie highlights, really the performance here is all to do with how often
At the risk of being controversial :-)
So qpid has both C++ and Java brokers available. Out of curiosity (and
definitely not wishing to start a flame war) what's the benefit of
that strategy, particularly because AMQP is language neutral and the C++
broker acts as a very nice JMS message
On 5 January 2012 19:30, Fraser Adams fraser.ad...@blueyonder.co.uk wrote:
Just to jump in on this thread.
Re
but my opinion
is that if you have millions of messages then a Message Broker is the
wrong solution to your problem - you want a Database.
I can't say I agree with Rob's
On 5 January 2012 19:46, Fraser Adams fraser.ad...@blueyonder.co.uk wrote:
At the risk of being controversial :-)
So qpid has both C++ and Java brokers available. Out of curiosity (and
definitely not wishing to start a flame war) what's the benefit of that
strategy, particularly because
Great discussion folks; Original question Praveen posted was indeed motivated
by
A discussion we were having about how to handle unexpected loads.
In the past, I have come across producers who went awry and enqueued millions
of messages. I guess we have to start throttling the producer that
On 5 January 2012 20:08, Vijay Devadhar vdevad...@salesforce.com wrote:
Great discussion folks; Original question Praveen posted was indeed
motivated by
A discussion we were having about how to handle unexpected loads.
In the past, I have come across producers who went awry and enqueued
Yeah there are lots of interesting subtleties with this sort of thing :-)
I've got a bit of a mantra on my project handle edge cases at the
edges so my core is very simple with federated C++ brokers run on
boxes with lots of memory running nothing but C++ qpid brokers.
Which is why I've been
Thanks Rob.
I really need to have a play with the Java broker some time - I do like the C++
broker though :-)
Re
Having spent the best part of an afternoon just trying to get the C++
broker and store to build on my Ubuntu 11.10 machine... that is certainly a
huge convenience :-)
I don't
- Original Message -
On 5 January 2012 19:46, Fraser Adams fraser.ad...@blueyonder.co.uk
wrote:
At the risk of being controversial :-)
So qpid has both C++ and Java brokers available. Out of curiosity
(and
definitely not wishing to start a flame war) what's the benefit
On 5 January 2012 20:39, William Henry whe...@redhat.com wrote:
Hi Rob,
I'm sure others on this list, like myself, would be keen to hear of use
cases where the Java broker outperforms the C++ broker.
Don't get me wrong, both brokers are extremely performant... and for
transient messaging
For persistent messaging the solutions have been tuned for very different
use cases it seems, with the Java performing better when the clients are
operating in a highly synchronous manner with high levels of concurrent
connections. The C++ (on Linux) is obviously much better tuned for the
On 5 January 2012 22:56, Daryoush Mehrtash dmehrt...@gmail.com wrote:
For persistent messaging the solutions have been tuned for very different
use cases it seems, with the Java performing better when the clients are
operating in a highly synchronous manner with high levels of concurrent
On 01/04/2012 05:55 PM, Ted Ross wrote:
I'd like to make a proposal and start a discussion about the future of
QMF and Qpid broker management.
[...]
I would like to propose that we:
1. move the C++ implementation of qmf2 out of the qpid tree and into
the extras subdirectory (where the Python
That will require a little more debugging however.
I've looked at this a little bit. I have a windows client running the main.cpp
from this thread. The test I run is to let the client send the first two
messages. Then during the pause I pull the network cable. After the pause the
client
Hi Rob,
Thanks for taking a deeper look into this.
Your results are very interesting. I've not tested the case of
multiple consumers/producers and the throughput in that case for BDB. I
will try to simulate
a test and see if I can get similar results.
Thank you,
Praveen
On Thu, Jan 5, 2012 at
22 matches
Mail list logo
