ft420 wrote:
thanks a lot. I tried both PRE_ACQUIRED & NOT_ACQUIRED. Is there any
performance overhead involved in any of these 2 options?
I doubt either option is as fast as the common path (which is where most
optimisation has focused so far). I'd suggest trying it out to see if it
meets the performance requirements you have and let us know what you find.
Also i wanted to know whether ACCEPT_MODE_EXPLICIT/ACCEPT_MODE_NONE has any
performance overhead?
Yes, there will be an overhead from accepting messages. However if you
do this at a wide enough interval (e.g. every 100 or so messages), it is
not that great (can't give you any precise figures though).
Is there any document available that gives performance overheads of options
that we use?
Not really. Again, probably the best things is to try out options for
your specific cases.
I was trying to declare a durable queue. I did following:
:
:
session.queueDeclare(arg::queue="myqueue", arg::durable=true);
:
:
steps ::
./qpidd -p 5004 --auth no
./my_queue //declares the queues
./my_producer // sends the messages to the queue
./browse // browses the messages
now i stop the broker i.e. ctrl+c on the cmd prompt where ./qpidd is running
start the broker again i.e. ./qpidd -p 5004 --auth no
./browse //gives error Queue not found
Do you have a persistence plugin loaded? There is no such plugin yet
available as part of the qpid project, but there is one available from:
http://anonsvn.jboss.org/repos/rhmessaging/store/trunk/cpp/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org
