[jira] [Commented] (IGNITE-12291) Create controllable paged query requests / responses for TextQuery similar to current SQL result processing
[ https://issues.apache.org/jira/browse/IGNITE-12291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025211#comment-17025211 ] Yuriy Shuliha commented on IGNITE-12291: - [~Pavlukhin] you are right with the question. As per ordered nature of TextQuery via Lucene, the client should receive responses from all node in order to merge results and sort them correctly. The query with limit works as this: for limit 1000 we must receive at least 1000 entries from every node, merge and sort them. This is the only correct way it can be implemented using existing distributed queries mechanism. So this ticked seems to be obsolete and should be dismissed. > Create controllable paged query requests / responses for TextQuery similar to > current SQL result processing > --- > > Key: IGNITE-12291 > URL: https://issues.apache.org/jira/browse/IGNITE-12291 > Project: Ignite > Issue Type: Improvement >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > > For now query initiator node sends 1 _GridCacheQueryRequest_ and can get > multiple _GridCacheQueryResponse_-s per remote. > TextQuery processing finishes when all remotes send _GridCacheQueryResponse_ > with 'finished' flag. > _TextQuery_ processing should be reworked like it was done for SQL queries. > Ignite has _GridQueryNextPageRequest \ Response_ classes for SQL result > processing. > Similar processing should be implemented for _TextQueries_: > *GridTextQueryNextPageRequest* > *GridTextQueryNextPageResponse* > Proper _TextQuery_ response processing should be implemented in > _GridCacheQueryFutureAdapter._ > This will allow us to add correct sorting and apply limit correctly on reduce. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12401) Some Text Queries return repeated results
[
https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985221#comment-16985221
]
Yuriy Shuliha edited comment on IGNITE-12401 at 11/30/19 12:17 AM:
After investigations, there're 2 causes of tests failure found:
*1. Related to Range tests only*
{{testTextQueryWithRange()}} uses range {{"[10 TO 20}" }}In this case the
Lucene response "unexpectedly" will also contain a key "2", but this key is not
among expected keys, because they are selected by predicate {{x ->
String.valueOf( x ).startsWith("1")}} .
The clue is that here Lucene compares range boundaries as Strings. Where "10"
is less then "2" and "20" is less then "3".
[https://docs.oracle.com/javase/7/docs/api/java/lang/String.html#compareTo(java.lang.String)]
More detailed explanation:
For {{v IN range[A TO B]}}
Lucene uses rather the next logic with string comparison (black-box tested by
me):
{{(A.compareTo(v) <= inclusive ? 0 : -1) && (B.compareTo(v) >= inclusive ? 0 :
1)}}
{{=== A range 10 includes === === B range 20 excludes ===}}
{{"10".compareTo("2") == -1 "20".compareTo("2") == 1 // passed, false
positive}}
{{"10".compareTo("15") == -5 "20".compareTo("15") == 1 // passed}}
{{"10".compareTo("25") == -1 "20".compareTo("20") == 0 // passed}}
{{"10".compareTo("3") == -2 "20".compareTo("3") == -1 // not passed}}
*2. Distributed Query produces responses from two nodes that partially contain
the same keys*
When checking the text query response, I noticed that GridLuceneIndex.query()
was executed on 2 grids/nodes per single request. This is expected for
distributed query. But on the other hand is cache mode is PARTITIONED, they
should not contain overlapping keys.
But here Lucene indexes on different nodes definitely contain data from the
same partition.
During final join with limit, key duplicates appears in response, that fails
assertion where unique values are expected.
Backups are set to 0 for current cache. Does it mean that entities are
incorrectly distributed over partitions/nodes?
This part needs extra investigations.
Still no direct links found with this issue and {{limits}} introduced earlier.
CC [~amashenkov], [~Pavlukhin]
was (Author: yuriy_shuliha):
After investigations, there're 2 causes of tests failure found:
*1. Related to Range tests only*
{{testTextQueryWithRange()}} uses range {{"[10 TO 20}" }}In this case the
Lucene response "unexpectedly" will also contain a key "2", but this key is not
among expected keys, because they are selected by predicate {{x ->
String.valueOf(x).startsWith("1")}} .
The clue is that here Lucene compares range boundaries as Strings. Where "10"
is less then "2" and "20" is less then "3".
[https://docs.oracle.com/javase/7/docs/api/java/lang/String.html#compareTo(java.lang.String)]
More detailed explanation:
For {{v IN range[A TO B]}}
Lucene uses rather the next logic with string comparison (black-box tested by
me):
{{(A.compareTo(v) <= inclusive ? 0 : -1) && (B.compareTo(v) >= inclusive ? 0 :
1)}}
{{=== A range 10 includes === === B range 20 excludes ===}}
{{"10".compareTo("2") == -1 "20".compareTo("2") == 1 // passed, false
positive}}
{{"10".compareTo("15") == -5 "20".compareTo("15") == 1 // passed}}
{{"10".compareTo("25") == -1 "20".compareTo("20") == 0 // passed}}
{{"10".compareTo("3") == -2 "20".compareTo("3") == -1 // not passed}}
*2. Distributed Query produces responses from two nodes that partially contain
the same keys*
When checking the text query response, I noticed that GridLuceneIndex.query()
was executed on 2 grids/nodes per single request. This is expected for
distributed query. But on the other hand is cache mode is PARTITIONED, they
should not contain overlapping keys.
But here Lucene indexes on different nodes definitely contain data from the
same partition.
During final join with limit, key duplicates appears in response, that fails
assertion where unique values are expected.
Backups are set to 0 for current cache. Does it mean that entities are
incorrectly distributed over partitions/nodes?
This part needs extra investigations.
Still no direct links found with this issue and {{limits}} introduced earlier.
CC [~amashenkov], [~Pavlukhin]
> Some Text Queries return repeated results
> -
>
> Key: IGNITE-12401
> URL: https://issues.apache.org/jira/browse/IGNITE-12401
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Yuriy Shuliha
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It came to my attention while checking for Range Queries support that we
> don't actually check that found query results are
[jira] [Commented] (IGNITE-12401) Some Text Queries return repeated results
[
https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985221#comment-16985221
]
Yuriy Shuliha commented on IGNITE-12401:
-
After investigations, there're 2 causes of tests failure found:
*1. Related to Range tests only*
{{testTextQueryWithRange()}} uses range {{"[10 TO 20}" }}In this case the
Lucene response "unexpectedly" will also contain a key "2", but this key is not
among expected keys, because they are selected by predicate {{x ->
String.valueOf(x).startsWith("1")}} .
The clue is that here Lucene compares range boundaries as Strings. Where "10"
is less then "2" and "20" is less then "3".
[https://docs.oracle.com/javase/7/docs/api/java/lang/String.html#compareTo(java.lang.String)]
More detailed explanation:
For {{v IN range[A TO B]}}
Lucene uses rather the next logic with string comparison (black-box tested by
me):
{{(A.compareTo(v) <= inclusive ? 0 : -1) && (B.compareTo(v) >= inclusive ? 0 :
1)}}
{{=== A range 10 includes === === B range 20 excludes ===}}
{{"10".compareTo("2") == -1 "20".compareTo("2") == 1 // passed, false
positive}}
{{"10".compareTo("15") == -5 "20".compareTo("15") == 1 // passed}}
{{"10".compareTo("25") == -1 "20".compareTo("20") == 0 // passed}}
{{"10".compareTo("3") == -2 "20".compareTo("3") == -1 // not passed}}
*2. Distributed Query produces responses from two nodes that partially contain
the same keys*
When checking the text query response, I noticed that GridLuceneIndex.query()
was executed on 2 grids/nodes per single request. This is expected for
distributed query. But on the other hand is cache mode is PARTITIONED, they
should not contain overlapping keys.
But here Lucene indexes on different nodes definitely contain data from the
same partition.
During final join with limit, key duplicates appears in response, that fails
assertion where unique values are expected.
Backups are set to 0 for current cache. Does it mean that entities are
incorrectly distributed over partitions/nodes?
This part needs extra investigations.
Still no direct links found with this issue and {{limits}} introduced earlier.
CC [~amashenkov], [~Pavlukhin]
> Some Text Queries return repeated results
> -
>
> Key: IGNITE-12401
> URL: https://issues.apache.org/jira/browse/IGNITE-12401
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Yuriy Shuliha
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It came to my attention while checking for Range Queries support that we
> don't actually check that found query results are the correct ones.
> We were checking that we got some results, but not whether they were expected.
> And voila, it turns out that Range Queries examples, as well as some other
> test cases, will readily fail when run with such checks! A query will return
> same value repeatedly, e.g. range query will return the "1" record twice, and
> limited text query will return "14" record twice.
> It didn't really occur on non-range queries before the introduction of limits.
> I think we should not ship broken limit queries. Maybe also fix range
> queries, if it's hard let's @Ignore them for now.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12401) Some Text Queries return repeated results
[ https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuriy Shuliha reassigned IGNITE-12401: --- Assignee: Yuriy Shuliha > Some Text Queries return repeated results > - > > Key: IGNITE-12401 > URL: https://issues.apache.org/jira/browse/IGNITE-12401 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Yuriy Shuliha >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It came to my attention while checking for Range Queries support that we > don't actually check that found query results are the correct ones. > We were checking that we got some results, but not whether they were expected. > And voila, it turns out that Range Queries examples, as well as some other > test cases, will readily fail when run with such checks! A query will return > same value repeatedly, e.g. range query will return the "1" record twice, and > limited text query will return "14" record twice. > It didn't really occur on non-range queries before the introduction of limits. > I think we should not ship broken limit queries. Maybe also fix range > queries, if it's hard let's @Ignore them for now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12389) Make GridCacheQueryFutureAdapter.enqueue() use parameter of List type instead Collection
Yuriy Shuliha created IGNITE-12389:
---
Summary: Make GridCacheQueryFutureAdapter.enqueue() use parameter
of List type instead Collection
Key: IGNITE-12389
URL: https://issues.apache.org/jira/browse/IGNITE-12389
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.7.6
Reporter: Yuriy Shuliha
Fix For: 2.8
Make {{GridCacheQueryFutureAdapter.enqueue(Collection col)}} use parameter
of List type instead Collection
This will allow to avoid new {{ArrayList}} creation and directly call
performance tolerant {{List.subList()}} method .
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971542#comment-16971542 ] Yuriy Shuliha commented on IGNITE-12189: - [~Pavlukhin] - added the "Release Note" > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 11h > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuriy Shuliha updated IGNITE-12189: Release Note: Added 'limit' as parameter for TextQuery constructor and builder. Use 'limit' to set response size to avoid fetching of all the documents that match the query string. If its value is 0 or less, considered to be no limit. Existing constructors without 'limit' parameter did not change functionality and create TextQuery object with 'limit' = 0. > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 11h > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971457#comment-16971457 ] Yuriy Shuliha commented on IGNITE-12189: - [~Pavlukhin] - Sorry for delay, was on vacation last week. I will create the ticket about passing `List` in nearest day-two. > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971455#comment-16971455 ] Yuriy Shuliha commented on IGNITE-12189: - [~Pavlukhin] There's no more work to be done on the ticket. Please do merge. CC [~dma...@apache.org] > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16966879#comment-16966879 ] Yuriy Shuliha commented on IGNITE-12189: - [~Pavlukhin] - running TC tests now ([https://ci.ignite.apache.org/viewLog.html?buildId=4747159=IgniteTests24Java8_RunAll]) >From 19 failed tests 15 are suggested by TC as flaky, 14 of them are new as >well. The tests related to Text Queries are green. Could you please suggest how to proceed with this? What is the acceptable steps to resolve/consider this PR to be ready to merge? > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964902#comment-16964902 ] Yuriy Shuliha commented on IGNITE-12189: - [~Pavlukhin] - #2 did resolved according to your comments. Please check GitHub > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964264#comment-16964264 ] Yuriy Shuliha commented on IGNITE-12189: - [~Pavlukhin] - did resolved according to your comments. Please check GitHub. > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 9h 40m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16961071#comment-16961071 ] Yuriy Shuliha edited comment on IGNITE-12189 at 10/28/19 2:04 PM: --- [~amashenkov], [~Pavlukhin] the recent changes requested by you were implemented. Current realization still coming with 0 or less as unlimited value. Lets go with this or consider -1 to move forward this PR. CC: [~dma...@apache.org] was (Author: yuriy_shuliha): [~amashenkov], [~Pavlukhin] the recent changes requested by you whore implemented. Current realization still coming with 0 or less as unlimited value. Lets go with this or consider -1 to move forward this PR. CC: [~dma...@apache.org] > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 8h 10m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16961071#comment-16961071 ] Yuriy Shuliha edited comment on IGNITE-12189 at 10/28/19 2:03 PM: --- [~amashenkov], [~Pavlukhin] the recent changes requested by you whore implemented. Current realization still coming with 0 or less as unlimited value. Lets go with this or consider -1 to move forward this PR. CC: [~dma...@apache.org] was (Author: yuriy_shuliha): [~amashenkov], [~Pavlukhin] the recent changes requested by you whore implemented. Current realization still coming with 0 or less as unlimited value. Lets go with this or consider -1 to move forward this PR. > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 8h 10m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16961071#comment-16961071 ] Yuriy Shuliha commented on IGNITE-12189: - [~amashenkov], [~Pavlukhin] the recent changes requested by you whore implemented. Current realization still coming with 0 or less as unlimited value. Lets go with this or consider -1 to move forward this PR. > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 8h 10m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956980#comment-16956980 ] Yuriy Shuliha commented on IGNITE-12189: - 'total' and 'limit' merged into single 'totalCnt' int variable Corresponding unit tests have run successfully. CC: [~amashenkov] > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956977#comment-16956977 ] Yuriy Shuliha commented on IGNITE-12189: - On behalf of [~amashenkov] >>> I've found GridCacheQueryFutureAdapter has newly added AtomicInteger 'total' field and 'limit; field as primitive int. Both fields are used inside synchronized block only. So, we can make both private and downgrade AtomicInteger to primitive int. Most likely, these fields can be replaced with one field. >>> > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952012#comment-16952012 ] Yuriy Shuliha commented on IGNITE-12189: - [~amashenkov] IGNITE-12291 ticket was created and linekd > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952012#comment-16952012 ] Yuriy Shuliha edited comment on IGNITE-12189 at 10/15/19 3:17 PM: --- [~amashenkov] IGNITE-12291 ticket was created and linked was (Author: yuriy_shuliha): [~amashenkov] IGNITE-12291 ticket was created and linekd > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12291) Create controllable paged query requests / responses for TextQuery similar to current SQL result processing
Yuriy Shuliha created IGNITE-12291: --- Summary: Create controllable paged query requests / responses for TextQuery similar to current SQL result processing Key: IGNITE-12291 URL: https://issues.apache.org/jira/browse/IGNITE-12291 Project: Ignite Issue Type: Improvement Reporter: Yuriy Shuliha Assignee: Yuriy Shuliha For now query initiator node sends 1 _GridCacheQueryRequest_ and can get multiple _GridCacheQueryResponse_-s per remote. TextQuery processing finishes when all remotes send _GridCacheQueryResponse_ with 'finished' flag. _TextQuery_ processing should be reworked like it was done for SQL queries. Ignite has _GridQueryNextPageRequest \ Response_ classes for SQL result processing. Similar processing should be implemented for _TextQueries_: *GridTextQueryNextPageRequest* *GridTextQueryNextPageResponse* Proper _TextQuery_ response processing should be implemented in _GridCacheQueryFutureAdapter._ This will allow us to add correct sorting and apply limit correctly on reduce. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948629#comment-16948629 ] Yuriy Shuliha commented on IGNITE-12189: - [~amashenkov] - I have made corrections according to your notes. Here's the tests run result (above). Can the PR be merged now ? > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946934#comment-16946934 ] Yuriy Shuliha commented on IGNITE-12189: - [~amashenkov] thank you for starting TC Bot. Can the results be interpreted as positive for current PR ? > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12266) Add limit parameter to Platforms for processing TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16945907#comment-16945907 ] Yuriy Shuliha commented on IGNITE-12266: - [~Pavlukhin] - yes, you are right, proper description should be added to the ticket. I planned to add it immediately after creation; but now i see that it will require more clarifications. There's place for TextQuery creation via binary readerin PlatformCache; https://github.com/apache/ignite/blob/dc58d91a866d59eb268a60f829a47ab5f259de38/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/cache/PlatformCache.java#L1425 But i cannot find proper point where corresponding TextQuery is being written into stream. [~amashenkov] - would you assist with this ? CC: [~avinogradov], [~agoncharuk] > Add limit parameter to Platforms for processing TextQuery > - > > Key: IGNITE-12266 > URL: https://issues.apache.org/jira/browse/IGNITE-12266 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12266) Add limit parameter to Platforms for processing TextQuery
Yuriy Shuliha created IGNITE-12266: --- Summary: Add limit parameter to Platforms for processing TextQuery Key: IGNITE-12266 URL: https://issues.apache.org/jira/browse/IGNITE-12266 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Yuriy Shuliha Assignee: Yuriy Shuliha Fix For: 2.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939338#comment-16939338 ] Yuriy Shuliha commented on IGNITE-12189: - [~yzhdanov] please review my pull-request in scope of ignite-core [~sergi] please review my pull-request in scope of ignite-indexing CC: [~dmagda] > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to queue > in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Long.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuriy Shuliha updated IGNITE-12189: Description: PROBLEM For now each server-node returns all response records to the client-node and it may contain ~thousands, ~hundred thousands records. Event if we need only first 10-100. Again, all the results are added to queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. There are no any means to deliver deterministic result. SOLUTION Implement _*limit*_ as parameter for _*TextQuery*_ and _*GridCacheQueryRequest*_ It should be passed as limit parameter in Lucene's _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. For distributed queries _*limit*_ will also trim response queue when merging results. Type: long Special value: : 0 -> No limit (Integer.MAX_VALUE); was: PROBLEM For now each server-node returns all response records to the client-node and it may contain ~thousands, ~hundred thousands records. Event if we need only first 10-100. Again, all the results are added to queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. There are no any means to deliver deterministic result. SOLUTION Implement _*limit*_ as parameter for _*TextQuery*_ and _*GridCacheQueryRequest*_ It should be passed as limit parameter in Lucene's _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. For distributed queries _*limit*_ will also trim response queue when merging results. Type: long Special value: : 0 -> No limit (Long.MAX_VALUE); > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuriy Shuliha updated IGNITE-12189: Fix Version/s: (was: 2.7.6) > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to queue > in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Long.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuriy Shuliha updated IGNITE-12189: Fix Version/s: 2.8 > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to queue > in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Long.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12190) Throw an exception for enabled text queries on persistent caches
[ https://issues.apache.org/jira/browse/IGNITE-12190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuriy Shuliha updated IGNITE-12190: Fix Version/s: (was: 2.7.6) 2.8 > Throw an exception for enabled text queries on persistent caches > > > Key: IGNITE-12190 > URL: https://issues.apache.org/jira/browse/IGNITE-12190 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12190) Throw an exception for enabled text queries on persistent caches
Yuriy Shuliha created IGNITE-12190: --- Summary: Throw an exception for enabled text queries on persistent caches Key: IGNITE-12190 URL: https://issues.apache.org/jira/browse/IGNITE-12190 Project: Ignite Issue Type: Improvement Components: general Reporter: Yuriy Shuliha Assignee: Yuriy Shuliha Fix For: 2.7.6 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12189) Implement correct limit for TextQuery
Yuriy Shuliha created IGNITE-12189: --- Summary: Implement correct limit for TextQuery Key: IGNITE-12189 URL: https://issues.apache.org/jira/browse/IGNITE-12189 Project: Ignite Issue Type: Improvement Components: general Reporter: Yuriy Shuliha Assignee: Yuriy Shuliha Fix For: 2.7.6 PROBLEM For now each server-node returns all response records to the client-node and it may contain ~thousands, ~hundred thousands records. Event if we need only first 10-100. Again, all the results are added to queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. There are no any means to deliver deterministic result. SOLUTION Implement _*limit*_ as parameter for _*TextQuery*_ and _*GridCacheQueryRequest*_ It should be passed as limit parameter in Lucene's _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. For distributed queries _*limit*_ will also trim response queue when merging results. Type: long Special value: : 0 -> No limit (Long.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
