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 D9D5CC0CB for ; Tue, 10 Jul 2012 10:55:14 +0000 (UTC) Received: (qmail 93398 invoked by uid 500); 10 Jul 2012 10:55:13 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 93353 invoked by uid 500); 10 Jul 2012 10:55:13 -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 93343 invoked by uid 99); 10 Jul 2012 10:55:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Jul 2012 10:55:13 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gokturk.gezer@gmail.com designates 209.85.160.50 as permitted sender) Received: from [209.85.160.50] (HELO mail-pb0-f50.google.com) (209.85.160.50) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Jul 2012 10:55:06 +0000 Received: by pbbrr4 with SMTP id rr4so129800pbb.37 for ; Tue, 10 Jul 2012 03:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8mrFRPPwXXFt2fhUOIYVAuTeAh89X0fVhd8jBRRP9tE=; b=I7jVpDKrBAeSScMDfYYUmAqnaqKpednJVcPki1cbp+pGwpOz9v0BmYe3eYsXkNjzgq gNmw7qt7yq/cy2rG1VTqmTnjuWhtT5HMp5A2cBES2e8qHoigcC8yVnoSBThBOBQ0Um+3 KEhYgLN4JJDrm+7tipS+wxxMrr2wR2LwII1MagXvHu4ar3V4ik7M/+gbz+/3gcoeG7PG ZcckTikOU5c0ntRKgJnCnWTxP1IPCz0iiu/zFo9cUVQo15HphXQ6XXBOfI47eXx2sO6L K5vS0oQE9xN9KbxjPDPhBkCJjX7A72lwgN5Fs9BfQBEbAgck+RQ9ub6qaORFeQfYazoL Vg5w== MIME-Version: 1.0 Received: by 10.68.201.135 with SMTP id ka7mr3009620pbc.15.1341917686453; Tue, 10 Jul 2012 03:54:46 -0700 (PDT) Received: by 10.68.64.74 with HTTP; Tue, 10 Jul 2012 03:54:46 -0700 (PDT) Date: Tue, 10 Jul 2012 13:54:46 +0300 Message-ID: Subject: Question about Replication of Config Partition and Schema Partition From: =?UTF-8?B?R8O2a3TDvHJrIEdlemVy?= To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=e89a8ff1c8d604d3cd04c4778f97 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8ff1c8d604d3cd04c4778f97 Content-Type: text/plain; charset=UTF-8 Hi Everyone, I would like to know, it config and schema partitions of one server node can be candidate for replication? 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. 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? Thanks, Gokturk --e89a8ff1c8d604d3cd04c4778f97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Everyone,

I would like to know, it config and schema = partitions of one server node can be candidate for replication? If replicat= ion of some ApacheDS instance will also clone its config and schema partiti= on, we have a little problem because of the randomly assigned OIDs to compo= nent factories. So lets say ApacheDS1 and ApacheDS2 both have same set of i= nterceptors, because of the nature of OSGI those can be introduced in diffe= rent order in two different server node which results in schema partitions = having different OID=C2=A0assignments=C2=A0for same components across 2 ser= ver node.

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 p= artition or entire server with all of its runtime components and configurat= ion?

Thanks,
Gokturk
--e89a8ff1c8d604d3cd04c4778f97--