Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 75419 invoked from network); 5 Jul 2010 22:07:12 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 5 Jul 2010 22:07:12 -0000 Received: (qmail 57808 invoked by uid 500); 5 Jul 2010 22:07:12 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 57740 invoked by uid 500); 5 Jul 2010 22:07:11 -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 57733 invoked by uid 99); 5 Jul 2010 22:07:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Jul 2010 22:07:11 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates 209.85.161.50 as permitted sender) Received: from [209.85.161.50] (HELO mail-fx0-f50.google.com) (209.85.161.50) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Jul 2010 22:07:03 +0000 Received: by fxm9 with SMTP id 9so5233326fxm.37 for ; Mon, 05 Jul 2010 15:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=a+s26z0716L9b9n07G/MW19+L0AYVPxMRDTSL5VOYOw=; b=jRrGuTqFjPZ4igRlZh+DGM/EzsvLcNsZj2KoquXopOa/mPKLY129jr2cAyQ94Qcw1L wqNHi9ez1hyChMAd1Tkyh+Y8U9QOMi2n2AF5F8GPmLKGtaUhG3E/auNfvcA6xwmiLO3P bbDIWwldF3XNEJHTdMPaxjJT2tfVhk+1JuOfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=E8g+KHF6FWf0bcwRUw17TKHFJpW3zoI+6iEzq8tZeVyuVSBYmm6LwFli4/Rn6vs/g/ MvIrYjCX/5CCyUWSegALm7BPpeElA55eZwlhxa8OcdIf4wqV6cTUYUP8IuvGI6/fxW0Y fqvd4c5PGNHnLYllDLMBx/XktyrgttB7Lr0zs= Received: by 10.213.90.201 with SMTP id j9mr2974973ebm.75.1278367603374; Mon, 05 Jul 2010 15:06:43 -0700 (PDT) Received: from emmanuel-lecharnys-MacBook-Pro.local ([78.192.106.184]) by mx.google.com with ESMTPS id a48sm39084009eei.0.2010.07.05.15.06.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Jul 2010 15:06:42 -0700 (PDT) Message-ID: <4C3257D6.9020306@gmail.com> Date: Tue, 06 Jul 2010 00:08:22 +0200 From: Emmanuel Lecharny Reply-To: elecharny@apache.org User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Apache Directory Developers List Subject: ACI and subtrees interactions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Hi, I'm just checking the subentryInterceptor while trying to find the best way to fix the ACI handling when the server is stopped and restarted. There is something really unpleasant in this interceptor : when adding a subtree, we do a search in the DIT to find all the entries part of the subtree, and each of them is modified to have the accessControlSubentries AT added, with a reference to the subentry. If the server contains millions of enries, this is simply not an option. The direct consequence is that anytime we add an ACI which span over a lot of entries, we wwill have a large number of modifications applied, and it's definitively a costly operation (moreover, I don't see how we can assure the atomicity of such an operation...) We have to find a better way to determinate if an entry is part of a subtree than by modifying this entry. Another annoying aspect is that when we evaluate an ACI, we have to get the subtree from the subEntry interceptor, because the associated cache is not global. This is not a good thing too. Caches must be handled globally by the DirectoryService instance, not by each interceptors. Still a lot of work before we can release a production ready server, guys... -- Regards, Cordialement, Emmanuel L�charny www.iktek.com