You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Sergey Mikhno <se...@gmail.com> on 2019/05/01 13:01:18 UTC

Re: uniqueMember Index

Hi Emmanuel,

I can see now that you have already fixed the problem.
We have M24 running now, how can I use your fix in our environment?
Or otherwise how can I build the latest snapshot to be able to verify it?

Best regards

Sergey Mikhno
Software Developer
Galexis AG


On Tue, Apr 30, 2019 at 4:40 PM Emmanuel Lécharny <el...@gmail.com>
wrote:

> I have created a JIRA ticket for this issue:
> https://issues.apache.org/jira/browse/DIRAPI-340
>
> Incidentally, I also have a fix that I'm going to test and apply asap.
> (the fix is pretty straightforward)
>
>
> On 30/04/2019 16:29, Sergey Mikhno wrote:
> > Thank you again,
> >
> > Is it possible to get a fix for this issue, how should we go about it?
> > It would be great to be able to test a bugfix in our environment.
> >
> > Best Regards
> >
> > Sergey
> >
> >
> > On Tue, Apr 30, 2019 at 4:24 PM Emmanuel Lécharny <el...@gmail.com>
> > wrote:
> >
> >> Ok, this a clear bug. The UniqueMemberComparator.compare() method is
> >> badly implemented, and returns either 0 or -1, which means we can't
> >> browse the index, as we never get a +1 (ie, provided uniqueMember is
> >> superior to the stored one).
> >>
> >> I'll get that fixed.
> >>
> >> On 30/04/2019 15:59, Emmanuel Lécharny wrote:
> >>> Hi Sergey,
> >>>
> >>>
> >>> I can positively confirm that there is a problem. I'm able to
> >>> reproduce the issue you are facing in a unit test.
> >>>
> >>> I'm currently debugging the server, and hope to come with a quick
> >>> answer (and hopefully a fix).
> >>>
> >>>
> >>> On 30/04/2019 11:33, Sergey Mikhno wrote:
> >>>> Dear Emmanuel,
> >>>>
> >>>> I spent now more than a week trying to understand why uniqueMember
> index
> >>>> doesn't work and still have no progress in understanding the problem.
> >>>>
> >>>> With a defined index on uniqueMember my query brings empty result
> >>>>
> >>>> *(**&*
> >>>>
> >>>>       *(*objectclass*=*groupOfUniqueNames*)*
> >>>>
> >>>>       *(**|*
> >>>>
> >>>>           *(*uniqueMember*=*cn=galexisLoginPOS*)*
> >>>>
> >>>>           *(*uniqueMember*=*cn=customerGalexis*)*
> >>>>
> >>>>           *(*uniqueMember*=*cn=customerAlloga*)*
> >>>>
> >>>>           *(*uniqueMember*=*cn=isDemo*)*
> >>>>
> >>>>       *)*
> >>>>
> >>>> *)*
> >>>>
> >>>>
> >>>>
> >>>> Without index the query brings correct results but is slow, 300ms.
> >>>> Is there any description about how to define an index on uniqueMember.
> >>>>
> >>>> We have several other non-standard indexed attributes and all of them
> >>>> are
> >>>> working.
> >>>> As I understand it should be possible to define an index on both
> >>>> member and
> >>>> uniqieMember.
> >>>>
> >>>> So I have 2 questions:
> >>>> 1. Is it correct that this query is slow because there is no index?
> >>>> 2. How should I define such an index?
> >>>>
> >>>> Below is the current index definition
> >>>> dn:
> >>>>
> >>
> ads-indexAttributeId=uniqueMember,ou=indexes,ads-partitionId=system,ou=parti
> >>
> >>>>    tions,ads-directoryServiceId=default,ou=config
> >>>> ads-indexHasReverse: FALSE
> >>>> entryCSN: 20190430090357.476000Z#000000#001#000000
> >>>> objectClass: ads-index
> >>>> objectClass: top
> >>>> objectClass: ads-jdbmIndex
> >>>> objectClass: ads-base
> >>>> createTimestamp: 20190430090357.476Z
> >>>> creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
> >>>> ads-indexAttributeId: uniqueMember
> >>>> ads-enabled: TRUE
> >>>> entryUUID: dcd2fa31-5ee0-48fb-9d3e-30487957045a
> >>>> entryParentId: fdf6f3a6-dfaf-4b1a-962c-faa14328d1ae
> >>>>
> >>>> Could you please advice?
> >>>>
> >
>


-- 
Sergey Mikhno

Re: uniqueMember Index

Posted by Sergey Mikhno <se...@gmail.com>.
Hi Emmanuel,

We built the trunk today and the results are as follows: UniqueMember query
without index has become faster, the same query with the index gives empty
result back.
Is it possible that our index definition is wrong?
We are defining the index in Apache Directory Studio.

The Comparator looks to be correct. What can be the problem?

Best regards

Sergey Mikhno
Software Developer
Galexis AG


On Wed, May 1, 2019 at 3:01 PM Sergey Mikhno <se...@gmail.com>
wrote:

> Hi Emmanuel,
>
> I can see now that you have already fixed the problem.
> We have M24 running now, how can I use your fix in our environment?
> Or otherwise how can I build the latest snapshot to be able to verify it?
>
> Best regards
>
> Sergey Mikhno
> Software Developer
> Galexis AG
>
>
> On Tue, Apr 30, 2019 at 4:40 PM Emmanuel Lécharny <el...@gmail.com>
> wrote:
>
>> I have created a JIRA ticket for this issue:
>> https://issues.apache.org/jira/browse/DIRAPI-340
>>
>> Incidentally, I also have a fix that I'm going to test and apply asap.
>> (the fix is pretty straightforward)
>>
>>
>> On 30/04/2019 16:29, Sergey Mikhno wrote:
>> > Thank you again,
>> >
>> > Is it possible to get a fix for this issue, how should we go about it?
>> > It would be great to be able to test a bugfix in our environment.
>> >
>> > Best Regards
>> >
>> > Sergey
>> >
>> >
>> > On Tue, Apr 30, 2019 at 4:24 PM Emmanuel Lécharny <el...@gmail.com>
>> > wrote:
>> >
>> >> Ok, this a clear bug. The UniqueMemberComparator.compare() method is
>> >> badly implemented, and returns either 0 or -1, which means we can't
>> >> browse the index, as we never get a +1 (ie, provided uniqueMember is
>> >> superior to the stored one).
>> >>
>> >> I'll get that fixed.
>> >>
>> >> On 30/04/2019 15:59, Emmanuel Lécharny wrote:
>> >>> Hi Sergey,
>> >>>
>> >>>
>> >>> I can positively confirm that there is a problem. I'm able to
>> >>> reproduce the issue you are facing in a unit test.
>> >>>
>> >>> I'm currently debugging the server, and hope to come with a quick
>> >>> answer (and hopefully a fix).
>> >>>
>> >>>
>> >>> On 30/04/2019 11:33, Sergey Mikhno wrote:
>> >>>> Dear Emmanuel,
>> >>>>
>> >>>> I spent now more than a week trying to understand why uniqueMember
>> index
>> >>>> doesn't work and still have no progress in understanding the problem.
>> >>>>
>> >>>> With a defined index on uniqueMember my query brings empty result
>> >>>>
>> >>>> *(**&*
>> >>>>
>> >>>>       *(*objectclass*=*groupOfUniqueNames*)*
>> >>>>
>> >>>>       *(**|*
>> >>>>
>> >>>>           *(*uniqueMember*=*cn=galexisLoginPOS*)*
>> >>>>
>> >>>>           *(*uniqueMember*=*cn=customerGalexis*)*
>> >>>>
>> >>>>           *(*uniqueMember*=*cn=customerAlloga*)*
>> >>>>
>> >>>>           *(*uniqueMember*=*cn=isDemo*)*
>> >>>>
>> >>>>       *)*
>> >>>>
>> >>>> *)*
>> >>>>
>> >>>>
>> >>>>
>> >>>> Without index the query brings correct results but is slow, 300ms.
>> >>>> Is there any description about how to define an index on
>> uniqueMember.
>> >>>>
>> >>>> We have several other non-standard indexed attributes and all of them
>> >>>> are
>> >>>> working.
>> >>>> As I understand it should be possible to define an index on both
>> >>>> member and
>> >>>> uniqieMember.
>> >>>>
>> >>>> So I have 2 questions:
>> >>>> 1. Is it correct that this query is slow because there is no index?
>> >>>> 2. How should I define such an index?
>> >>>>
>> >>>> Below is the current index definition
>> >>>> dn:
>> >>>>
>> >>
>> ads-indexAttributeId=uniqueMember,ou=indexes,ads-partitionId=system,ou=parti
>> >>
>> >>>>    tions,ads-directoryServiceId=default,ou=config
>> >>>> ads-indexHasReverse: FALSE
>> >>>> entryCSN: 20190430090357.476000Z#000000#001#000000
>> >>>> objectClass: ads-index
>> >>>> objectClass: top
>> >>>> objectClass: ads-jdbmIndex
>> >>>> objectClass: ads-base
>> >>>> createTimestamp: 20190430090357.476Z
>> >>>> creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
>> >>>> ads-indexAttributeId: uniqueMember
>> >>>> ads-enabled: TRUE
>> >>>> entryUUID: dcd2fa31-5ee0-48fb-9d3e-30487957045a
>> >>>> entryParentId: fdf6f3a6-dfaf-4b1a-962c-faa14328d1ae
>> >>>>
>> >>>> Could you please advice?
>> >>>>
>> >
>>
>
>
> --
> Sergey Mikhno
>


-- 
Sergey Mikhno