directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [Studio] Using JDBM for secondary cache
Date Wed, 02 Apr 2008 21:33:36 GMT
Hi Stefan,

On Wed, Apr 2, 2008 at 3:27 PM, Stefan Seelmann <> wrote:

> 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<String, IEntry>: with the DN as key and the entry as value
> (IEntry is a Studio internal interface with some implementations)
> - a HashMap<IEntry, AttributeInfo>: 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<IEntry, ChildrenInfo>: 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.

Oh that's not good.  We need to cleanup that code anyway so might be good to
work in some optimization.

Emmanuel had a good idea at some point to build a simple parser for DNs
along with a simpler LdapDN class for handling most general cases.  If this
parser fails then another corner-case parser continues where the first left

All these crazy and complicated corner cases like with multi-attribute Rdns
and character issues cost more memory.  They can then be handled by this
special DN parser with it's resective special LdapDN object that has
additional structures for handling these the tracking of these complex DNs.

If 99% of the time the simple LDAP DNs are used with smaller footprint, then
we can reduce complexity and memory usage, while increasing performance.
This will have an impact for both ApacheDS and Studio.

>  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.

I was just pointing it out if you were interested in using it.  This is just
a wrapper that abstracts most BTree implementations with a common
interface.  The JDBM implementation which we use by default might be handy
for a secondary cache to swap entries out.

We can talk about it if you want to use it at AC.  Also here's a link to the
documentation (which I am really proud of :D):


View raw message