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 Lécharny <el...@gmail.com> on 2012/02/27 17:31:24 UTC
Txn branch issues
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?05? ?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
Re: Txn branch issues
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/28/12 10:22 AM, Selcuk AYA a écrit :
> branch is now in working state and tests are passing. You can
> uncomment passwordpolicy test too as it should pass as well. I will
> get back to working on this later.
Great job !!!
Thanks Selcuk !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Txn branch issues
Posted by Selcuk AYA <ay...@gmail.com>.
branch is now in working state and tests are passing. You can
uncomment passwordpolicy test too as it should pass as well. I will
get back to working on this later.
thanks
Selcuk
On Mon, Feb 27, 2012 at 12:22 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Selcuk,
>
> before doing anything, *do* a backup of you changes. Save them somwhere
> (even if it's merged with the svn up you've did).
>
>
> Le 2/27/12 8:31 PM, Selcuk AYA a écrit :
>
>> How do I revert a file while preserving my local changes? Is that
>> possible with svn once I do an svn up? I could you could revert the
>> latest commit and doing an svn up on my side would resolve the issue.
>>
>> thanks
>> Selcuk
>>
>> On Mon, Feb 27, 2012 at 11:01 AM, Emmanuel Lécharny<el...@gmail.com>
>> wrote:
>>>
>>> Le 2/27/12 7:57 PM, Selcuk AYA a écrit :
>>>
>>>> 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.
>>>
>>> Oh, ok. So then you can simply revert up to the version you find useful.
>>> Don't be afraid to 'delete' whatever I did, in any case, if for any
>>> (stupid)
>>> rrason I need to get it back, subversion will have keep it.
>>>
>>> Many thanks !
>>>
>>> FYI, I have debugged a bit more and found that the added entry with the
>>> 'person' OC has somehow mess up the UUID index, so now, all the entries
>>> are
>>> linked to the<person,<added entry UUID>> pair.
>>>
>>> I have some trace if you need, but I guess you already fixed it.
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: Txn branch issues
Posted by Emmanuel Lécharny <el...@gmail.com>.
Selcuk,
before doing anything, *do* a backup of you changes. Save them somwhere
(even if it's merged with the svn up you've did).
Le 2/27/12 8:31 PM, Selcuk AYA a écrit :
> How do I revert a file while preserving my local changes? Is that
> possible with svn once I do an svn up? I could you could revert the
> latest commit and doing an svn up on my side would resolve the issue.
>
> thanks
> Selcuk
>
> On Mon, Feb 27, 2012 at 11:01 AM, Emmanuel Lécharny<el...@gmail.com> wrote:
>> Le 2/27/12 7:57 PM, Selcuk AYA a écrit :
>>
>>> 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.
>> Oh, ok. So then you can simply revert up to the version you find useful.
>> Don't be afraid to 'delete' whatever I did, in any case, if for any (stupid)
>> rrason I need to get it back, subversion will have keep it.
>>
>> Many thanks !
>>
>> FYI, I have debugged a bit more and found that the added entry with the
>> 'person' OC has somehow mess up the UUID index, so now, all the entries are
>> linked to the<person,<added entry UUID>> pair.
>>
>> I have some trace if you need, but I guess you already fixed it.
>>
>>
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Txn branch issues
Posted by Selcuk AYA <ay...@gmail.com>.
How do I revert a file while preserving my local changes? Is that
possible with svn once I do an svn up? I could you could revert the
latest commit and doing an svn up on my side would resolve the issue.
thanks
Selcuk
On Mon, Feb 27, 2012 at 11:01 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 2/27/12 7:57 PM, Selcuk AYA a écrit :
>
>> 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.
>
> Oh, ok. So then you can simply revert up to the version you find useful.
> Don't be afraid to 'delete' whatever I did, in any case, if for any (stupid)
> rrason I need to get it back, subversion will have keep it.
>
> Many thanks !
>
> FYI, I have debugged a bit more and found that the added entry with the
> 'person' OC has somehow mess up the UUID index, so now, all the entries are
> linked to the <person, <added entry UUID>> pair.
>
> I have some trace if you need, but I guess you already fixed it.
>
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: Txn branch issues
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/27/12 7:57 PM, Selcuk AYA a écrit :
> 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.
Oh, ok. So then you can simply revert up to the version you find useful.
Don't be afraid to 'delete' whatever I did, in any case, if for any
(stupid) rrason I need to get it back, subversion will have keep it.
Many thanks !
FYI, I have debugged a bit more and found that the added entry with the
'person' OC has somehow mess up the UUID index, so now, all the entries
are linked to the <person, <added entry UUID>> pair.
I have some trace if you need, but I guess you already fixed it.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Txn branch issues
Posted by Selcuk AYA <ay...@gmail.com>.
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
<el...@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 <ay...@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 <el...@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
Re: Txn branch issues
Posted by Emmanuel Lecharny <el...@apache.org>.
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 <ay...@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 <el...@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
Re: Txn branch issues
Posted by Selcuk AYA <ay...@gmail.com>.
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 <el...@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
>