You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2012/01/04 20:51:11 UTC
Strange issue with the txns when injecting entris with ApplyLdif

Hi,

i'm facing a strange problem. The client-api-test 
ClientSearchRequestTest.testSearchPersonSubstring() is failing on 
Selcuk's branch(with my modifications), and was working on Selcuk's 
branch before my modifications. The search returns too more entries (the 
filter tells the server to return all the entries with an Ojectclass 
containing *ers* - person, for instance-, and we get 12 entries instead 
of 3).

I have debugged the code most of the day, and the difference between 
those two versions is that the previous version does not initiate a txn 
when injecting the LDIFs into the server, when the new version does 
(because it's using the coreSession).
OTOH, this should not be a problem at all : the newly added entries are 
visible (using Studio), and the search is done after the modification.

As a matter of fact, when we are walking the cursors during the search, 
up to a point, we read data from the txnIndexCursor in the new code, 
when this cursor is null in the old code. I don't know well this part of 
this cod, but my understanding is that this txnIndexCursor is supposed 
to be used to read the data stored in the changeLog (ie, data which has 
been modified but not flushed yet to the disk). IMO, even if the cursor 
is not null, we shuld not grab element from it, but sadly, we do.

Here are the three changes done before the search :

[
IndexChange 'apacheRdn': <ADD, b881e633-e69c-43b5-905e-c731632f0f8e, 
ParentIdAndRdn<1e5c8c99-63d6-4218-8700-f61e420713aa, 'cn=user1'>>,
IndexChange 'objectClass': <ADD, b881e633-e69c-43b5-905e-c731632f0f8e, 
person>,
IndexChange 'objectClass': <ADD, b881e633-e69c-43b5-905e-c731632f0f8e, 
top>,
IndexChange 'apacheOneLevel': <ADD, 
b881e633-e69c-43b5-905e-c731632f0f8e, 
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD, 
b881e633-e69c-43b5-905e-c731632f0f8e, 
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD, 
b881e633-e69c-43b5-905e-c731632f0f8e, 
b881e633-e69c-43b5-905e-c731632f0f8e>,
IndexChange 'entryCSN': <ADD, b881e633-e69c-43b5-905e-c731632f0f8e, 
20120104194007.961000Z#000000#000#000000>,
IndexChange 'entryUUID': <ADD, b881e633-e69c-43b5-905e-c731632f0f8e, 
b881e633-e69c-43b5-905e-c731632f0f8e>,
EntryAddDelete change : ADD
Entry
     dn[n]: cn=user1,ou=users,ou=system
     objectclass: person
     objectclass: top
     cn: user1
     sn: user1 sn
     entryParentId: 1e5c8c99-63d6-4218-8700-f61e420713aa
     entryUUID: b881e633-e69c-43b5-905e-c731632f0f8e
     creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
     createTimestamp: 20120104194007Z
     entryCSN: 20120104194007.961000Z#000000#000#000000
]

[
IndexChange 'apacheRdn': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42, 
ParentIdAndRdn<1e5c8c99-63d6-4218-8700-f61e420713aa, 'cn=user1-alias'>>,
IndexChange 'objectClass': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42, 
extensibleObject>,
IndexChange 'objectClass': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42, 
alias>,
IndexChange 'objectClass': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42, 
top>,
IndexChange 'apacheAlias': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42, 
2.5.4.3=user1,2.5.4.11=users,2.5.4.11=system>,
IndexChange 'apacheOneLevel': <ADD, 
9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42, 
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD, 
9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42, 
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD, 
9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42, 
9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42>,
IndexChange 'entryCSN': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42, 
20120104194128.727000Z#000000#000#000000>,
IndexChange 'entryUUID': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42, 
9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42>,
EntryAddDelete change : ADD
Entry
     dn[n]: cn=user1-alias,ou=users,ou=system
     objectclass: extensibleObject
     objectclass: alias
     objectclass: top
     aliasedobjectname: cn=user1,ou=users,ou=system
     cn: user1-alias
     entryParentId: 1e5c8c99-63d6-4218-8700-f61e420713aa
     entryUUID: 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42
     creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
     createTimestamp: 20120104194128Z
     entryCSN: 20120104194128.727000Z#000000#000#000000
]

[
IndexChange 'apacheRdn': <ADD, 588509f4-ad9e-4aef-84a7-bee04e64b872, 
ParentIdAndRdn<1e5c8c99-63d6-4218-8700-f61e420713aa, 'cn=elecharny'>>,
IndexChange 'objectClass': <ADD, 588509f4-ad9e-4aef-84a7-bee04e64b872, 
person>,
IndexChange 'objectClass': <ADD, 588509f4-ad9e-4aef-84a7-bee04e64b872, 
top>,
IndexChange 'apacheOneLevel': <ADD, 
588509f4-ad9e-4aef-84a7-bee04e64b872, 
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD, 
588509f4-ad9e-4aef-84a7-bee04e64b872, 
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD, 
588509f4-ad9e-4aef-84a7-bee04e64b872, 
588509f4-ad9e-4aef-84a7-bee04e64b872>,
IndexChange 'entryCSN': <ADD, 588509f4-ad9e-4aef-84a7-bee04e64b872, 
20120104194227.433000Z#000000#000#000000>,
IndexChange 'entryUUID': <ADD, 588509f4-ad9e-4aef-84a7-bee04e64b872, 
588509f4-ad9e-4aef-84a7-bee04e64b872>,
EntryAddDelete change : ADD
Entry
     dn[n]: cn=elecharny,ou=users,ou=system
     objectclass: person
     objectclass: top
     cn: elecharny
     sn: Emmanuel Lécharny
     entryParentId: 1e5c8c99-63d6-4218-8700-f61e420713aa
     entryUUID: 588509f4-ad9e-4aef-84a7-bee04e64b872
     creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
     createTimestamp: 20120104194227Z
     entryCSN: 20120104194227.433000Z#000000#000#000000
]


When we fetch the candidate from the ObjectClass index, we will now get 
tuple found from the backend, and tuples grabbed from the changes, and 
both entries are returned to the client. At this point, I have no idea 
what can go wrong... Any help would be greatly appreciated :)


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com