Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.5
    • Fix Version/s: 2.0.0-M13
    • Component/s: None
    • Labels:
      None

      Description

      My goal is to delete all the element per day,but occasionally it will failed for non specified element. The code will search all children elements of a node and delete it all,but may failed on this:

      NamingEnumeration ne = dirCtx.search(new LdapName(name), "objectClass=*", constraints);

      and then it throw exception.

      This problem occurred twice on 1.5.6 and 1.5.5,it affected single element,and this element can't be deleted on Apache Directory Studio too.The exception like:

      Error while reading entry

      • [LDAP: error code 80 - OTHER: failed for SearchReques
        javax.naming.NamingException: [LDAP: error code 80 - OTHER: failed for SearchRequest
        baseDn : 'ou=WLAN,ou=resource,dc=gd,dc=test,dc=com'
        filter : '(2.5.4.0=*:[121664])'
        scope : single level
        typesOnly : false
        Size Limit : 2000
        Time Limit : no limit
        Deref Aliases : deref Always
        attributes : 'hassubordinates', 'objectclass'
        : null]; remaining name 'ou=WLAN,ou=resource,dc=gd,dc=test,dc=com'
        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
        at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
        at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
        at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
        at org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper$1.run(JNDIConnectionWrapper.java:356)
        at org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.runAndMonitor(JNDIConnectionWrapper.java:1272)
        at org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.checkConnectionAndRunAndMonitor(JNDIConnectionWrapper.java:1203)
        at org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.search(JNDIConnectionWrapper.java:398)
        at org.apache.directory.studio.ldapbrowser.core.jobs.SearchRunnable.search(SearchRunnable.java:500)
        at org.apache.directory.studio.ldapbrowser.core.jobs.SearchRunnable.searchAndUpdateModel(SearchRunnable.java:320)
        at org.apache.directory.studio.ldapbrowser.core.jobs.InitializeChildrenRunnable.executeSearch(InitializeChildrenRunnable.java:361)
        at org.apache.directory.studio.ldapbrowser.core.jobs.InitializeChildrenRunnable.initializeChildren(InitializeChildrenRunnable.java:212)
        at org.apache.directory.studio.ldapbrowser.core.jobs.InitializeChildrenRunnable.run(InitializeChildrenRunnable.java:171)
        at org.apache.directory.studio.connection.ui.RunnableContextRunner$1.run(RunnableContextRunner.java:113)
        at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

      [LDAP: error code 80 - OTHER: failed for SearchRequest
      baseDn : 'ou=WLAN,ou=resource,dc=gd,dc=test,dc=com'
      filter : '(2.5.4.0=*:[121664])'
      scope : single level
      typesOnly : false
      Size Limit : 2000
      Time Limit : no limit
      Deref Aliases : deref Always
      attributes : 'hassubordinates', 'objectclass'
      : null]

      I upgraded 1.5.5 to 1.5.6 to avoid this bug ,but found it happened again finally.

      1. bad.ldif
        402 kB
        roy huang

        Activity

        Hide
        roy huang added a comment -

        More interesting is the problem node can be rename or move to other nod on Apache Directory Studio but can't search it's children and delete.

        Show
        roy huang added a comment - More interesting is the problem node can be rename or move to other nod on Apache Directory Studio but can't search it's children and delete.
        Hide
        Emmanuel Lecharny added a comment -

        Strange... Again, the real error is swallowed, so it's impossible to tell what's going on here.

        Can you add some logs on the server and run the search again ?

        Show
        Emmanuel Lecharny added a comment - Strange... Again, the real error is swallowed, so it's impossible to tell what's going on here. Can you add some logs on the server and run the search again ?
        Hide
        roy huang added a comment - - edited

        No server logs for this cause I am using the default log4j config.
        I can't restart the server now because another bug.
        My guess is it may be some concurrent problems when deleting all elements.But no prove either.
        The error node is still in my data,how can I provide more information?

        Show
        roy huang added a comment - - edited No server logs for this cause I am using the default log4j config. I can't restart the server now because another bug. My guess is it may be some concurrent problems when deleting all elements.But no prove either. The error node is still in my data,how can I provide more information?
        Hide
        Emmanuel Lecharny added a comment -

        How many entries do you have in your base ? (I guess it's more than 150 000)

        Can you provide a ldif dump we can analyze ?

        Show
        Emmanuel Lecharny added a comment - How many entries do you have in your base ? (I guess it's more than 150 000) Can you provide a ldif dump we can analyze ?
        Hide
        roy huang added a comment -

        Total entries no more than 60000.
        But I tried to export the error entry,found it can be exported and its children can be exported too.
        I am very surprise cause these children nodes can't be display in apache directory studio.
        I attached the ldif file.

        Show
        roy huang added a comment - Total entries no more than 60000. But I tried to export the error entry,found it can be exported and its children can be exported too. I am very surprise cause these children nodes can't be display in apache directory studio. I attached the ldif file.
        Hide
        Emmanuel Lecharny added a comment -

        You know that you can't delete an entry which has children, right ? It's not allowed by LDAP.

        Show
        Emmanuel Lecharny added a comment - You know that you can't delete an entry which has children, right ? It's not allowed by LDAP.
        Hide
        roy huang added a comment -

        That's not my point.
        I want to delete the entry and then I search its children,but I got the exception.But if I export the entry,it and its children can be export to ldif , just as I attached.
        That's what make me confused.
        It is a bug,and I just don't know why I can still export the error entry.

        Show
        roy huang added a comment - That's not my point. I want to delete the entry and then I search its children,but I got the exception.But if I export the entry,it and its children can be export to ldif , just as I attached. That's what make me confused. It is a bug,and I just don't know why I can still export the error entry.
        Hide
        Stefan Seelmann added a comment -

        Sounds like the onelevel index is inconsistent. Can you check if there is a difference if you search the children using onelevel scope or sublevel scope?

        Show
        Stefan Seelmann added a comment - Sounds like the onelevel index is inconsistent. Can you check if there is a difference if you search the children using onelevel scope or sublevel scope?
        Hide
        roy huang added a comment -

        Oh yes! One level scope throw exception and Subtree works fine.

        Show
        roy huang added a comment - Oh yes! One level scope throw exception and Subtree works fine.
        Hide
        Stefan Seelmann added a comment -

        Just a note to Emmanuel: I'm trying to find out if we can get rid of the onelevel and sublevel index, and if we can use the new RDN index instead. Just to avoid duplicate work.

        Show
        Stefan Seelmann added a comment - Just a note to Emmanuel: I'm trying to find out if we can get rid of the onelevel and sublevel index, and if we can use the new RDN index instead. Just to avoid duplicate work.
        Hide
        Emmanuel Lecharny added a comment -

        Side note to Kiran : I thought about it, but I'm afraid that it would be complicated

        Show
        Emmanuel Lecharny added a comment - Side note to Kiran : I thought about it, but I'm afraid that it would be complicated
        Hide
        Emmanuel Lecharny added a comment -

        To Stefan : were are we in this area ? Should we consider that the bug is still present ?

        Show
        Emmanuel Lecharny added a comment - To Stefan : were are we in this area ? Should we consider that the bug is still present ?
        Hide
        Stefan Seelmann added a comment -

        I have no free cycles till June 17th, I'll check that issue then.

        Show
        Stefan Seelmann added a comment - I have no free cycles till June 17th, I'll check that issue then.
        Hide
        Pierre-Arnaud Marcelot added a comment -

        Version 2.0.0-M1 has been released.
        Moving all related non-resolved issues to the next version.

        Show
        Pierre-Arnaud Marcelot added a comment - Version 2.0.0-M1 has been released. Moving all related non-resolved issues to the next version.
        Hide
        Pierre-Arnaud Marcelot added a comment -

        Version 2.0.0-M3 has been released a couple months ago.

        Assigned the remaining opened JIRA to the next iteration (2.0.0-M4).

        Show
        Pierre-Arnaud Marcelot added a comment - Version 2.0.0-M3 has been released a couple months ago. Assigned the remaining opened JIRA to the next iteration (2.0.0-M4).
        Hide
        Emmanuel Lecharny added a comment -

        I'm pretty sure the issue was solved when we protected the operation against concurrent modifications last year.

        Feel free to re-open it f the pb still occurs on the latest version.

        Show
        Emmanuel Lecharny added a comment - I'm pretty sure the issue was solved when we protected the operation against concurrent modifications last year. Feel free to re-open it f the pb still occurs on the latest version.

          People

          • Assignee:
            Stefan Seelmann
            Reporter:
            roy huang
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development