On 09/15/2015 10:54 AM, Graham Leggett wrote:
On 15 Sep 2015, at 11:07 AM, Gordon Sim <[email protected]> wrote:
There is no standard way of doing this with AMQP 1.0 that will work for
different brokers as yet.
Though there is no simple API call, most brokers support management via
messages sent/received to a specific address and.or via HTTP, so it is possible
to programatically get the information you are looking for.
At present any code will be broker specific though. What broker are you using?
I plan to use qpid, but I’m designing an AMQP solution, not a broker specific
solution, thus the problem.
I think you would need to solve this with a system of adapters for
different brokers, providing a uniform facade over diverse management
mechanisms and schemas.
The OASIS working group for AMQP has a draft of a management spec that
covers the mechanism, but not the schema. Not sure how many brokers
actually support that yet, but for those that do you would just need to
massage the schemas. Most others offer very similar and simple
mechanisms either message based or http based.
What I am trying to avoid is a message-of-death: An entity generates a response
that is too big, and is rejected from the queue. I want the entity to be able
to ask “dear queue, are you willing to accept a message of X in size, because
if you aren’t I’m going to fail now before doing all the work only to have that
work thrown away at the end”.
This is discretely separate from the queue is full scenario, where “wait
longer” solves the problem. What I want to avoid is the problem where the
entity waits for an event (acceptance of a too large message) that will never
happen.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
