The parameters we had used with the original QpidBench program is as follows:
-c 1 -i 1000 -s 1024 -m both --timestamp false --message-id false
--message-cache true --persistent true --jms true
--
View this message in context:
http://apache-qpid-users.2158936.n2.nabble.com/Qpid-Java-Broker-p
Hi Robbie,
Thanks for the reply. We also didn't see much performance difference
between broker instances based on Derby store and berkeley db store. However
readings we obtained now are quite ok, here's the summary of readings we
have with Derby persistence:
We have also tinkered a little bit wit
Ok, I havent actually tried this yet, but after sneaking a look at the
code I am pretty sure I see a problem in the client specific to
transacted AMQP 0-10 sessions with prefetch=1 that would cause the
behaviour you are seeing. I'll look into it at the weekend. Time for
sleep, before 3am comes alon
Hi Robbie,
I was testing against trunk, and also, I was calling commit after my
simulated processing delay, yes.
Thanks,
Praveen
On Thu, Oct 27, 2011 at 5:11 PM, Robbie Gemmell wrote:
> Just to be clear for when I look at it...were you using trunk or 0.12
> for those tests, and presumably you w
Just to be clear for when I look at it...were you using trunk or 0.12
for those tests, and presumably you were calling commit after your
simulated processing delay?
Robbie
On 28 October 2011 00:28, Praveen M wrote:
> Hi Robbie,
>
> I was using asynchronous onMessage delivery with transacted sess
Hi Robbie,
I was using asynchronous onMessage delivery with transacted session for my
tests.
So from your email, I'm afraid it might be an issue. It will be great if you
could investigate a little on this and keep us update.
Thanks a lot,
Praveen
On Thu, Oct 27, 2011 at 11:49 AM, Robbie Gemmell
As far as I know, you need to build it yourself.
If you want a build that's supported, you could contact Red Hat to talk
about MRG.
-Steve
> -Original Message-
> From: Daniel Mounessa [mailto:dmoune...@tradeware.com]
> Sent: Wednesday, October 26, 2011 4:55 PM
> To: users@qpid.apache.org
>From the below, would I be right in thinking you were using receive()
calls with an AutoAck session? If so then you would see the behaviour
you observed as the message gets acked just before receive() returns,
which makes the broker send the next one to the client. That shouldnt
happen if you were
As Jakub mentioned, this '5 messages each' behaviour is the result of
prefetch (and your consumers being present before you started
publishing). Because the consumers had space in their prefetch buffer,
the messages were basically round-robin delivered to the clients as
they were enqueued.
The del
The reason I said that was that it takes a *lot* longer to run
some(/all) of the system tests when using the DerbyStore, but doing
some very noddy tests today with a single consumer and producer showed
there wasnt any great difference between them. Both were noticably
slower than historically, so i
Is there a built version for Linux that I could download and use or do I
need to download the source code and rebuild the qpidd?
Thanks for your help.
I've downloaded qpid from git repository
Last commit...
QPID-3504: ensure the glue for the optional bdbstore feature is part of the
broker binary package
676b55c23fafb4763a5f89586fd6a357d8783b85
I'm compiling qpid with mingw gcc version 4.4
I have the error
AI_ADDRCONFIG was not declared
T
12 matches
Mail list logo
