directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: Txn branch issues
Date Mon, 27 Feb 2012 18:50:43 GMT
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