<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Mark,<br>
<br>
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:<br>
<br>
init(Config) -><br>
{Timeout, Queue, Params} = parse_config(Config),<br>
{ok, Conn} = amqp_connection:start(Params),<br>
{ok, Chan} = amqp_connection:open_channel(Conn),<br>
State = #state{ connection = Conn, channel = Chan, queue =
Queue, timeout = Timeout, status = idle },<br>
start_timer(State),<br>
{ok, State}.<br>
<br>
handle_info(connect, State = #state{ status = running }) -><br>
{noreply, State};<br>
handle_info(connect, State = #state{ channel = Chan, queue = Queue
}) -><br>
try<br>
#'queue.declare_ok'{} = amqp_channel:call(Chan,
#'queue.declare{ queue = Queue, exclusive = true }),<br>
{noreply, State#state{ status = running }}<br>
catch _:_ -><br>
start_timer(State),<br>
{noreply, State}<br>
end.<br>
<br>
start_timer(#state{ timeout = T }) -><br>
erlang:send_after(T, self(), <br>
<br>
<br>
Hopefully that'll get you going.<br>
<br>
Cheers,<br>
Tim<br>
<br>
<br>
On 08/16/2013 04:03 PM, Geib, Mark wrote:
<blockquote
cite="mid:065F453F-5803-4FDD-95D5-F76B8D7A360D@echostar.com"
type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:mark.geib@echostar.com">mark.geib@echostar.com</a> / 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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rabbitmq-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a>
<a class="moz-txt-link-freetext" href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a>
</pre>
</blockquote>
<br>
</body>
</html>