[openamq-dev] Disconnect notification between two peers

[Mike Owens]

Yes, the scenario I needed help with the when an application server (service
provider) acts as a second tier to broker transactions to a database on
behalf of a client, i.e.

client app --> amq_server (direct exchange) --> server_app  --> DB

In this scenario, the client app is listening on a private queue, and there
is a private exchange between the client and server. Specifically, this
server instance is a member of a worker pool (like an Apache prefork model,
or PostgreSQL's postmaster/backend process model). The reason this is
important in my application is that the server is using a language
interpreter that doesn't lend itself to efficient threading (has a global
mutex to access the VM). Therefore, there is better overall performance if I
reserve one server process per client.

In this scenario, the server becomes more or less dedicated to servicing a
particular client, and therefore may have a significant number of resources
just for that client (VM, database connection(s), etc.). This session works
kind of like a HTTP 1.1 connection with KeepAlive (although it is much
better with AMQ b/c of the asyn message capability). It is a long-term
session.

If the client goes down, ideally the server should be able to detect this as
if it had a native socket  to the client (that just closed), and immediately
free its resources and make itself available to service the next incoming
client.

As is obvious, the server does not have a direct socket open to the client,
but rather to the amq_server, who in turn does have a direct connection to
the client. It is the level of indirection that I am trying to bridge. Can I
somehow have the amq_server send out a message to the application server
(out of band or otherwise) notifying it that the client has gone away?
Otherwise, the application server will have to rely on a inactivity timeout,
or some kind of ping to see if the client is still there.

If there is no way to do this in the protocol, it looks like it may be
possible with the console API, using the notify command. If it's possible
for the server to send notifications about peer disconnects, then one could
have a dedicated client connect to the server and monitor these
notifications via the console API. This client would then broadcast these
disconnect events to the server worker pool, which would do the trick.

I hope I am not coming across as demanding. I am just trying to find the
best way for me to solve this problem. If I have to implement a ping/timeout
on the server, that's fine. It's easy to do with AMQ. I just want to make
sure up front that I am taking the best approach possible. That is why I am
asking.

-- Mike

On Nov 6, 2007 7:44 AM, Elli Barasch <comptonsw at comcast.net> wrote:

>  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 listopenamq-dev at lists.openamq.orghttp://lists.openamq.org/mailman/listinfo/openamq-dev
>
>
>
> _______________________________________________
> 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/a3676d35/attachment.htm