[rabbitmq-discuss] amqp usage and msg ack timeout

Justin Azoff JAzoff at uamail.albany.edu
Thu Jul 10 18:04:51 BST 2008


This is also somewhat related to the "One producer multiple subscribers"
thread.

My potential use case for AMQP is for distributed "event" handling.  A
simple example is where one process detects that a device is down.
Prior to queueing it would do something like:

if is_down(device):
  send_email(device)
  send_page(device)
  play_sound(device)

In my testing with amqp, I wrote a wrapper(attached)  which lets me do
the following in different programs on different machines.

#poller.py
e = Events("device_down")
if is_down(device):
  e.add_event(device)

#send_email.py
e = Events("device_down")
e.register_callback('send_email', send_email)

#play_sound.py
e = Events("device_down")
e.register_callback('play_sound', play_sound)
...

The wrapper automatically creates a fanout exchange called 'device_down'
and creates a durable queue for each registered handler.

So my first question is, am I correctly using rabbitmq/AMQP for this, or
did I completely miss some built in feature that would make all of this
much easier?  I wanted each handler to be able to be restarted and never
miss a message, and I wanted a decoupling between the process emitting
the events and each handler.  I think durable queues and fanout
exchanges are the proper solution for this, but I may be wrong.

My second question involves a timeout for the acknowledgment of
messages.  I noticed that if a process crashed, a message would
automatically be put back into the queue, but if instead the process
went into an infinite loop, the message would stay checked out
indefinitely.  Is there a way to tell the server that if a message has
been received, but not acked in a period of time, that it should be put
back into the queue?

I know there is also one potential issue where it may be difficult to
manage the different exchanges and queues on the server. It would be
nice to be able to specify that a queue is durable, but if messages are
not consumed for a long period of time then it should be deleted.


-- 
-- Justin Azoff
-- Network Performance Analyst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amqpevent.py
Type: text/x-python
Size: 3287 bytes
Desc: not available
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080710/041df608/attachment.py 


More information about the rabbitmq-discuss mailing list