[openamq-dev] Disconnect notification between two peers

[Elli Barasch]

Martin,
I'm a bit confused about your response.  Mike asked about server 
notification between peers, not about client notification nor about
a fan-out  topology.  I, too, would require some notification that  a 
client has disconnected, in order that the server might roll back
transactions initiated by the client in a timely fashion.  So there are 
two votes for that functionality. ;^)

On a similar vein, can you confirm that a client can recognize that all 
the consumers of a queue to which the client is publishing  have 
disconnected? One method might be to have the consumers declare a shared 
queue which auto-deletes when the last consumer detaches. Is this feasible?

Thanks,
Elli

Martin Sustrik wrote:
> 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
> _______________________________________________
> openamq-dev mailing list
> openamq-dev at lists.openamq.org
> http://lists.openamq.org/mailman/listinfo/openamq-dev
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openamq.org/pipermail/openamq-dev/attachments/20071106/c311660d/attachment.htm