[rabbitmq-discuss] Two questions: max bindings and handling noconsumer present

[Bell, Paul M.]

Tim and Matthias,

Thank you for your replies. Sorry I didn't get back to you sooner.

I do understand that the instant I determine (query the infrastructure) that the consumer is up, it might go down.

I am trying to prevent a "job start" message from being published when there is no consumer to receive that message. In the normal course of events, with the consumer up, receipt of such a message would cause the consumer to run the job requested by the message.

It is far more preferable to complain up front that there is no consumer (and that therefore the job won't be run) than it is to have the broker silently discard the message.

I will think about the alternative routing topologies Matthias suggests. But what's wrong with using the mandatory flag - is it not applicable for the case I describe?

Cordially,

Paul

-----Original Message-----
From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Matthias Radestock
Sent: Wednesday, August 01, 2012 4:09 AM
To: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] Two questions: max bindings and handling noconsumer present

On 01/08/12 08:23, Tim Watson wrote:
>
> On 1 Aug 2012, at 04:10, "Bell, Paul M." <pbell at syncsort.com> .
>>
>> I suppose this is where the "mandatory" flag comes in. But I'm
>> wondering if there's a way to query  the broker about its
>> infrastructure, e.g., the existence of a queue/binding that would
>> indicate the presence of the consumer.
>>
>
> There are ways to query the infrastructure, but these rare generally
> not exposed to client APIs. What client are you using?

Moreover, performing such a "does a consumer exists?" query before
publishing is racy, since the consumer might well vanish between the
query and the publishing event.

What are you actually trying to accomplish? Is the idea that in the
absence of consumers the producer would hang on to the message and retry
later? In that case you may want to consider alternative routing
topologies. E.g. perhaps the consumer queues could be declared ahead of
time. Or you could use an alternate exchange to route messages to
holding queue where they are then picked up from consumers when they
join. Or you could do something even more sophisticated and configure
said holding queue with a message-ttl and set the original exchange as
the dead-letter exchange of the queue - that way messages will be
retried periodically automatically.

Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss



ATTENTION: -----

The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other  confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.