directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <ayasel...@gmail.com>
Subject Re: Txn branch issues
Date Mon, 27 Feb 2012 18:57:10 GMT
thanks Emmanuel. I put my fixes on top of your changes which were
there last week(when I started working on the code again). Only
reverting to that point is good enough. Once I can verify the tests
and check in the code, I will give a status update.

thanks
Selcuk
On Mon, Feb 27, 2012 at 10:50 AM, Emmanuel Lecharny
<elecharny@apache.org> wrote:
> Ok, np.
>
> The best would probably be to start back from the revision you used when you
> left in december, and consider what I have done since as a best effort, but
> not sufficient.
>
> What is important is to see how we can keep the txn at the right place (ie
> in the opManager), *if* it's the best place.
>
> Frankly, I have *no* problem reverting what I have done. It already had the
> advantage for me to get a bit of understanding on what you have done, even
> if it wasn't not good enough to stabilize the code.
>
> So atm, what I would suggest is that we revert, you can then continue
> without having conflicts, get the branch working with mvn (running in
> eclipse is not enough), and when you are done, we can consider mergng back
> in trunk.
>
> Sounds like a plan for you ?
>
> PS : at some point, we *really* need to share what you have done to be sure
> we can fix a bug without destroying the original work.
>
> Thanks !
>
>
>
> On Mon, Feb 27, 2012 at 7:29 PM, Selcuk AYA <ayaselcuk@gmail.com> wrote:
>>
>> I fixed quite a bit of issues and got the tests to work at least in
>> eclipse(not checked with mvn yet). I was going to commit but saw some
>> changes did an svn up and the files ended up in conflict.Also I saw
>> some changes to search layer trying to fix some stuff which actuyally
>> wont fix anything. If possible please roll back all your latest check
>> in. Just a status update of what works and what doesnt work will be
>> enough at this point and I will ask for further help if i need coding
>> help.
>>
>> On Mon, Feb 27, 2012 at 8:31 AM, Emmanuel Lécharny <elecharny@gmail.com>
>> wrote:
>> > Hi Selcuk,
>> >
>> > so I had time this morning to get back to the branch, and focus on the
>> > error
>> > I have. Here is a sumary of the pb.
>> >
>> > First, I have @ignored a few failing tests :
>> > - in PasswordPolicy, because the failure has nothing to do with the txns
>> > - then for the PagedSearch tests, because I haven't -yet- restored the
>> > way
>> > it was deling with txns in your initial branch
>> >
>> > Otherwise, the rest of tests are passing with flying colors, except one
>> > test
>> > in ldap-client-test module :
>> > ClientSearchRequestTest.testSeaechPersonSubstring() is failing.
>> >
>> > What happens is that we get back may entries which don't fit the
>> > "(objectclass=*ers*)" filter (12 entries, instead of 3).
>> >
>> > Here are the returned entries :
>> >
>> > Entry
>> >    dn: cn=Administrators,ou=groups,ou=system
>> >    objectClass: top
>> >    objectClass: groupOfUniqueNames
>> >    createTimestamp: 20120227140034Z
>> >    uniqueMember: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >    entryUUID: 027f4818-79a7-4974-a363-148f9f37ff6b
>> >    cn: Administrators
>> >    entryCSN: 20120227140034.983000Z#000000#000#000000
>> >    entryParentId: ae9ab7f6-5afb-4345-b801-2424714ffd84
>> >    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >
>> > Entry
>> >    dn: ou=configuration,ou=system
>> >    objectClass: top
>> >    objectClass: organizationalUnit
>> >    createTimestamp: 20120227140034Z
>> >    ou: configuration
>> >    entryUUID: 2ddf826e-14c5-441f-9907-7d54524fbde7
>> >    entryCSN: 20120227140034.994000Z#000000#000#000000
>> >    entryParentId: 69acb598-559f-4ca9-8aa4-bd63096cd100
>> >    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >
>> > Entry (OK)
>> >    dn: uid=admin,ou=system
>> >    objectClass: top
>> >    objectClass: person
>> >    objectClass: organizationalPerson
>> >    objectClass: inetOrgPerson
>> >    objectClass: tlsKeyInfo
>> >    uid: admin
>> >    privateKeyFormat: PKCS#8
>> >    createTimestamp: 20120227140034Z
>> >    sn: administrator
>> >    entryUUID: 399e0da3-beae-4bc5-8d33-5d113607c07f
>> >    entryParentId: 69acb598-559f-4ca9-8aa4-bd63096cd100
>> >    publicKey: 0\0
>> >    displayName: Directory Superuser
>> >    userCertificate: 0? ?0? 0   5? ? 0
>> >
>> > Entry
>> >    dn: ou=users,ou=system
>> >    objectClass: top
>> >    objectClass: organizationalUnit
>> >    createTimestamp: 20120227140034Z
>> >    ou: users
>> >    entryUUID: 548c6635-d95b-45af-899f-3585d9af774c
>> >    entryCSN: 20120227140034.965000Z#000000#000#000000
>> >    entryParentId: 69acb598-559f-4ca9-8aa4-bd63096cd100
>> >    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >
>> > Entry
>> >    dn: ou=system
>> >    objectClass: top
>> >    objectClass: organizationalUnit
>> >    objectClass: extensibleObject
>> >    createTimestamp: 20120227140034Z
>> >    ou: system
>> >    entryUUID: 69acb598-559f-4ca9-8aa4-bd63096cd100
>> >    entryCSN: 20120227140034.551000Z#000000#000#000000
>> >    entryParentId: 00000000-0000-0000-0000-000000000000
>> >    creatorsName: uid=admin,ou=system
>> >
>> > Entry
>> >    dn: prefNodeName=sysPrefRoot,ou=system
>> >    objectClass: top
>> >    objectClass: organizationalUnit
>> >    objectClass: extensibleObject
>> >    createTimestamp: 20120227140035Z
>> >    entryUUID: 6f0e6dc3-2fe3-4616-bab9-33ac7dc8e0dd
>> >    prefNodeName: sysPrefRoot
>> >    entryCSN: 20120227140035.044000Z#000000#000#000000
>> >    entryParentId: 69acb598-559f-4ca9-8aa4-bd63096cd100
>> >    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >
>> > Entry
>> >    dn: ou=partitions,ou=configuration,ou=system
>> >    objectClass: top
>> >    objectClass: organizationalUnit
>> >    createTimestamp: 20120227140035Z
>> >    ou: partitions
>> >    entryUUID: 868ee0ae-5b31-4646-a8b9-b2896aab8efe
>> >    entryCSN: 20120227140035.010000Z#000000#000#000000
>> >    entryParentId: 2ddf826e-14c5-441f-9907-7d54524fbde7
>> >    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >
>> > Entry
>> >    dn: ou=services,ou=configuration,ou=system
>> >    objectClass: top
>> >    objectClass: organizationalUnit
>> >    createTimestamp: 20120227140035Z
>> >    ou: services
>> >    entryUUID: 9f06c097-6a21-4fbe-94b2-830d7d1967fe
>> >    entryCSN: 20120227140035.023000Z#000000#000#000000
>> >    entryParentId: 2ddf826e-14c5-441f-9907-7d54524fbde7
>> >    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >
>> > Entry (OK)
>> >    dn: cn=elecharny,ou=users,ou=system
>> >    objectclass: person
>> >    objectclass: top
>> >    createTimestamp: 20120227140035Z
>> >    sn: Emmanuel Lécharny
>> >    entryUUID: a8fa279b-cefe-4747-aa5c-952899cb041a
>> >    cn: elecharny
>> >    entryCSN: 20120227140035.268000Z#000000#000#000000
>> >    entryParentId: 548c6635-d95b-45af-899f-3585d9af774c
>> >    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >
>> > Entry
>> >    dn: ou=groups,ou=system
>> >    objectClass: top
>> >    objectClass: organizationalUnit
>> >    createTimestamp: 20120227140034Z
>> >    ou: groups
>> >    entryUUID: ae9ab7f6-5afb-4345-b801-2424714ffd84
>> >    entryCSN: 20120227140034.974000Z#000000#000#000000
>> >    entryParentId: 69acb598-559f-4ca9-8aa4-bd63096cd100
>> >    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >
>> > Entry (OK)
>> >    dn: cn=user1,ou=users,ou=system
>> >    objectclass: person
>> >    objectclass: top
>> >    createTimestamp: 20120227140035Z
>> >    sn: user1 sn
>> >    entryUUID: be3072a9-fc95-4782-bac0-e2a0f3cf0e21
>> >    cn: user1
>> >    entryCSN: 20120227140035.214000Z#000000#000#000000
>> >    entryParentId: 548c6635-d95b-45af-899f-3585d9af774c
>> >    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >
>> > Entry
>> >    dn: ou=interceptors,ou=configuration,ou=system
>> >    objectClass: top
>> >    objectClass: organizationalUnit
>> >    createTimestamp: 20120227140035Z
>> >    ou: interceptors
>> >    entryUUID: f4dfd59b-f03e-4b8b-932c-8a6bdf603c46
>> >    entryCSN: 20120227140035.034000Z#000000#000#000000
>> >    entryParentId: 2ddf826e-14c5-441f-9907-7d54524fbde7
>> >    creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >
>> >
>> > While debugging the code, it seems that at some point, we try to fetch
>> > the
>> > entry using the ObjectClass index, but sadly, it returns the wrong UUID
>> > so
>> > we fetch an entry which has not the right ObjectClass.
>> >
>> > It's difficult to tell why the index does not refer to correct entries,
>> > as
>> > the test is adding the entries at the beginning, and generates some new
>> > UUID
>> > each time you run it, so it makes the debugging very painful.
>> >
>> > However, debugging ClientSearchRequestTest.testSeaechPersonSubstring()
>> > can
>> > lead to see where the error come from.
>> >
>> > Feel free to contact me for more insights, I'll be working late tonite.
>> >
>> > --
>> > Regards,
>> > Cordialement,
>> > Emmanuel Lécharny
>> > www.iktek.com
>> >
>
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com

Mime
View raw message