[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