From dev-return-41161-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Tue Jul 10 15:31:03 2012 Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4A4BEDBF9 for ; Tue, 10 Jul 2012 15:31:03 +0000 (UTC) Received: (qmail 12387 invoked by uid 500); 10 Jul 2012 15:31:03 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 12341 invoked by uid 500); 10 Jul 2012 15:31:03 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 12334 invoked by uid 99); 10 Jul 2012 15:31:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Jul 2012 15:31:02 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates 209.85.212.178 as permitted sender) Received: from [209.85.212.178] (HELO mail-wi0-f178.google.com) (209.85.212.178) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Jul 2012 15:30:55 +0000 Received: by wibhr14 with SMTP id hr14so106930wib.1 for ; Tue, 10 Jul 2012 08:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=js7CmBciDLtgQL7vHqeuKWR8OD3L/PdyJA5grdn+Kfk=; b=x06mLOgfNN+KlqSFNbuwztI6+IBi0Se6+xdw7oh9s/HiRDglaqAw8hmrNXRuxl2O2S wDm4nzB0co+xHusyvnSGaa+JjISVI89FNwF3tPo5LUg0lHWm3s6I3T+asha3nM10W2DW woty3YRkYCDwXptMTtoqmB+H1WYO7Z9jEyM69HdpOjOV/NZpR0gTpHtqJB7Z1xR4xyVJ Xp4atYQv7BRRed9PTv2eAW354BqqjADnr+H6MPP48vliWRnrksPpwG5MHaOAUOHM3Uyd sFw7NJKoVrzp4XJIFN1M4Pivk0zg7KKKGmiw/y1sPITN7ZLd0OXeYq+cxtpmvuqZHpsk DDEQ== Received: by 10.180.100.133 with SMTP id ey5mr39273335wib.4.1341934234654; Tue, 10 Jul 2012 08:30:34 -0700 (PDT) Received: from Emmanuels-MacBook-Pro.local (lon92-10-78-226-4-211.fbx.proxad.net. [78.226.4.211]) by mx.google.com with ESMTPS id a16sm103520579eeg.0.2012.07.10.08.30.33 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 08:30:34 -0700 (PDT) Message-ID: <4FFC4A9A.40403@gmail.com> Date: Tue, 10 Jul 2012 17:30:34 +0200 From: =?UTF-8?B?RW1tYW51ZWwgTMOpY2hhcm55?= Reply-To: elecharny@apache.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: Question about Replication of Config Partition and Schema Partition References: <4FFC300A.5080601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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