Closed l8nite closed 9 years ago
I would rely on a separate sentinel to keep track of when to terminate your main loop. For example, if you want to send 5 messages and quit only when you've ACK'd receipts for the 5, then you could do something like:
sent_messages = 0
client.on_receipt { |r, *_| sent_messages += 1 }
while sent_messages < 5
sleep 1
end
Be warned, depending on how you're approaching failover/retrying, you can run into some issues as outlined in #13 and the failover functionality found in onstomp/failover
can suffer from race conditions related to this issue.
Thanks. I'm glad you've at least put some initial thought into these race conditions.
My intent is to have a long-running queue subscriber which simply does its best to stay connected and wait around for new messages and be allowed to failover to our standby broker when the master goes offline.
Looks like my best bet right now is to wait for failover_retries_exceeded
to terminate the main loop if the client URI is failover. If we're not in failover mode, then continue to rely on .connected?
I'm testing out the failover client and wondering what the best approach is to keeping my subscriber process waiting while it attempts to reconnect.
Right now I have a simple loop in my main process
During a failover (i.e., if I shut down the broker it was talking to), this loop breaks because client.connected? returns false.
What event(s) should I use to determine whether or not the client is going to be attempting a retry?