You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Mark D <te...@debusschere.com> on 2014/02/25 18:53:32 UTC
Suggestions for troubleshooting filters.
I am having hard time understanding filters.
I have 3 partitions with suffix
dc=cnu1456
dc=test3,dc=com
dc=test5,dc=com
They all appear to have similar attributes structure with appropriate values.
Using a separate test app and Apache Directory Studio the following filter only returns 2 out of 3 expected.
(&(dc=*)(objectClass=zimbraDomain))
If I try (objectClass=zimbraDomain) I get 2 out of 3 but different combination.
>From what I understand both filters are true for all 3.
I am using search base of root / empty.
I am using current TRUNK build. This behavior has always been an issue for me.
So, is there a log property or something I have missed to help debug / learn what it's comparison logic.
Re: Suggestions for troubleshooting filters.
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 3/12/14 7:21 PM, Mark D a écrit :
> It appears this is case sensitive, does that sound right ?
>
> ads-enabled: TRUE ( works )
> ads-enabled: true ( didn't work ).
Indeed.
>
> Second, if this attribute IS not defined that is the same as being FALSE (not enabled)
This is the default value, yes.
>
> Per Kiran's comments "the server handles filters like (xxx=*) correctly even when there is no
> index on 'xxx' attribute"
I may be wrong, but if the xxx attribute is not indexed, it should work.
If it's not, then it's a bug (all in all, it will do a full scan)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Suggestions for troubleshooting filters.
Posted by Kiran Ayyagari <ka...@apache.org>.
On Wed, Mar 12, 2014 at 11:51 PM, Mark D <te...@debusschere.com> wrote:
> It appears this is case sensitive, does that sound right ?
>
> ads-enabled: TRUE ( works )
> ads-enabled: true ( didn't work ).
>
> no, ApacheDS allows boolean values in both cases
> Second, if this attribute IS not defined that is the same as being FALSE
> (not enabled)
>
> right
> Per Kiran's comments "the server handles filters like (xxx=*) correctly
> even when there is no
> index on 'xxx' attribute"
>
> I didn't see that behavior, searching did not find it period.
>
> did you test it on a brand new server instance like I mentioned in an
earlier reply?
--
Kiran Ayyagari
http://keydap.com
Re: Suggestions for troubleshooting filters.
Posted by Mark D <te...@debusschere.com>.
It appears this is case sensitive, does that sound right ?
ads-enabled: TRUE ( works )
ads-enabled: true ( didn't work ).
Second, if this attribute IS not defined that is the same as being FALSE (not enabled)
Per Kiran's comments "the server handles filters like (xxx=*) correctly even when there is no
index on 'xxx' attribute"
I didn't see that behavior, searching did not find it period.
Re: Suggestions for troubleshooting filters.
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Mar 6, 2014 at 12:44 PM, Mark D <te...@debusschere.com> wrote:
> Well, despite some self inflected pain and suffering I am feeling much
> better about using AD ;)
>
> First, it can't remain this way. I think index should work just DB in the
> idea that it is
> in complete sync with row (data). It should certainly rebuild / reindex
> on a restart, creation.
>
> we do perform this (in JdbmParition) for a _new_ index but not for
existing indices that
were disabled and enabled after creation.
> If a match is not found in the index it shouldn't go back an do an entire
> scan.
>
> nope this makes indices useless and search becomes a full scan all the time
the onus is on the administrator to fix the broken indices.
> I understand that is big under taking. I did my best to figure this out
> in the docs.
> Until this gets resolved, an updated filter section in the docs with
> example would
> possibly save another person from frustration.
>
note that the issue you are facing is due to an incorrect index,
the server handles filters like (xxx=*) correctly even when there is no
index on 'xxx' attribute
(Emmanuel thought that there is a bug in the server in his previous reply,
but there is _no_ such
bug in the server)
>
> Looking forward to better results !!
>
> I would suggest you to test the (xxx=*) filter on a brand new instance of
the server after injecting
some test data (you can even inject few entries in the default
dc=example,dc=com partition for this)
to verify
> Also, I was looking at the index description early in the docs.
> It doesn't show the default value or Enabled attribute for that matter.
>
>
> http://directory.apache.org/apacheds/configuration/ads-2.0-configuration.html
>
> Thanks,
>
--
Kiran Ayyagari
http://keydap.com
Re: Suggestions for troubleshooting filters.
Posted by Mark D <te...@debusschere.com>.
Well, despite some self inflected pain and suffering I am feeling much better about using AD ;)
First, it can't remain this way. I think index should work just DB in the idea that it is
in complete sync with row (data). It should certainly rebuild / reindex on a restart, creation.
If a match is not found in the index it shouldn't go back an do an entire scan.
I understand that is big under taking. I did my best to figure this out in the docs.
Until this gets resolved, an updated filter section in the docs with example would
possibly save another person from frustration.
Looking forward to better results !!
Also, I was looking at the index description early in the docs.
It doesn't show the default value or Enabled attribute for that matter.
http://directory.apache.org/apacheds/configuration/ads-2.0-configuration.html
Thanks,
Re: Suggestions for troubleshooting filters.
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 3/6/14 6:54 AM, Mark D a écrit :
> Well, you may have helped uncover something. I thought I had indexes
> When I look at config in ApacheStudio it shows the indexes on the partitions.
> When I looked at config file, I noted the following index attributes were missing.
>
> ads-enabled: TRUE
> ads-indexcachesize: 100
>
> Note, a few partitions I was testing were created dynamically and not through
> the Studio. Hence I was responsible for those missing.
Definitively, the ads-enabled attribute *must* be TRUE (FALSE is teh
default AFAIR). The other one has a default valu of 100.
>
> So, I added ads-enabled: TRUE to the UID index for the partition.
> Restarted AD. Ran test search which failed with same results.
> I then added a new entry to the partition and ran search again.
> It now finds the entry with UID.
Expected.
>
> So, it this possibly the issue ?
Yes, absolutely.
> When I search with filter (objectClass=namedObject)
> it always worked. Does 'x=*' have to be indexed, whereas '=' searches anything ?
Those are two different indexes. the (xxx=*) will match every entry
having the xxx attributeType, and we use the prsenceIndex for that, when
the (xxx=blah) use the xxx index to fetch entries having an
attributeType xxx having the value blah.
Note that the (xxx=*) filter will only work *if* xxx is indexed...
One vicious thing is that if uid is not indexed, filters like (uid=blah)
will work, but (uid=*) won't. The reason is that when we have and
indexed attribute like uid, we will use the index to fetch entries , so
here, as we always have a presence index, we will use it, and as uid is
not indexed, we won't find any entry associated with (uid=*).
Now, thinking out loud I think that we are doing a very big disservice
here : just because we do'nt have an index on uid should *never* be an
issue for the user, except that the response time will be way lower. In
other words, indexes should speedup the serahces, not break them.
That deserves a JIRA, IMO.
>
> I have been suffering for a while with so many filters not working with (x=*).
I can understand...
>
> My confusion has been based on
> 1) I was testing with one partition which evidently was a partition created from the Studio
> and I was comparing behavior to the new dynamic created partition.
> 2) In ADStudio, the configs visually appear the same regarding indexes.
>
> I am back to recreating all test partitions etc and see if this changes things.
I'm quite sure it will work fine if you do that.
In the mean time, I'll create an issue to get the server respect our
users and *always* do the search and return valid entries except when
the index is created *after* the entry has already been created (we
do'nt reindex on the fly, sadly. Note that we should and we will, but
not in this current version).
> Thanks.
>
Thanks to you for having raised this issue !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Suggestions for troubleshooting filters.
Posted by Mark D <te...@debusschere.com>.
Well, you may have helped uncover something. I thought I had indexes
When I look at config in ApacheStudio it shows the indexes on the partitions.
When I looked at config file, I noted the following index attributes were missing.
ads-enabled: TRUE
ads-indexcachesize: 100
Note, a few partitions I was testing were created dynamically and not through
the Studio. Hence I was responsible for those missing.
So, I added ads-enabled: TRUE to the UID index for the partition.
Restarted AD. Ran test search which failed with same results.
I then added a new entry to the partition and ran search again.
It now finds the entry with UID.
So, it this possibly the issue ? When I search with filter (objectClass=namedObject)
it always worked. Does 'x=*' have to be indexed, whereas '=' searches anything ?
I have been suffering for a while with so many filters not working with (x=*).
My confusion has been based on
1) I was testing with one partition which evidently was a partition created from the Studio
and I was comparing behavior to the new dynamic created partition.
2) In ADStudio, the configs visually appear the same regarding indexes.
I am back to recreating all test partitions etc and see if this changes things.
Thanks.
Re: Suggestions for troubleshooting filters.
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 3/5/14 8:38 PM, Mark D a écrit :
> Should this relatively simple filter (uid=*) return everything with a 'uid' attribute ?
Yes.
> In ApacheDS it only displays one record. It doesn't show DNs expected in
> another partition. I tried setting base search to the other partition and it returns nothing.
Weird...
Have you created an index on uid ?
If so, have you created it *after* having injected the data ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Suggestions for troubleshooting filters.
Posted by Mark D <te...@debusschere.com>.
Should this relatively simple filter (uid=*) return everything with a 'uid' attribute ?
In ApacheDS it only displays one record. It doesn't show DNs expected in
another partition. I tried setting base search to the other partition and it returns nothing.
I don't fully understand the cursor references below. I thought cursor would hold
matching references.
I deleted some of the IndexEntries below so email wouldn't be so long.
------------
[11:03:55] DEBUG [org.apache.directory.server.ldap.handlers.request.SearchRequestHandler] - Handling single reply request: MessageType : SEARCH_REQUEST
Message ID : 25
SearchRequest
baseDn : ''
filter : '(uid=*)'
scope : whole subtree
typesOnly : false
Size Limit : 5000
Time Limit : no limit
Deref Aliases : deref Always
attributes : 'objectClass'
org.apache.directory.api.ldap.model.message.SearchRequestImpl@802e3cd2
[11:03:55] DEBUG [org.apache.directory.server.ldap.handlers.request.SearchRequestHandler] - ManageDsaITControl NOT detected.
[11:03:55] DEBUG [org.apache.directory.server.ldap.handlers.request.SearchRequestHandler] - Entry is NOT a referral.
[11:03:55] DEBUG [org.apache.directory.server.ldap.handlers.request.SearchRequestHandler] - Message received: MessageType : SEARCH_REQUEST
Message ID : 25
SearchRequest
baseDn : ''
filter : '(uid=*)'
scope : whole subtree
typesOnly : false
Size Limit : 5000
Time Limit : no limit
Deref Aliases : deref Always
attributes : 'objectClass'
org.apache.directory.api.ldap.model.message.SearchRequestImpl@802e3cd2
[11:03:55] DEBUG [org.apache.directory.server.OPERATION_LOG] - >> SearchOperation : SearchContext for Dn '', filter :'(uid=*)'
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating AvlSingletonOrOrderedSetCursor org.apache.directory.server.core.avltree.AvlSingletonOrOrderedSetCursor@52f6c35f
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating AvlTreeMapNoDupsWrapperCursor org.apache.directory.server.core.avltree.AvlTreeMapNoDupsWrapperCursor@4694bc86
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating IndexCursorAdaptor IndexCursorAdaptor (absent) :
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating SetCursor SetCursor :
Index : -1
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating EntryCursorAdaptor EntryCursorAdaptor
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating BaseEntryFilteringCursor BaseEntryFilteringCursor, no wrapped
No filter
No prefetched
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating SetCursor SetCursor :
Index : -1
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating EntryCursorAdaptor EntryCursorAdaptor
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating BaseEntryFilteringCursor BaseEntryFilteringCursor, no wrapped
No filter
No prefetched
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating SetCursor SetCursor :
Index : -1
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating EntryCursorAdaptor EntryCursorAdaptor
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating BaseEntryFilteringCursor BaseEntryFilteringCursor, no wrapped
No filter
No prefetched
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating SetCursor SetCursor :
Index : -1
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating EntryCursorAdaptor EntryCursorAdaptor
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating BaseEntryFilteringCursor BaseEntryFilteringCursor, no wrapped
No filter
No prefetched
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating ArrayTreeCursor ArrayTreeCursor (absent)
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating KeyTupleArrayCursor KeyTupleArrayCursor (absent)#0.9.2342.19200300.100.1.1 :
ArrayTreeCursor (absent)
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating IndexCursorAdaptor IndexCursorAdaptor (absent) :
KeyTupleArrayCursor (absent)#0.9.2342.19200300.100.1.1 :
ArrayTreeCursor (absent)
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing IndexCursorAdaptor IndexCursorAdaptor (absent) :
KeyTupleArrayCursor (absent)#0.9.2342.19200300.100.1.1 :
ArrayTreeCursor (absent)
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing KeyTupleArrayCursor KeyTupleArrayCursor (absent)#0.9.2342.19200300.100.1.1 :
ArrayTreeCursor (absent)
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing ArrayTreeCursor ArrayTreeCursor (absent)
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating SetCursor SetCursor :
Index : -1
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating EntryCursorAdaptor EntryCursorAdaptor
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating BaseEntryFilteringCursor BaseEntryFilteringCursor, no wrapped
No filter
No prefetched
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating AvlSingletonOrOrderedSetCursor org.apache.directory.server.core.avltree.AvlSingletonOrOrderedSetCursor@4ee5259d
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating AvlTreeMapNoDupsWrapperCursor org.apache.directory.server.core.avltree.AvlTreeMapNoDupsWrapperCursor@26088ee2
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating IndexCursorAdaptor IndexCursorAdaptor (absent) :
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating SetCursor SetCursor :
Index : -1
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating EntryCursorAdaptor EntryCursorAdaptor
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating BaseEntryFilteringCursor BaseEntryFilteringCursor, no wrapped
No filter
No prefetched
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Creating CursorList org.apache.directory.server.core.api.filtering.CursorList@7bdcaaef
[11:03:55] DEBUG [org.apache.directory.server.OPERATION_LOG] - << SearchOperation successful
[11:03:55] DEBUG [org.apache.directory.server.ldap.handlers.request.SearchRequestHandler] - using <5000,5000> for size limit
[11:03:55] DEBUG [org.apache.directory.server.ldap.handlers.request.SearchRequestHandler] - Sending uid=admin,ou=system
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing CursorList org.apache.directory.server.core.api.filtering.CursorList@7bdcaaef
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing CursorList org.apache.directory.server.core.api.filtering.CursorList@7bdcaaef
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing BaseEntryFilteringCursor BaseEntryFilteringCursor, wrapped :
EntryCursorAdaptor
IndexCursor :
SetCursor :
Index : 118
Size : 118
IndexEntry[ c09b3b91-dd9a-46b6-965c-678c3e6ad7eb, c09b3b91-dd9a-46b6-965c-678c3e6ad7eb ]
IndexEntry[ 2cb2d861-e84d-40f3-94b3-3a16ba5de0bc, 2cb2d861-e84d-40f3-94b3-3a16ba5de0bc ]
deleted ....
IndexEntry[ c6136964-a7d7-4d41-93bd-ea700bf3e21f, c6136964-a7d7-4d41-93bd-ea700bf3e21f ]
Evaluator :
AndEvaluator : (&:[118](uid=*:[?])(#{SUBTREE_SCOPE (Estimated), 'ou=config', DEREF_ALWAYS}:[118]))
SubstreeScopeEvaluator : (#{SUBTREE_SCOPE (Estimated), 'ou=config', DEREF_ALWAYS}:[118])
PresenceEvaluator : (uid=*:[?])
Filters :
HideSubentriesFilter
CollectiveAttributeFilter
TopFilter
DefaultAuthorizationSearchFilter
No prefetched
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing EntryCursorAdaptor EntryCursorAdaptor
IndexCursor :
SetCursor :
Index : 118
Size : 118
IndexEntry[ c09b3b91-dd9a-46b6-965c-678c3e6ad7eb, c09b3b91-dd9a-46b6-965c-678c3e6ad7eb ]
IndexEntry[ 2cb2d861-e84d-40f3-94b3-3a16ba5de0bc, 2cb2d861-e84d-40f3-94b3-3a16ba5de0bc ]
deleted...
IndexEntry[ c6136964-a7d7-4d41-93bd-ea700bf3e21f, c6136964-a7d7-4d41-93bd-ea700bf3e21f ]
Evaluator :
AndEvaluator : (&:[118](uid=*:[?])(#{SUBTREE_SCOPE (Estimated), 'ou=config', DEREF_ALWAYS}:[118]))
SubstreeScopeEvaluator : (#{SUBTREE_SCOPE (Estimated), 'ou=config', DEREF_ALWAYS}:[118])
PresenceEvaluator : (uid=*:[?])
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
Index : 118
Size : 118
IndexEntry[ c09b3b91-dd9a-46b6-965c-678c3e6ad7eb, c09b3b91-dd9a-46b6-965c-678c3e6ad7eb ]
IndexEntry[ 2cb2d861-e84d-40f3-94b3-3a16ba5de0bc, 2cb2d861-e84d-40f3-94b3-3a16ba5de0bc ]
deleted...
IndexEntry[ c6136964-a7d7-4d41-93bd-ea700bf3e21f, c6136964-a7d7-4d41-93bd-ea700bf3e21f ]
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing BaseEntryFilteringCursor BaseEntryFilteringCursor, wrapped :
EntryCursorAdaptor
IndexCursor :
SetCursor :
Index : 0
Evaluator :
EmptyEvaluator
Filters :
HideSubentriesFilter
CollectiveAttributeFilter
TopFilter
DefaultAuthorizationSearchFilter
No prefetched
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing EntryCursorAdaptor EntryCursorAdaptor
IndexCursor :
SetCursor :
Index : 0
Evaluator :
EmptyEvaluator
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
Index : 0
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing BaseEntryFilteringCursor BaseEntryFilteringCursor, wrapped :
EntryCursorAdaptor
IndexCursor :
SetCursor :
Index : 0
Evaluator :
EmptyEvaluator
Filters :
HideSubentriesFilter
CollectiveAttributeFilter
TopFilter
DefaultAuthorizationSearchFilter
No prefetched
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing EntryCursorAdaptor EntryCursorAdaptor
IndexCursor :
SetCursor :
Index : 0
Evaluator :
EmptyEvaluator
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
Index : 0
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing BaseEntryFilteringCursor BaseEntryFilteringCursor, wrapped :
EntryCursorAdaptor
IndexCursor :
SetCursor :
Index : 0
Evaluator :
EmptyEvaluator
Filters :
HideSubentriesFilter
CollectiveAttributeFilter
TopFilter
DefaultAuthorizationSearchFilter
No prefetched
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing EntryCursorAdaptor EntryCursorAdaptor
IndexCursor :
SetCursor :
Index : 0
Evaluator :
EmptyEvaluator
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
Index : 0
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing BaseEntryFilteringCursor BaseEntryFilteringCursor, wrapped :
EntryCursorAdaptor
IndexCursor :
SetCursor :
Index : 1
Size : 1
IndexEntry[ null, ad49747a-0491-418f-b6d7-97b331755c93 ]
Evaluator :
AndEvaluator : (&:[1](uid=*:[?])(#{SUBTREE_SCOPE (Estimated), 'ou=system', DEREF_ALWAYS}))
PresenceEvaluator : (uid=*:[?])
SubstreeScopeEvaluator : (#{SUBTREE_SCOPE (Estimated), 'ou=system', DEREF_ALWAYS})
Filters :
HideSubentriesFilter
CollectiveAttributeFilter
TopFilter
DefaultAuthorizationSearchFilter
No prefetched
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing EntryCursorAdaptor EntryCursorAdaptor
IndexCursor :
SetCursor :
Index : 1
Size : 1
IndexEntry[ null, ad49747a-0491-418f-b6d7-97b331755c93 ]
Evaluator :
AndEvaluator : (&:[1](uid=*:[?])(#{SUBTREE_SCOPE (Estimated), 'ou=system', DEREF_ALWAYS}))
PresenceEvaluator : (uid=*:[?])
SubstreeScopeEvaluator : (#{SUBTREE_SCOPE (Estimated), 'ou=system', DEREF_ALWAYS})
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
Index : 1
Size : 1
IndexEntry[ null, ad49747a-0491-418f-b6d7-97b331755c93 ]
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing BaseEntryFilteringCursor BaseEntryFilteringCursor, wrapped :
EntryCursorAdaptor
IndexCursor :
SetCursor :
Index : 2612
Size : 2612
IndexEntry[ b232606f-3e28-4c98-9a57-20ee4b3c10ea, b232606f-3e28-4c98-9a57-20ee4b3c10ea ]
IndexEntry[ 7beb799c-668f-4972-b805-c7ba0786044f, 7beb799c-668f-4972-b805-c7ba0786044f ]
deleted
IndexEntry[ 98e7f648-d9f9-46fb-8bbd-3b827b657124, 98e7f648-d9f9-46fb-8bbd-3b827b657124 ]
Evaluator :
AndEvaluator : (&:[2612](uid=*:[?])(#{SUBTREE_SCOPE (Estimated), 'ou=schema', DEREF_ALWAYS}:[2612]))
SubstreeScopeEvaluator : (#{SUBTREE_SCOPE (Estimated), 'ou=schema', DEREF_ALWAYS}:[2612])
PresenceEvaluator : (uid=*:[?])
[11:03:55] DEBUG [org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
Index : 2612
Size : 2612
IndexEntry[ b232606f-3e28-4c98-9a57-20ee4b3c10ea, b232606f-3e28-4c98-9a57-20ee4b3c10ea ]
IndexEntry[ 7beb799c-668f-4972-b805-c7ba0786044f, 7beb799c-668f-4972-b805-c7ba0786044f ]
deleted.
IndexEntry[ 98e7f648-d9f9-46fb-8bbd-3b827b657124, 98e7f648-d9f9-46fb-8bbd-3b827b657124 ]
Re: Suggestions for troubleshooting filters.
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/26/14 7:32 PM, mark debusschere a écrit :
> Did my best to build, verified sync'd through http://svn.apache.org/viewvc/directory/apacheds/trunk/?sortby=date&pathrev=1572064
>
> Search still fails to match as expected against objectClass.
>
> I am going to try and create a test case with LDIF to import for JIRA.
That would be great !
>
> Is there any chance this could be related to older jdbm impl. I have been testing
> with same instance for a couple of months.
I don't think so. On option would be that some indexes are not correctly
set, but unlikely if you have not upgraded since you started.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Suggestions for troubleshooting filters.
Posted by mark debusschere <ma...@debusschere.com>.
Did my best to build, verified sync'd through http://svn.apache.org/viewvc/directory/apacheds/trunk/?sortby=date&pathrev=1572064
Search still fails to match as expected against objectClass.
I am going to try and create a test case with LDIF to import for JIRA.
Is there any chance this could be related to older jdbm impl. I have been testing
with same instance for a couple of months.
Re: Suggestions for troubleshooting filters.
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/26/14 6:38 AM, Kiran Ayyagari a écrit :
> On Wed, Feb 26, 2014 at 10:40 AM, Emmanuel Lécharny <el...@gmail.com>wrote:
>
>> Le 2/26/14 4:14 AM, mark debusschere a écrit :
>>> I don't get it, this filter doesn't return expected results :
>> (objectClass=zimbraDomain)
>>> but (zimbraDomainName=*) works as expected
>>> and (zimbraDomainName=Name) works as expected
>>>
>>> I think I ran into this before. I ended up using plain attributes
>> because they seem to match as expected.
>>> Would this be realted to the objectClass being part of a custom schema ?
>> No, not really. ObjecClass is a standard indexed attribute, so you
>> should gte what you are expecting to get here.
>>
>> Just to be sure, are you doing those tests against the current Apache
>> Directory Server trunk ?
>>
>> If so, I would suggest to create a JIRA, because there is something
>> fishy that we need to solve before cutting a release.
>>
>> I confirm that this is a bug, am working on a fix
I just applied a patch in trunk. It would be interesting to check that
the pb is solved with the initial test.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Suggestions for troubleshooting filters.
Posted by Kiran Ayyagari <ka...@apache.org>.
On Wed, Feb 26, 2014 at 10:40 AM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 2/26/14 4:14 AM, mark debusschere a écrit :
> > I don't get it, this filter doesn't return expected results :
> (objectClass=zimbraDomain)
> >
> > but (zimbraDomainName=*) works as expected
> > and (zimbraDomainName=Name) works as expected
> >
> > I think I ran into this before. I ended up using plain attributes
> because they seem to match as expected.
> >
> > Would this be realted to the objectClass being part of a custom schema ?
> No, not really. ObjecClass is a standard indexed attribute, so you
> should gte what you are expecting to get here.
>
> Just to be sure, are you doing those tests against the current Apache
> Directory Server trunk ?
>
> If so, I would suggest to create a JIRA, because there is something
> fishy that we need to solve before cutting a release.
>
> I confirm that this is a bug, am working on a fix
> Thanks !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: Suggestions for troubleshooting filters.
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/26/14 4:14 AM, mark debusschere a écrit :
> I don't get it, this filter doesn't return expected results : (objectClass=zimbraDomain)
>
> but (zimbraDomainName=*) works as expected
> and (zimbraDomainName=Name) works as expected
>
> I think I ran into this before. I ended up using plain attributes because they seem to match as expected.
>
> Would this be realted to the objectClass being part of a custom schema ?
No, not really. ObjecClass is a standard indexed attribute, so you
should gte what you are expecting to get here.
Just to be sure, are you doing those tests against the current Apache
Directory Server trunk ?
If so, I would suggest to create a JIRA, because there is something
fishy that we need to solve before cutting a release.
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Suggestions for troubleshooting filters.
Posted by mark debusschere <ma...@debusschere.com>.
I don't get it, this filter doesn't return expected results : (objectClass=zimbraDomain)
but (zimbraDomainName=*) works as expected
and (zimbraDomainName=Name) works as expected
I think I ran into this before. I ended up using plain attributes because they seem to match as expected.
Would this be realted to the objectClass being part of a custom schema ?
Re: Suggestions for troubleshooting filters.
Posted by Mark D <te...@debusschere.com>.
In Apache studio, the filter has
Controls: nothing is checked.
Scope is Subtree
Alias Dereferencing, both checked Finding Base DN, Search
Limits: count 1000, time: 0
Referral Handing: Follow Referrals automatically ( tried all 3 ).
The partitions show dc, objectClass have indexes.
dn: dc=cnu1472gwr
objectClass: amavisAccount
objectClass: dcObject
objectClass: organization
objectClass: zimbraDomain
dc: cnu1472gwr
o: cnu1472gwr domain
zimbraDomainName: cnu1472gwr
zimbraDomainType: local
zimbraCreateTimestamp: 20130821050200Z
zimbraDomainStatus: active
zimbraGalInternalSearchBase: ROOT
zimbraMailStatus: enabled
zimbraPrefTimeZoneId: America/Los_Angeles
dn: dc=test3,dc=com
objectClass: amavisAccount
objectClass: dcObject
objectClass: organization
objectClass: top
objectClass: zimbraDomain
dc: test3
o: test3.com domain
zimbraDomainName: test3.com
zimbraDomainType: local
zimbraCreateTimestamp: 20131103164251Z
zimbraDomainStatus: active
zimbraGalMode: zimbra
zimbraMailStatus: enabled
zimbraPrefTimeZoneId: America/Los_Angeles
dn: dc=test5,dc=com
objectClass: amavisAccount
objectClass: dcObject
objectClass: organization
objectClass: top
objectClass: zimbraDomain
dc: test5
o: test5.com domain
zimbraDomainName: test5.com
zimbraDomainType: local
zimbraCreateTimestamp: 20140225094941Z
zimbraDomainStatus: active
zimbraMailStatus: enabled
----- Original Message -----
From: "Kiran Ayyagari" <ka...@apache.org>
To: users@directory.apache.org
Sent: Tuesday, February 25, 2014 10:37:06 AM
Subject: Re: Suggestions for troubleshooting filters.
what is the value of search scope?
On Tue, Feb 25, 2014 at 11:23 PM, Mark D <te...@debusschere.com> wrote:
> I am having hard time understanding filters.
>
> I have 3 partitions with suffix
> dc=cnu1456
> dc=test3,dc=com
> dc=test5,dc=com
>
> They all appear to have similar attributes structure with appropriate
> values.
> Using a separate test app and Apache Directory Studio the following filter
> only returns 2 out of 3 expected.
>
> (&(dc=*)(objectClass=zimbraDomain))
>
> If I try (objectClass=zimbraDomain) I get 2 out of 3 but different
> combination.
>
> From what I understand both filters are true for all 3.
>
> I am using search base of root / empty.
>
> I am using current TRUNK build. This behavior has always been an issue
> for me.
>
> So, is there a log property or something I have missed to help debug /
> learn what it's comparison logic.
>
>
>
--
Kiran Ayyagari
http://keydap.com
Re: Suggestions for troubleshooting filters.
Posted by Kiran Ayyagari <ka...@apache.org>.
what is the value of search scope?
On Tue, Feb 25, 2014 at 11:23 PM, Mark D <te...@debusschere.com> wrote:
> I am having hard time understanding filters.
>
> I have 3 partitions with suffix
> dc=cnu1456
> dc=test3,dc=com
> dc=test5,dc=com
>
> They all appear to have similar attributes structure with appropriate
> values.
> Using a separate test app and Apache Directory Studio the following filter
> only returns 2 out of 3 expected.
>
> (&(dc=*)(objectClass=zimbraDomain))
>
> If I try (objectClass=zimbraDomain) I get 2 out of 3 but different
> combination.
>
> From what I understand both filters are true for all 3.
>
> I am using search base of root / empty.
>
> I am using current TRUNK build. This behavior has always been an issue
> for me.
>
> So, is there a log property or something I have missed to help debug /
> learn what it's comparison logic.
>
>
>
--
Kiran Ayyagari
http://keydap.com