You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Negoita Ionut <jo...@gmail.com> on 2015/11/02 16:59:20 UTC

getting LDAP: error code 80 - OTHER: failed for MessageType : ADD_REQUEST

Hi,

we have been using ApacheDS 2.0.0-M17 for about a year and from time to
time the data gets corrupted leaving us no other choice but to create a
fresh installation, export then import what data we can. This is very
frustrating and also dangerous for us to deploy in a production environment.

What happens is that after a while of usage adding an entry (a user) gives
an error, and any additions after that fail. All entries for which the
error occurs cannot be found anymore (using ApacheDS Studio or via Java),
when trying to re-add them we get an error saying that an entry with the
same cn already exists, and we cannot delete the entry since we can't find
it.

Please help, what are we doing wrong? Do we have to set some settings?
We've had similar problems with version since M11, and upgraded hoping this
will not occur anymore.

kindest regards,
John Negoita

Here is the trace from the Java that tries to add the entry:

javax.naming.NamingException: [LDAP: error code 80 - OTHER: failed for
MessageType : ADD_REQUEST
Message ID : 3
    Add Request :
Entry
    dn[n]: cn=something@something.com,ou=users,ou=portal,o=mycompany
    objectClass: organizationalPerson
    objectClass: person
    objectClass: inetOrgPerson
    objectClass: portalUser
    objectClass: top
    userPassword: 0x7B 0x23 0x48 0x41 0x7D 0x19 0x76 0x76 0x53 0x51 0x35
0x4E 0x54 0x57 0x4B 0x75 ...
    sn: something@something.com
    cn: something@something.com
    email: something@something.com
    lastName: Johnson
    portalInstance: apps.domain.com=63414
    defaultPortalInstance: subdomain.domain.com=63408
    firstName: John
    ManageDsaITImpl Control
        Type OID    : '2.16.840.1.113730.3.4.2'
        Criticality : 'false'
'
: java.lang.ArrayIndexOutOfBoundsException: -19960:
org.apache.directory.api.ldap.model.exception.LdapException:
java.lang.ArrayIndexOutOfBoundsException: -19960
        at
org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.add(AbstractBTreePartition.java:862)
        at
org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.add(DefaultPartitionNexus.java:352)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor$1.add(BaseInterceptor.java:165)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.journal.JournalInterceptor.add(JournalInterceptor.java:139)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.trigger.TriggerInterceptor.add(TriggerInterceptor.java:300)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.event.EventInterceptor.add(EventInterceptor.java:226)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.subtree.SubentryInterceptor.add(SubentryInterceptor.java:1014)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.collective.CollectiveAttributeInterceptor.add(CollectiveAttributeInterceptor.java:134)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.operational.OperationalAttributeInterceptor.add(OperationalAttributeInterceptor.java:232)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.schema.SchemaInterceptor.add(SchemaInterceptor.java:1101)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.hash.PasswordHashingInterceptor.add(PasswordHashingInterceptor.java:93)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.exception.ExceptionInterceptor.add(ExceptionInterceptor.java:189)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.admin.AdministrativePointInterceptor.add(AdministrativePointInterceptor.java:1201)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.authz.AciAuthorizationInterceptor.add(AciAuthorizationInterceptor.java:515)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.referral.ReferralInterceptor.add(ReferralInterceptor.java:249)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.authn.AuthenticationInterceptor.add(AuthenticationInterceptor.java:405)
        at
org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:422)
        at
org.apache.directory.server.core.normalization.NormalizationInterceptor.add(NormalizationInterceptor.java:131)
        at
org.apache.directory.server.core.DefaultOperationManager.add(DefaultOperationManager.java:394)
        at
org.apache.directory.server.core.shared.DefaultCoreSession.add(DefaultCoreSession.java:255)
        at
org.apache.directory.server.core.shared.DefaultCoreSession.add(DefaultCoreSession.java:239)
        at
org.apache.directory.server.ldap.handlers.request.AddRequestHandler.handle(AddRequestHandler.java:57)
        at
org.apache.directory.server.ldap.handlers.request.AddRequestHandler.handle(AddRequestHandler.java:39)
        at
org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:207)
        at
org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56)
        at
org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:221)
        at
org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:217)
        at
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:690)
        at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
        at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
        at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
        at
org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74)
        at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
        at
org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:474)
        at
org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:428)
        at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -19960
        at jdbm.recman.BlockIo.readInt(BlockIo.java:282)
        at jdbm.recman.RecordHeader.getAvailableSize(RecordHeader.java:105)
        at
jdbm.recman.PhysicalRowIdManager.allocNew(PhysicalRowIdManager.java:216)
        at
jdbm.recman.PhysicalRowIdManager.alloc(PhysicalRowIdManager.java:177)
        at
jdbm.recman.PhysicalRowIdManager.update(PhysicalRowIdManager.java:101)
        at jdbm.recman.BaseRecordManager.update(BaseRecordManager.java:281)
        at
jdbm.recman.CacheRecordManager.updateCacheEntries(CacheRecordManager.java:417)
        at
jdbm.recman.CacheRecordManager.commit(CacheRecordManager.java:349)
        at
org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.sync(JdbmTable.java:977)
        at
org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.sync(JdbmPartition.java:324)
        at
org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.add(AbstractBTreePartition.java:852)
        ... 48 more
]; remaining name 'cn=something@something.com'
        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3131)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
        at com.sun.jndi.ldap.LdapCtx.c_createSubcontext(LdapCtx.java:811)
        at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(ComponentDirContext.java:337)
        at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:266)
        at
javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:202)
        .....

Re: getting LDAP: error code 80 - OTHER: failed for MessageType : ADD_REQUEST

Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 02/11/15 16:59, Negoita Ionut a écrit :
> Hi,

Hi,
>
> we have been using ApacheDS 2.0.0-M17 for about a year and from time to
> time the data gets corrupted leaving us no other choice but to create a
> fresh installation, export then import what data we can. This is very
> frustrating and also dangerous for us to deploy in a production environment.
>
> What happens is that after a while of usage adding an entry (a user) gives
> an error, and any additions after that fail. All entries for which the
> error occurs cannot be found anymore (using ApacheDS Studio or via Java),
> when trying to re-add them we get an error saying that an entry with the
> same cn already exists, and we cannot delete the entry since we can't find
> it.
>
> Please help, what are we doing wrong? Do we have to set some settings?
> We've had similar problems with version since M11, and upgraded hoping this
> will not occur anymore.

You are not doing anything wrong... Sadly :/

There is a known problem in the JDBM backend we are using, and that
leads to data corruption from time to time. We are working on replacing
this backend by Mavibot, but this is far from being simple - beside teh
fact that we are lacking of time to work on it -.

As of today, we have something working, but we are still lacking the
cross-btree transaction taht is critical from a performance POV. This is
what we are working on.

I can't give you any expectation for a release that use Mavibot, that
could be a few weeks, or a few monts (depends on day job/familly life
and the number of hours we can squeeze out of insomnia...)