directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Swift <>
Subject Re: DN and valueOf( "<a DN>" ) method
Date Tue, 10 Aug 2010 07:58:54 GMT
>> This idea needs testing. In particular, we'd need to figure out the 
>> optimal array size (i.e. number of locks / LHMs). For example, 
>> distributing the cache over 16 LHMs is not going to help much for 
>> really big multi-threaded apps containing 16000+ threads (1000 
>> threads contending per lock).
> But are you going to have 16K threads anyway ?

Perhaps not today, but perhaps tomorrow.

There are already very large CMT (core multi-threading) machines in the 
pipeline from various vendors and I have heard and read projections of 
10K+ thread CMT machines in the next few years. Hence the fork/join work 
going on in JDK7 at the moment and the push for closures.

Since many server apps size their thread pools based on the number of 
available processors (core threads on CMT machines) then it is not that 
unlikely in the next few years.

I think that even today some app server environments run with tens of 
thousands of threads.

Basically, we have no control over how other people use our SDK so, 
while I might not use 16K threads, someone else might :-(

>> A major problem with this approach if we choose to use it in the 
>> OpenDS SDK is that common ancestor DNs (e.g. "dc=com") are going to 
>> end up in a single LHM so, using our current design (RDN + parent 
>> DN), all decoding attempts will usually end up contending on the same 
>> lock anyway :-( So we may need to change our DN implementation to 
>> better cope with this caching strategy.
>> We are not alone though: a concurrent Map implementation which can be 
>> used for caching in a similar manner to LHM is one of the most 
>> frequently demanded enhancements to the java.util.concurrent library.
> There might be some other data structure available, we may need to do 
> some research in this area...

I did have a poke around some time ago and found a couple. I didn't 
evaluate them though as I seem to remember that they introduced a lot of 
extra "baggage" and I'd like to keep the size of the SDK to a minimum 
(to be honest, I think our OpenDS SDK is already too big).


View raw message