From dev-return-24716-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed Apr 02 19:27:39 2008 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 11312 invoked from network); 2 Apr 2008 19:27:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Apr 2008 19:27:39 -0000 Received: (qmail 64845 invoked by uid 500); 2 Apr 2008 19:27:38 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 64794 invoked by uid 500); 2 Apr 2008 19:27:38 -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 64783 invoked by uid 99); 2 Apr 2008 19:27:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Apr 2008 12:27:38 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 02 Apr 2008 19:26:55 +0000 Received: (qmail 11219 invoked from network); 2 Apr 2008 19:27:14 -0000 Received: from localhost (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 2 Apr 2008 19:27:14 -0000 Message-ID: <47F3DE14.1000105@apache.org> Date: Wed, 02 Apr 2008 21:27:16 +0200 From: Stefan Seelmann User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [Studio] Using JDBM for secondary cache References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi Alex, Alex Karasulu schrieb: > Stefan S., > > Do we use a secondary cache for Studio? Just wondering because of the > performance issues someone noted on the user list when dealing with a > very large directory. no, we don't use a cache for Studio. I tried to use ehcache long time ago but it was really slow when it swaps entries to the disk and back. Today there we have the following: - a HashMap: with the DN as key and the entry as value (IEntry is a Studio internal interface with some implementations) - a HashMap: as soon as the attributes of an entry were loaded an AttributeInfo containing all attributes and other information is created and put to this map - a hashMap: as soon as child entries are loaded a ChildrenInfo containing all child entries is created and put to this map. For sure, this does scale well. With the default VM parameters (64MB heap) you could load about 30,000 entries to get an OutOfMemory :-((( I also think that the switch from the old DN/RDN implementation to the shared-ldap LdapDN/Rdn implementation costs some memory. We should consider to do some test for performance and memeory consumtion. > The idea occurred to me that the JDBM code for > JdbmTable and JdbmIndex could potentially be used by Studio to help > solve some of the caching problems. If this is something you think will > help we can move this code into shared so both the server and Studio can > leverage them. Yeah, that sounds great. You want me to look how the JDBM code works? I guess we will have some time at ApacheCon for that. > > Alex Kind Regards, Stefan Seelmann