directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@gmail.com>
Subject Relication and provider presence detection
Date Tue, 04 Dec 2012 13:52:24 GMT
Hi,

continuing with replication analysis, here is a description of the
different use cases we have when it comes to detect if the provider is
connected or disconected.

I have identified 6 use cases for that :

1) The consumer has been stopped because the server it runs on has been
shutdown.

This is a pretty obvious use case : either the server has been killed
properly, and we can kindly close the connection to the providers, or
the server has been brutally closed, then the socket might be up for a
delay depending on the underlaying OS, but will eventually be closed.
Nothing specifal to do there.

2) The admin stopped a consumer.

This is an interesting use case, but in 2.0, we don't handle such a use
case. An admin might want to shutdown a consumer, or restart it, because
the configuration has changed. In 2.0, we won't support dynamic
configuration, so that ends with a server restart. Cf use case 1.

3) The provider has cleanly disconnected

The consumer will receive a disconnection notice for the associated
consumers, which will stop processing the incoming data (as we won't get
anymore), and switch to a connection polling thread. We will try to
connect back every N seconds, until the provider is back.

4) The connection is closed because we haven't received any message for
more than the socket inactivity delay

We will receive a disconnection notification, and the consumer will
exit, and try to reconnect after a delay. This is very simular to (3).

We can do better : having a separate thread that polls the various
provider periodically, keeping the socket opened.

5) The provider has brutaly disconnected

We won't be informed from such a disconnection. The RefreshOnly
replication will be able to detect it, because it periodically tries to
contact the remote peer, but the Refresh&Persist replication is just
waiting for incoming messages, which it won't received anymore.

If we have the thread described in (4), we can detect such a use case

6) We got an exception during the replication

This is a special case, as we are not suppose to get any exception
there. But still, shit happens. I suggest we stop the consumer,
dsiconnect it, reconnect back and try to reconnect.


I think those 6 use case cover all the possibility, and the proposed
solution are ok, but feel free to comment !

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com 


Mime
View raw message