[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