> the current implementation of replication, AFAICT, is based on a pull > system.
The current system seems more like push than pull to me, in the sense that one replica decides to send modifications to another without being asked for them. The process of A (client) replicating modifications to B (server) at the moment is: 1. A connects to B. 2. Periodically, A asks B for its current CSN vector. 3a. If A still has enough modifications in its log to bring B up to date: A sends B all the modifications that it has newer than B's CSN vector. 3b. If A doesn't have enough modifications in its log to bring B up to date: A sends B all entries in the DIT. 4. B applies the incoming modifications. There is a problem that you mention, where B goes down and A just keeps trying to reconnect blindly. It would be nice if the responsibility lay with B to notify all other replicas when it comes back up. > - how many threads should we have ? A pool or one thread per replicas ? I would say one thread per replica is OK (I think that's what we have now). Ideally we would have a system where we don't need to be connected to every replica (i.e. if A is connected to B and B is connected to C we don't need A to be connected to C). > The connecting replica could send the last entryCSN received, and then a > search can be done on the server for every CSN with a higher CSN. Then > you don't need to keep any modification on disk, as they are already > stored in the DiT. This would only be OK if you could guarantee that no new modifications would occur on the reconnecting replica until it has been brought back up to date. I think the current method of just sending the modification logs works better especially when the replica was only disconnected for something like a temporary network glitch. I don't think there's a reason to have a separate list of modification logs for each replica stored in the server - we can just keep the main modification logs around until all replicas have them. > The way Mitosis works atm is to keep the deleted entries in the DiT with > a added attribute telling if the entry has been deleted, so we keep them > in the DiT ( but not available for standard operations) until all the > replicas has been updated. So a disconnected replicas which reconnect > will get the deleted entry info when it connect back. As far as I can see mitosis doesn't really use these tombstone entries. A delete operation is stored in the modification logs which are sent to any replica that doesn't have them yet. > How to handle the real deletion is the problem, as we have to keep a > state of each replica... Personally I think we can stop using tombstone entries completely and just rely on the modification logs. The question then is when do we purge the modification logs? At the moment a modification log item is purged after a certain (configurable) amount of time. It perhaps would be nicer if we kept modification log items around while we know other replicas still need them. This would just involve storing the CSN vector for each known replica. Martin
