directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kiran Ayyagari (JIRA)" <>
Subject [jira] [Resolved] (DIRSERVER-1992) LRUMap used as Entry DN cache in AbstractBTreePartition is going into an inconsistent state
Date Sat, 02 Aug 2014 12:23:11 GMT


Kiran Ayyagari resolved DIRSERVER-1992.

    Resolution: Fixed

The issue appears to be due to LRUMap not properly working in non synchronized blocks.
Now, the LRUMap was replaced with ehCache's cache instance and I don't see the error that
I was able to reproduce with MultiThreadedReadWriteTest [1] when LRUMap was present (and with
the cache size of 100)

The fix is committed here


> LRUMap used as Entry DN cache in AbstractBTreePartition is going into an inconsistent
> -------------------------------------------------------------------------------------------
>                 Key: DIRSERVER-1992
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 2.0.0-M17
>            Reporter: Kiran Ayyagari
>            Assignee: Kiran Ayyagari
>            Priority: Blocker
>             Fix For: 2.0.0-M18
> Hello, I'm having a strange issue where I find that I cannot query the LDAP after a large
synchronization operation that occurs at night. The sync deletes and recreates about 25,000
entries with an average of 30 attributes each. Each entry is a separate call to ldapmodify.
This condition is 'corrected' by restarting the ldap server. This makes me suspect it is a
cache corruption of some sort. I'm not getting anything in the log on the server, this error
is client side only. I've tried adjusting cache from 100,000 to 1,000 entries for the partition,
as well as enabling and disabling write sync. The JVM is 1 GB xmx.
> 10:28:04 AM: List failed
> Root error: [LDAP: error code 1 - OPERATIONS_ERROR: failed for MessageType : SEARCH_REQUEST
> Message ID : 2
>     SearchRequest
>         baseDn : ''
>         filter : '(objectClass=*)'
>         scope : single level
>         typesOnly : false
>         Size Limit : no limit
>         Time Limit : no limit
>         Deref Aliases : never Deref Aliases
>         attributes : 'numsubordinates'
key=da6930c8-7524-488e-9e29-c1fb92c4f13d value=dc=nasa,dc=gov size=10000 maxSize=10000 Please
check that your keys are immutable, and that you have used synchronization properly. If so,
then please report this to<>
as a bug.]

This message was sent by Atlassian JIRA

View raw message