GS.Chandra N wrote:
Thanks for the detailed reply Rafael. Might i ask for some clarification on
the answers provided -
Rafael Schloming <[email protected]> wrote:
One of the message properties is a free-form map you can use like this:
mp = session.message_properties(application_headers={"my_field": val, ...})
Are these the top level application headers that can be used to subscribe
messages, that can be used in amq.match headers exchange? If so how i read
them off, in the other end?
Yes, the headers exchange operates on the application_headers map. You
can access them this way:
msg_props = message.get("message_properties")
app_hdrs = msg_props.application_headers
4.is there any api that creates a new queue and connects directly to the
destination without this being explictly handled in the code?
What exactly do you mean by connect? Publish? Subscribe? Bind?
hmmm I was comparing the subscriber code with that of the publisher. It
seemed as if the publisher was a lot more simpler due to the fact it was not
creating any queues / binding to the exchange etc. How does message transfer
work without queues at the publisher?
Actually, even in the simple publish scenario the queue is actually
present on publish as well. It's specified in the routing_key and it
tells the default exchange where to put the message.
I was thinking on the same line for clients - like have an invisible default
queue / session itself for all incoming data, if no explicit queue name is
specified in the subscription api's. It would make for a simpler model for
the first timer especially if they do not need multiple queues.
We could certainly add some API for dispatching all the incoming
messages from distinct server queues into a single local queue or
listener. Is this what you're thinking?
Will multiple queues help me in scaling? Is it possible to do the queue.get
from multiple threads without having an underlying lock, synchronizing it?
Multiple server queues may depending on your app, but I wouldn't expect
multiple client queues to be a huge factor one way or another.
I believe there is a qpid-queue-stats command that will report things like
the enqueue/dequeue statistics on the console. For the client end you'd have
to track your own statistics.
hmmm yes - is there a plan for any future releases to address this ? It
would have been cool if the same qpid-tool could connect to the clients too
and get the details required off them. It would make management simpler. The
project that i'm investigating qpid for would have MANY dsitributed
processes and it would be impossible to maintain it without some tool that
can periodically read off the stats and alert the user. Do the client
libraries publish some sort of stats?
No. I'd be a hesitant to make the clients automatically publish stats,
but I could imagine tracking some stats in the library and making them
available to the application to publish if/when it chooses.
--Rafael
g
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
