[openamq-dev] Disconnect notification between two peers

Martin Sustrik sustrik at imatix.com
Tue Nov 6 06:28:09 CET 2007


Mike,

> Ideally, it would be nice if the server could just register an interest 
> in knowing if/when the peer with routing_key #xyz disconnected. Without 
> this, the server will have to either resort to polling or implementing 
> some kind of timeout, both of which seam to run counter to the 
> asynchronous message paradigm.

This is an interesting question that sheds some light on AMQP design. 
There's no such functionality in AMQP protocol and I believe there is a 
good reason why. Let me explain.

There are two basic scenarios for any messaging application: 
request/reply, RPC, ESB or however you choose to call it is the first 
one and publish/subscribe or data distribution is the second one.

In the former scenario, client application is sending a request for some 
service, server application gets the message and replies back to the 
client (I believe this is the scenario you are interested in.)

To ensure scalability when your server is not able to handle the request 
load any more, you should be able to install the server on a new box (2 
boxes, 10 boxes, 100 boxes, ...) and plug it into your infrastructure 
without even restarting client applications. Afterwards you'll expect 
the request load to be fairly balanced between the boxes.

Now imagine that the client application is registered for 'server 
disconnected' event. Would you like to get the event if any of the 
server apps is disconnected? I don't think so as there may be still 
another 99 instances running and ready to serve the requests.

What you would like to see IMO is getting back a 'request cannot be 
served' error in case all the servers are down. And this is exactly what 
'mandatory' and 'immediate' flags are for.

As for the latter scenario (publish/subscribe) one application is 
sending messages whereas N applications are dynamically subscribing to 
receive them.

Once again, if one of the subscribers disconnects there's no reason why 
your publishing application should be bothered.

Martin

Martin


More information about the openamq-dev mailing list