directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norbet Reilly" <nrh...@gmail.com>
Subject Re: [ApacheDS][performance] Add, Search, Del throughput
Date Wed, 12 Jul 2006 02:18:16 GMT
Hi All,

I haven't done an update to the latest SVN trunk for a while, so I
thought I'd try one and see if I could take advantage of the speed
improvements and enhanced LDIF reader support I've been reading about.
Unfortunately things didn't go so smoothly...

I use JDK1.4 (still the intended target platform, correct ?) as as
with all of the updates I've done over the last six months or so,
there were a number of build problems which I had to hack around. Two
which I can remember were that the StringTools.DEFAULT_CHARSET_JDK_1_5
constant can't be evaluated under JDK1.4 as it is assigned to a
JDK1.5-specific method. Another was the LDAP class loader seems to
refer to a JDK.1.5 compiled class.

 After fixing these I then saw a whole raft of unit test failures and
decided there wasn't going to be time to investigate/resolve them all,
the list is as follows:

./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/HighestPrecedenceFilterTest.java.bak
./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MaxValueCountFilterTest.java.bak
./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MicroOperationFilterTest.java.bak
./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MostSpecificProtectedItemFilterTest.java.bak
./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MostSpecificUserClassFilterTest.java.bak
./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/RestrictedByFilterTest.java.bak
./apacheds/core-unit/src/test/java/org/apache/directory/server/core/sp/LdapClassLoaderTest.java.bak
./mina/core/src/test/java/org/apache/mina/common/support/FutureTest.java.bak
./mina/core/src/test/java/org/apache/mina/transport/socket/nio/SocketBindTest.java.bak
./mina/core/src/test/java/org/apache/mina/transport/vmpipe/VmPipeBindTest.java.bak
./shared/ldap/src/test/java/org/apache/directory/shared/ldap/ldif/LdifReaderTest.java.bak

After moving these out of the way I had a working JDK1.4 build and
needed to refactor my code to remove all LdapName refs and replace a
number javax.naming.Name with LdapDN references: which was fine as I'd
expected to need to do this work.

However, when I attempted a sanity check reading a small LDIF file at
ApacheDS start-up I encountered the most worrying set of problems. In
about ten different places during start-up the core wasn't internally
able to resolve the system partition (ou=system), as
DefaultDirectoryPartitionNexus.getBackend(LdapDN) expects the provided
DN to be normalised (<oid>=value), but was given an unormalised DN. At
this stage I was quite a few hours into the update and decided to just
hack in any number of .normalise()s to see if I could get the system
to start-up.

So my questions are:
 1. JDK 1.4 is still the target platform, correct?
 2. I know updating to the trunk usually involves an element of risk,
but my experiences with this upgrade tend to suggest that the codebase
currently has some pretty deep-running issues re LdapDN normalisation.
It's possible that all the problems I saw were due to importing LDIF,
but I strongly suspect otherwise. I'll do some other testing before
rolling back to the snapshot I was using previously.
 3. Am I the only one seeing these problems with unit
tests/normalisation on the trunk? If not, is there a point in time
when the stability of the trunk is expected to be restored.
 4. I tried a few weeks back to move from the trunk back to the 1.0
branch (which I'd prefer to use ultimately) but had the same JDK1.4
compatibility issues reported above, so didn't want to invest a lot of
time in back-porting my customisations until it looked closer to being
frozen.
 5. Which codebase would the comitters advise me to concentrate on,
should I concentrate exclusively on the 1.0 branch and ignore the
trunk for a while?

Sorry if I sound a bit grumpy, the update led to a very late night.

Any opinions gratefully accepted...

Thanks

Mime
View raw message