[rabbitmq-discuss] How to catch RESOURCE_LOCKED exceptions in erlang client

Fri Aug 16 16:31:27 BST 2013

That works, of course.

I guess I was expecting that the reply would just be something containing the error, different from the #'queue.declare_ok'{} that I could match on.

Thanks again.

Mark Geib
Principal Engineer
Cheyenne Software Engineering
mark.geib at echostar.com / 35-215

“We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing.” 
― Mother Teresa

On Aug 16, 2013, at 9:17 AM, Tim Watson wrote:

> Hi Mark,
> 
> Ok - without getting buried in the details, it sounds like what you want is a simple try...catch in your code to determine whether or not the queue.declare succeeds. That's fairly simple to do, since either you'll get back a #'queue.declare-ok'{} record or an error will propagate to the caller. In the latter case, you can set off a timer to retry when you're ready:
> 
> init(Config) ->
>     {Timeout, Queue, Params} = parse_config(Config),
>     {ok, Conn} = amqp_connection:start(Params),
>     {ok, Chan} = amqp_connection:open_channel(Conn),
>     State = #state{ connection = Conn, channel = Chan, queue = Queue, timeout = Timeout, status = idle },
>     start_timer(State),
>     {ok, State}.
> 
> handle_info(connect, State = #state{ status = running }) ->
>     {noreply, State};
> handle_info(connect, State = #state{ channel = Chan, queue = Queue }) ->
>     try
>         #'queue.declare_ok'{} = amqp_channel:call(Chan, #'queue.declare{ queue = Queue, exclusive = true }),
>         {noreply, State#state{ status = running }}
>     catch _:_ ->
>         start_timer(State),
>         {noreply, State}
>     end.
> 
> start_timer(#state{ timeout = T }) ->
>     erlang:send_after(T, self(), 
> 
> 
> Hopefully that'll get you going.
> 
> Cheers,
> Tim
> 
> 
> On 08/16/2013 04:03 PM, Geib, Mark wrote:
>> Maybe more explanation will help.
>> 
>> I am trying to re-broadcast udp datagrams between different networks with a simple erlang application that listens to the specified UDP port, then publishes to a rabbitmq exchange. Then another erlang application is consuming the messages and broadcasting the datagram on whatever network is required, etc. These datagrams are near mission critical and so we are building completely, nearly, redundant paths. That is there will be two applications listening to the datagram source, both will publish to separate brokers, on different network paths. Then there will be two consumer applications each able to consume messages from both of the brokers being published to. What I need to do is prevent both consuming applications from broadcasting the datagram on the target network. We can not handle duplicates.
>> 
>> Here was my idea.
>> 
>> On the consuming client side we configure both clients the same, both brokers are listed in each config. When a client comes up it will try to connect to each broker, if those connections succeed then an attempt is made to create an exclusive queue on each broker, no bindings yet. If a client can create both exclusive queues then it will be the UDP broadcaster. At this point the client will bind one of the two queues to start receiving messages from one of the servers. The other exclusive queue is left unbound, so no messages are routed to it. The other client attempts the same, but will fail to create the exclusive queues. The connections to the two brokers will be maintained, but at some interval will continue to attempt to create the exclusive queues, if it should ever succeed then it will start broadcasting as the first client did. So in order to broadcast one of these applications must create both exclusive queues. What I was depending on was being able to use the exclus
>>  ive queue
>>  as a sort of resource lock, but not do any bindings or consuming until I am sure I have "locked" all the brokers.
>> 
>> The case where one of the brokers is down, or un-reachable is handled by the clients where the connection attempt to that broker will fail, so the client assumes it is not useable, but is able to connect and create the exclusive queue on the other broker. In this case the client will be the broadcaster, since it is able to create the exclusive queue on all "available" brokers. Even if the other client is able to connect to both brokers it will not be able to create the exclusive queues on both, so will not broadcast.
>> 
>> Hope that helps.
>> 
>> Mark Geib
>> Principal Engineer
>> Cheyenne Software Engineering
>> 
>> mark.geib at echostar.com
>>  / 35-215
>> 
>> 
>> “We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing.” 
>> ― Mother Teresa
>> 
>> 
>> 
>> 
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> 
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130816/6a68cc56/attachment.pgp>