From dev-return-22471-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Mon Nov 12 18:42:12 2007 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 73764 invoked from network); 12 Nov 2007 18:42:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Nov 2007 18:42:12 -0000 Received: (qmail 37207 invoked by uid 500); 12 Nov 2007 18:42:00 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 36982 invoked by uid 500); 12 Nov 2007 18:41:59 -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 36970 invoked by uid 99); 12 Nov 2007 18:41:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2007 10:41:59 -0800 X-ASF-Spam-Status: No, hits=-98.8 required=10.0 tests=ALL_TRUSTED,FS_REPLICA X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Nov 2007 18:42:11 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 570E3714231 for ; Mon, 12 Nov 2007 10:41:51 -0800 (PST) Message-ID: <10751569.1194892911354.JavaMail.jira@brutus> Date: Mon, 12 Nov 2007 10:41:51 -0800 (PST) From: "Alex Karasulu (JIRA)" To: dev@directory.apache.org Subject: [jira] Commented: (DIRSERVER-1097) Only send net changes during replication In-Reply-To: <25804711.1194890991301.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DIRSERVER-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541888 ] Alex Karasulu commented on DIRSERVER-1097: ------------------------------------------ Great idea! I was thinking we can do similar optimizations as well when dealing with reverting things in this ChangeLog thing we're working on now. The idea is the same, if in rev 10 an entry is created, then modified in 200, 2345, and deleted in 94872. Then reverting to rev 7 for example would essentially not include anything with respect to this entry. The code in the replication subsystem and the changelog shapshotting would essentially have to do similar things. Perhaps we can share this code. I think there is intense synergy and complementation between this changelog feature and the replication subsystem. I'm trying to grasp how revision numbers can be used in concert with UUIDs to manage various tasks. Also thinking about how the two can better compliment each other. I'd be interested in any thoughts you may have on the matter. > Only send net changes during replication > ---------------------------------------- > > Key: DIRSERVER-1097 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1097 > Project: Directory ApacheDS > Issue Type: Improvement > Components: mitosis > Affects Versions: 1.5.1 > Reporter: Martin Alderson > Priority: Minor > > During replication we currently send all changes that have occurred since the target replica was last brought up to date. We can optimise this by only sending the net changes. As an example, if an entry is created, modified several times then deleted at one server, we do not need to tell other replicas anything regarding this entry. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.