Le 7/10/12 5:07 PM, Göktürk Gezer a écrit :

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?

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.

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.

You are right. I assumed that the configuration was propagated live, which means the Life Cycle management is already implemented in the server, which is not the case. However, it would be good to replicate the configuration, so that we just have to stop and restart the server to benefit from the modification, without having to inject it into the server.
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.

Keep in mind that the configuration is read only once, at startup (at least, atm), so even if you modify the configuration, it's not effective before you stop and restart the server. So replication the configuration should not have any effect on the server, until you stop and restart it.


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 ?
Rplication is not working well, atm :/ For the schema or for the data...

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.
Hmmm... The configuration schema cannot be modified. It's hard coded, and can't be changed.

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?

Not sure I get whant you mean here...


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Reply via email to