On Tue, Jul 10, 2012 at 4:37 PM, Emmanuel Lécharny <email@example.com>
Le 7/10/12 12:54 PM, Göktürk Gezer a écrit :
I would like to know, it config and schema partitions of one server node
can be candidate for replication?
We should not affect random OID to components. An OID should identify a unique object, so if you have some instance of this object on many instances of the server, then they should always have the same OID.
If replication of some ApacheDS instance
will also clone its config and schema partition, we have a little problem
because of the randomly assigned OIDs to component factories. So lets say
ApacheDS1 and ApacheDS2 both have same set of interceptors, because of the
nature of OSGI those can be introduced in different order in two different
server node which results in schema partitions having different
OID assignments for same components across 2 server node.
We can go with has values of component names. That would do the trick !
Depends. Replication is supposed to be configurable. You can replicate only part of the data, it's up to the administrator to tell what should be replicated, or not.
This is something we've postponed to discuss later, it's not a concern for
single server but in replication scenario i'd like to know how this effects
consistency between distinct server nodes. I'm not so sure what is being
replicated in our implementation, some partition or entire server with all
of its runtime components and configuration?
Well i don't believe replicating runtime information and plain data with the same process is a good idea anymore. Right now changes on configuration partition is read until next restart, but after migrating to OSGI it will. So syncing the replicas to have same runtime footprint must be handled via seperate subsystem, otherwise we're in trouble. There can be some switch in replication configuration to specify whether replica's runtime configuration will be the same. Apart from configuration we also have the schema's backing that configuration entries, because they are not spread in many location, that won't be much of a problem.
How replication is working for schema data ATM ?
In the standard scenario, the configuration and schema should be replicated, that's pretty mandatory.
Configuration and configuration related schema must be handled in some other way, if don't then we can not manage lifecycle of server in OSGI. If some ApacheDS instance can obtain the reference to replica instance than we can manage it incrementally as the configuration or backed schema changes. ComponentHub is pretty much supporting that. However we should have access to DirectoryService reference of replica, I guess this is not the case right now?
Does it help ?
Yeah thanks, but need more :)