You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Kiran Ayyagari (JIRA)" <ji...@apache.org> on 2014/07/31 13:25:38 UTC

[jira] [Created] (DIRSERVER-1992) LRUMap used as Entry DN cache in AbstractBTreePartition is going into an inconsistent state

Kiran Ayyagari created DIRSERVER-1992:
-----------------------------------------

             Summary: LRUMap used as Entry DN cache in AbstractBTreePartition is going into an inconsistent state
                 Key: DIRSERVER-1992
                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1992
             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'
org.apache.directory.api.ldap.model.message.SearchRequestImpl@5f3340d2: Entry.next=null, data[removeIndex]=85bf738a-38c6-48c8-8772-1d000695d730=employeenumber=0000ntvd177,ou=People,dc=nasa,dc=gov previous=3a39fa31-9a7a-4b41-bf09-d356b8258a7b=employeenumber=13584685,ou=People,dc=nasa,dc=gov 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 commons-dev@jakarta.apache.org<ma...@jakarta.apache.org> as a bug.]



--
This message was sent by Atlassian JIRA
(v6.2#6252)