directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: DN and valueOf( "<a DN>" ) method
Date Wed, 28 Jul 2010 20:32:34 GMT
On Wed, Jul 28, 2010 at 4:37 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>  On 7/28/10 11:31 AM, Stefan Seelmann wrote:
>>>
>>> I was thinking lately about the DN class. I know that OpenDS (and
>>> probably
>>> UnboundId, but not sure) has a DN.valueOf( "<a DN>" ) factory that
>>> returns a
>>> DN potentially leveraging a cache associated to a ThreadLocal.
>>>
>> ...
>>>
>>> I don't think it's such a good idea :
>>> - first, as it's ThreadLocal based, you will have as many cache as you
>>> have
>>> threads processing requests. Not sure it competes with a unique cache,
>>> not
>>> sure either we can't use the memory in a better way...
>>
>> An advantage to use ThreadLocal is that you don't need to synchronize
>> access to the cache Could be worth to measure the performance
>
> Using ConcurrentHashMap should not be a major performance penalty. I mean,
> it *will* be more costly than not having any synchronization but it sounds
> acceptable.
>
> Another possibility is to use a CopyOnWriteArraySet, but I'm afraid that it
> will crawl if many new DN are added.
>>
>> difference, I wonder if the OpenDS team did some performance analysis?
>
> They compared the performances they get with a ThreadLocal cache and no
> cache : the gain was sensible (I don't have the number for OpenDS). FYI, the
> DN parsing count for more or less 13% of the whole CPU needed internally
> (network excluded) to process a simple search, and normalization cost an
> extra 10%. There is most certainly a net potential gain to implement a DN
> cache !
I have just committed a DNFactory implementation [1]. But the real
issue with this is that
the ApacheDS's DN class is mutable and hence will cause issues[2].

A working solution I have is to return a clone of the DN *all* the
time (whether a hit or a miss)
this is guaranteed to work and am thinking that cloning() is way
faster than the time required for
parsing and normalizing a DN from the beginning. But one penalty we
pay for this solution is that
two instances(of which one is just a clone) will be created for every
DN miss in the cache.

P.S:- haven't committed the above mentioned solution

Kiran Ayyagari

[1] https://svn.apache.org/repos/asf/directory/apacheds/branches/apacheds-dnfactory-experiment/core/src/main/java/org/apache/directory/server/core/DNFactory.java

[2] the test testToSysDn() in PreferencesUtilsTest class fails because
of the mutable DN reference returned from cache

Mime
View raw message