[Date Prev][Date Next] [Chronological] [Thread] [Top]

Implementation-specific error 80. (from another angle)



Greetings; I'm also seeing fairly frequent problems with internal error 80;
Many of the times, I can figure out where I managed to bludgeon an entry into
or out of only one of the index or the id2entry.  But in this case in
particular, I appear to have signs of an un-cleaned-up cache.

I am running 2.1.12 on AIX 5.1  Here's what I'm trying to do


dn: uflEduUniversityId=30132600, ou=People, dc=ufl, dc=edu
changetype: delete

dn: uflEduUniversityId=30132600, ou=People, dc=ufl, dc=edu
changetype: add
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: eduPerson
objectclass: uflEduPerson
[....]


and here's the log trace of the interaction.

]: conn=18 op=0 BIND dn="uid=root,dc=ufl,dc=edu" method=128
]: conn=18 op=0 AUTHZ dn="uid=root,dc=ufl,dc=edu" mech=simple ssf=0
]: conn=18 op=0 RESULT tag=97 err=0 text=
]: conn=18 op=1 DEL dn="uflEduUniversityId=30132600,ou=People,dc=ufl,dc=edu"
]: conn=18 op=1 RESULT tag=107 err=0 text=
]: conn=18 op=2 ADD dn="uflEduUniversityId=30132600,ou=People,dc=ufl,dc=edu"
]: ====> cache_add_entry( 1 ): "uflEduUniversityId=30132600,ou=People,dc=ufl,dc=edu": already in id cache
]: cache_add_entry_lock failed
]: conn=18 op=2 RESULT tag=105 err=80 text=cache add failed
]: conn=18 op=3 UNBIND
]: conn=18 fd=7 closed

It _appears_ that, even after the delete is reported complete, the ID is still
active in the cache.  Or maybe I'm smoking something.

Is the cache here a cache openLDAP manages, or is it something that is taken
care of by bdb?  

If I restart slapd, (of course) the new insert goes through, and often I can
make the complete delete-add cycle work.  But in a series of (say) 150 of
them, I seldom reach the end.

I'm certain it ought not to matter, but I've got a dn2entry that's closing in
on 3G.



- Allen S. Rout