On Jul 10, 2012 6:31 PM, "Emmanuel Lécharny" <elecharny@gmail.com> 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 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.
>
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 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.
>
>
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 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.
>
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 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...
>
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
> www.iktek.com
>