directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göktürk Gezer <>
Subject Re: Question about Replication of Config Partition and Schema Partition
Date Wed, 11 Jul 2012 10:23:34 GMT
On Jul 10, 2012 6:31 PM, "Emmanuel Lécharny" <> wrote:
> 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
>>>> 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
>>>> replicated in our implementation, some partition or entire server with
>>>> 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
>>> 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
>> partition is read until next restart, but after migrating to OSGI it
> 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.
Yes, actually we have more than configuration to replicate. Bundles of
master node must also be replicated to slaves. When replicating some data
inside some custom component, that custom component's bundle must also be
present at replicas.

>> So syncing the replicas to have same runtime footprint must be handled
>> seperate subsystem, otherwise we're in trouble. There can be some switch
>> 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.
Yeah that's the problem! It won't be that way anymore. Blindly replicating
configuration without making bundle space equal might broke replicas
because of the thing I described above. So before configuration replication
we must replicate bundles. Karaf cellar feature supports this in limited
way. I'll look further if we can make use of it to solve this problem.
>> Apart from configuration we also have the
>> schema's backing that configuration entries, because they are not spread
>> 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.
That was before too! They are dynamically managed now. But only under 1
schema: cn=components.
>> If
>> some ApacheDS instance can obtain the reference to replica instance than
>> can manage it incrementally as the configuration or backed schema
>> ComponentHub is pretty much supporting that. However we should have
>> to DirectoryService reference of replica, I guess this is not the case
>> right now?
> Not sure I get whant you mean here...
I suppose replication is using LdapConnection? If this is right, then we
can access DirectoryService reference of the server that we are replicating
into by getDirectoryService(). That was what I meant, if possible?
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny

View raw message