[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So transforming
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, fetch=f + o)
>>Scan
{noformat}
Is not a valid transformation when there is an Exchange operator between a
Limit and a Sort and should not be used.
was:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So transforming
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, fetch=f + o)
>>Scan
{noformat}
Is not a valid transformation when there is an exchange operator between Limit
and parameterised Sort and should not be used.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that Sort's input always returns data from a single source.
> This assumption is not correct for the cases, when a query splits into
> multiple fragments.
> So transforming
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, fetch=f + o)
> >>Scan
> {noformat}
> Is not a valid transformation when there is an Exchange operator between a
> Limit and a Sort and should not be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So transforming
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, fetch=f + o)
>>Scan
{noformat}
Is not a valid transformation when there is an exchange operator between Limit
and parameterised Sort and should not be used.
was:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So transforming
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, fetch=f + o)
>>Scan
{noformat}
Is not a valid transformation if there is an exchange operator between Limit
and parameterised Sort and should not be used.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that Sort's input always returns data from a single source.
> This assumption is not correct for the cases, when a query splits into
> multiple fragments.
> So transforming
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, fetch=f + o)
> >>Scan
> {noformat}
> Is not a valid transformation when there is an exchange operator between
> Limit and parameterised Sort and should not be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So transforming
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, fetch=f + o)
>>Scan
{noformat}
Is not a valid transformation if there is an exchange operator between Limit
and parameterised Sort and should not be used.
was:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So transforming
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, fetch=f + o)
>>Scan
{noformat}
Is not a valid transformation and should not be used.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that Sort's input always returns data from a single source.
> This assumption is not correct for the cases, when a query splits into
> multiple fragments.
> So transforming
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, fetch=f + o)
> >>Scan
> {noformat}
> Is not a valid transformation if there is an exchange operator between Limit
> and parameterised Sort and should not be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So transforming
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, fetch=f + o)
>>Scan
{noformat}
Is not a valid transformation and should not be used.
was:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So transforming
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, fetch=f + o)
>>Scan
{noformat}
Is not a valid transformation and should not be used.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that Sort's input always returns data from a single source.
> This assumption is not correct for the cases, when a query splits into
> multiple fragments.
> So transforming
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, fetch=f + o)
> >>Scan
> {noformat}
> Is not a valid transformation and should not be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22400) Fix unstable IgniteClusterSnapshotStreamerTest
[ https://issues.apache.org/jira/browse/IGNITE-22400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22400: -- Fix Version/s: 2.17 > Fix unstable IgniteClusterSnapshotStreamerTest > --- > > Key: IGNITE-22400 > URL: https://issues.apache.org/jira/browse/IGNITE-22400 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > Fix For: 2.17 > > > Some of IgniteClusterSnapshotStreamerTest's test fails sometimes. We do not > flush streamer's data before the tests and do not wait untils streamer stops. > This is the issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22401) Code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-22401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22401: -- Fix Version/s: 2.17 > Code cleanup > > > Key: IGNITE-22401 > URL: https://issues.apache.org/jira/browse/IGNITE-22401 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.17 > > > Fixes of the code style, abbeviations, unused code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22401) Code cleanup
[
https://issues.apache.org/jira/browse/IGNITE-22401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851743#comment-17851743
]
Ignite TC Bot commented on IGNITE-22401:
{panel:title=Branch: [pull/11366/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11366/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7893764buildTypeId=IgniteTests24Java8_RunAll]
> Code cleanup
>
>
> Key: IGNITE-22401
> URL: https://issues.apache.org/jira/browse/IGNITE-22401
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> Fixes of the code style, abbeviations, unused code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22401) Code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-22401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22401: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Code cleanup > > > Key: IGNITE-22401 > URL: https://issues.apache.org/jira/browse/IGNITE-22401 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > > Fixes of the code style, abbeviations, unused code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22400) Fix unstable IgniteClusterSnapshotStreamerTest
[ https://issues.apache.org/jira/browse/IGNITE-22400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22400: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Fix unstable IgniteClusterSnapshotStreamerTest > --- > > Key: IGNITE-22400 > URL: https://issues.apache.org/jira/browse/IGNITE-22400 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > > Some of IgniteClusterSnapshotStreamerTest's test fails sometimes. We do not > flush streamer's data before the tests and do not wait untils streamer stops. > This is the issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22401) Code cleanup
Vladimir Steshin created IGNITE-22401: - Summary: Code cleanup Key: IGNITE-22401 URL: https://issues.apache.org/jira/browse/IGNITE-22401 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Assignee: Vladimir Steshin Fixes of the code style, abbeviations, unused code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22400) Fix unstable IgniteClusterSnapshotStreamerTest
[ https://issues.apache.org/jira/browse/IGNITE-22400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22400: -- Labels: ise (was: ) > Fix unstable IgniteClusterSnapshotStreamerTest > --- > > Key: IGNITE-22400 > URL: https://issues.apache.org/jira/browse/IGNITE-22400 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > > Some of IgniteClusterSnapshotStreamerTest's test fails sometimes. We do not > flush streamer's data before the tests and do not wait untils streamer stops. > This is the issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22400) Fix unstable IgniteClusterSnapshotStreamerTest
[
https://issues.apache.org/jira/browse/IGNITE-22400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851739#comment-17851739
]
Ignite TC Bot commented on IGNITE-22400:
{panel:title=Branch: [pull/11369/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11369/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7898025buildTypeId=IgniteTests24Java8_RunAll]
> Fix unstable IgniteClusterSnapshotStreamerTest
> ---
>
> Key: IGNITE-22400
> URL: https://issues.apache.org/jira/browse/IGNITE-22400
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: ise
>
> Some of IgniteClusterSnapshotStreamerTest's test fails sometimes. We do not
> flush streamer's data before the tests and do not wait untils streamer stops.
> This is the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22400) Fix unstable IgniteClusterSnapshotStreamerTest
Vladimir Steshin created IGNITE-22400: - Summary: Fix unstable IgniteClusterSnapshotStreamerTest Key: IGNITE-22400 URL: https://issues.apache.org/jira/browse/IGNITE-22400 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Assignee: Vladimir Steshin Some of IgniteClusterSnapshotStreamerTest's test fails sometimes. We do not flush streamer's data before the tests and do not wait untils streamer stops. This is the issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22392) Sql. Set operation. Incorrect query transformation for a query with limit / offset that uses the same table (When RemoveSortInSubQuery is enabled)
[
https://issues.apache.org/jira/browse/IGNITE-22392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22392:
--
Description:
Combination of LIMIT / OFFSET and set operator results in incorrect
transformation of a plan tree. This issue is caused by incorrect handling of
the `RemoveSortInSubQuery` flag inside SqlToRelConverter. ATM this issue is
migrated by disabling that flag.
{noformat}
statement ok
CREATE TABLE test (a INTEGER);
statement ok
INSERT INTO test VALUES (1), (2), (3), (4);
# query 1
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
2
# query 2
query I rowsort
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
4
# combined query should return 2, 4
# but it returns 2
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
UNION ALL
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
2
4
{noformat}
Query 1
{noformat}
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
Limit(offset=[1], fetch=[1]), id = 80
Exchange(distribution=[single]), id = 79
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 78
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 50
{noformat}
Query 2
{noformat}
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
Limit(offset=[1]), id = 201
Limit(offset=[2], fetch=[3]), id = 200
Exchange(distribution=[single]), id = 199
Sort(sort0=[$0], dir0=[ASC], offset=[2], fetch=[3]), id = 198
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 168
{noformat}
Combine queries using UNION ALL
{noformat}
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
UNION ALL
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
UnionAll(all=[true]), id = 403
Limit(offset=[1], fetch=[1]), id = 400
Exchange(distribution=[single]), id = 399 # subtree is duplicated in
another part of a query
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398 #
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
Limit(offset=[1]), id = 402
Limit(offset=[2], fetch=[3]), id = 401
Exchange(distribution=[single]), id = 399 # duplicate
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
{noformat}
When tables are different, results are correct.
Reproducible in vanila calcite:
{noformat}
EnumerableUnion(all=[true])
> EnumerableCalc(expr#0..1=[{inputs}], A=[$t0])
> EnumerableLimit(offset=[1], fetch=[1])
> EnumerableSort(sort0=[$0], dir0=[ASC])
> EnumerableTableScan(table=[[BLANK, TEST]])
> EnumerableCalc(expr#0..1=[{inputs}], A=[$t0])
> EnumerableLimit(offset=[2], fetch=[3])
> EnumerableSort(sort0=[$0], dir0=[ASC])
> EnumerableTableScan(table=[[BLANK, TEST]])
{noformat}
was:
Combination of LIMIT / OFFSET and set operator results in incorrect
transformation of a plan tree. This issue is caused by incorrect by incorrect
handling of the `RemoveSortInSubQuery` flag inside SqlToRelConverter internals.
ATM this issue is migrated by disabling that flag.
{noformat}
statement ok
CREATE TABLE test (a INTEGER);
statement ok
INSERT INTO test VALUES (1), (2), (3), (4);
# query 1
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
2
# query 2
query I rowsort
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
4
# combined query should return 2, 4
# but it returns 2
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
UNION ALL
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
2
4
{noformat}
Query 1
{noformat}
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
Limit(offset=[1], fetch=[1]), id = 80
Exchange(distribution=[single]), id = 79
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 78
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 50
{noformat}
Query 2
{noformat}
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
Limit(offset=[1]), id = 201
Limit(offset=[2], fetch=[3]), id = 200
Exchange(distribution=[single]), id = 199
Sort(sort0=[$0], dir0=[ASC], offset=[2], fetch=[3]), id = 198
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 168
{noformat}
[jira] [Comment Edited] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851564#comment-17851564
]
Maksim Zhuravkov edited comment on IGNITE-22204 at 6/3/24 4:29 PM:
---
The previous issue was moved to
https://issues.apache.org/jira/browse/IGNITE-22392.
was (Author: JIRAUSER298618):
The previous issue is moved to
https://issues.apache.org/jira/browse/IGNITE-22392.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that Sort's input always returns data from a single source.
> This assumption is not correct for the cases, when a query splits into
> multiple fragments.
> So transforming
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, fetch=f + o)
> >>Scan
> {noformat}
> Is not a valid transformation and should not be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So transforming
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, fetch=f + o)
>>Scan
{noformat}
Is not a valid transformation and should not be used.
was:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So transforming
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not a valid transformation and should not be used.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that Sort's input always returns data from a single source.
> This assumption is not correct for the cases, when a query splits into
> multiple fragments.
> So transforming
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, fetch=f + o)
> >>Scan
> {noformat}
> Is not a valid transformation and should not be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So transforming
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not a valid transformation and should not be used.
was:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that Sort's input always returns data from a single source.
> This assumption is not correct for the cases, when a query splits into
> multiple fragments.
> So transforming
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Is not a valid transformation and should not be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for the cases, when a query splits into multiple
fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
was:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for most cases, when query splits into multiple
fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that Sort's input always returns data from a single source.
> This assumption is not correct for the cases, when a query splits into
> multiple fragments.
> So
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Is not applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
That assumption is not correct for most cases, when query splits into multiple
fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
was:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source
Which is not correct, because fetch parameter is applied incorrectly when query
splits into multiple fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that Sort's input always returns data from a single source.
> That assumption is not correct for most cases, when query splits into
> multiple fragments.
> So
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Is not applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
This assumption is not correct for most cases, when query splits into multiple
fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
was:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source.
That assumption is not correct for most cases, when query splits into multiple
fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that Sort's input always returns data from a single source.
> This assumption is not correct for most cases, when query splits into
> multiple fragments.
> So
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Is not applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that its inputs always returns data from a single source
Which is not correct, because fetch parameter is applied incorrectly when query
splits into multiple fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
was:
Patch IGNITE-16013 for AI-2 cannot be applied for AI-3, because that patch
assumes that its inputs always returns data from a single source
Which is not correct, because fetch parameter is applied incorrectly when query
splits into multiple fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that its inputs always returns data from a single source
> Which is not correct, because fetch parameter is applied incorrectly when
> query splits into multiple fragments.
> So
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Is not applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that Sort's input always returns data from a single source
Which is not correct, because fetch parameter is applied incorrectly when query
splits into multiple fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
was:
Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
assumes that its inputs always returns data from a single source
Which is not correct, because fetch parameter is applied incorrectly when query
splits into multiple fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied to AI-3, because that patch
> assumes that Sort's input always returns data from a single source
> Which is not correct, because fetch parameter is applied incorrectly when
> query splits into multiple fragments.
> So
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Is not applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Summary: Sql. Sort operator cannot use offset parameter (was: Sql. Sort
operator can not use offset parameter)
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 can not be applied for AI-3, because that patch
> assumes that its inputs always returns data from a single source
> Which is not correct, because fetch parameter is applied incorrectly when
> query splits into multiple fragments.
> So
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Is not applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator cannot use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 cannot be applied for AI-3, because that patch
assumes that its inputs always returns data from a single source
Which is not correct, because fetch parameter is applied incorrectly when query
splits into multiple fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
was:
Patch IGNITE-16013 for AI-2 can not be applied for AI-3, because that patch
assumes that its inputs always returns data from a single source
Which is not correct, because fetch parameter is applied incorrectly when query
splits into multiple fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
> Sql. Sort operator cannot use offset parameter
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 cannot be applied for AI-3, because that patch
> assumes that its inputs always returns data from a single source
> Which is not correct, because fetch parameter is applied incorrectly when
> query splits into multiple fragments.
> So
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Is not applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22399) Improve handling of small network messages on send
Roman Puchkovskiy created IGNITE-22399: -- Summary: Improve handling of small network messages on send Key: IGNITE-22399 URL: https://issues.apache.org/jira/browse/IGNITE-22399 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator can not use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 can not be applied for AI-3, because that patch
assumes that its inputs always returns data from a single source
Which is not correct, because fetch parameter is applied incorrectly when query
splits into multiple fragments.
So
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Is not applicable.
was:
Patch IGNITE-16013 for AI-2 can not be applied for AI-3, because that patch
either (a) assumes that its inputs always returns
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Which is not correct, because fetch parameter is applied incorrectly when query
splits into multiple fragments.
> Sql. Sort operator can not use offset parameter
> ---
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 can not be applied for AI-3, because that patch
> assumes that its inputs always returns data from a single source
> Which is not correct, because fetch parameter is applied incorrectly when
> query splits into multiple fragments.
> So
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Is not applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator can not use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 can not be applied for AI-3, because that patch
either (a) assumes that its inputs always returns
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Which is not correct, because fetch parameter is applied incorrectly when query
splits into multiple fragments.
was:
Patch IGNITE-16013 for AI-2 can not be applied for AI-3, because that patch
either (a) assumes that its inputs always returns
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Which is not correct, because fetch and offset are applied twice.
> Sql. Sort operator can not use offset parameter
> ---
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 can not be applied for AI-3, because that patch
> either (a) assumes that its inputs always returns
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Which is not correct, because fetch parameter is applied incorrectly when
> query splits into multiple fragments.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Sort operator can not use offset parameter
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Summary: Sql. Sort operator can not use offset parameter (was: Sql.
Incorrect Limit / Sort transformation)
> Sql. Sort operator can not use offset parameter
> ---
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 can not be applied for AI-3, because that patch
> either (a) assumes that its inputs always returns
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Which is not correct, because fetch and offset are applied twice.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22398) Rework network threads' lags detection using the critical workers watchdog
Denis Chudov created IGNITE-22398: - Summary: Rework network threads' lags detection using the critical workers watchdog Key: IGNITE-22398 URL: https://issues.apache.org/jira/browse/IGNITE-22398 Project: Ignite Issue Type: Improvement Reporter: Denis Chudov *Motivation* CriticalWorkerWatchdog should become the common approach to detect the critical threads' lags. *Definition of done* * Network threads' lags and slow processing of messages should be reworked using CriticalWorkerWatchdog; * TrackableNetworkMessageHandler should be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22397) Improve the CriticalWorkerWatchdog to make it able to measure different delays for different threads
Denis Chudov created IGNITE-22397: - Summary: Improve the CriticalWorkerWatchdog to make it able to measure different delays for different threads Key: IGNITE-22397 URL: https://issues.apache.org/jira/browse/IGNITE-22397 Project: Ignite Issue Type: Improvement Reporter: Denis Chudov Motivation For now, the critical worker is some thread that cannot be blocked for more than X ms, and the value X is the same for every worker and configured with CriticalWorkersConfiguration#maxAllowedLag. We have different mechanisms for other threads like network ones (see TrackableNetworkMessageHandler). Using the CriticalWorkerWatchdog we can introduce the common approach for every case. Definition of done - we are able to configure maxAllowedLag per thread (per pool); - we are able to detect small lags of critical threads (such as 5 ms which is used in TrackableNetworkMessageHandler) using CriticalWorkerWatchdog. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22397) Improve the CriticalWorkerWatchdog to make it able to measure different delays for different threads
[ https://issues.apache.org/jira/browse/IGNITE-22397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-22397: -- Description: *Motivation* For now, the critical worker is some thread that cannot be blocked for more than X ms, and the value X is the same for every worker and configured with CriticalWorkersConfiguration#maxAllowedLag. We have different mechanisms for other threads like network ones (see TrackableNetworkMessageHandler). Using the CriticalWorkerWatchdog we can introduce the common approach for every case. *Definition of done* - we are able to configure maxAllowedLag per thread (per pool); - we are able to detect small lags of critical threads (such as 5 ms which is used in TrackableNetworkMessageHandler) using CriticalWorkerWatchdog. was: Motivation For now, the critical worker is some thread that cannot be blocked for more than X ms, and the value X is the same for every worker and configured with CriticalWorkersConfiguration#maxAllowedLag. We have different mechanisms for other threads like network ones (see TrackableNetworkMessageHandler). Using the CriticalWorkerWatchdog we can introduce the common approach for every case. Definition of done - we are able to configure maxAllowedLag per thread (per pool); - we are able to detect small lags of critical threads (such as 5 ms which is used in TrackableNetworkMessageHandler) using CriticalWorkerWatchdog. > Improve the CriticalWorkerWatchdog to make it able to measure different > delays for different threads > > > Key: IGNITE-22397 > URL: https://issues.apache.org/jira/browse/IGNITE-22397 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > For now, the critical worker is some thread that cannot be blocked for more > than X ms, and the value X is the same for every worker and configured with > CriticalWorkersConfiguration#maxAllowedLag. We have different mechanisms for > other threads like network ones (see > TrackableNetworkMessageHandler). Using the CriticalWorkerWatchdog we can > introduce the common approach for every case. > > *Definition of done* > - we are able to configure maxAllowedLag per thread (per pool); > - we are able to detect small lags of critical threads (such as 5 ms which > is used in TrackableNetworkMessageHandler) using CriticalWorkerWatchdog. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22310) Handling of TxCleanupMessage takes too much time on the network thread
[
https://issues.apache.org/jira/browse/IGNITE-22310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-22310:
--
Description:
When running tests on my local machine, I've encountered a lot of messages like
"Message handling has been too long" for messages of type
{{{}TxCleanupMessage{}}}. Looks like the sync part of the
{{TxCleanupRequestHandler}} should either be optimized or dispatched onto a
different thread.
The reason is that we have the following flow: tx finish (on commit partition)
-> tx cleanup (on every node containing enlisted partitions) -> tx write intent
switch (on every enlisted partition). In the case of commit partition all of
this is executed on the same node, so the network engine does "send to self"
without changing the thread. In other words, on commit partition the flow is
following: tx finish (partition operations thread) -> tx cleanup (same thread)
-> tx write intent switch (same thread).
There is a network message handler measuring the time and writing the mentioned
message to log. In the case of tx cleanup on commit partition it actually
measures the tx write intent switch, which is not very fast and happens
synchronously because we started tx cleanup already being within a partition
operations thread. Seems that this time measuring handler should be aware of
the thread permissions and not write any warnings when the current thread has
(storage_read, storage_write) permissions.
was:When running tests on my local machine, I've encountered a lot of
messages like "Message handling has been too long" for messages of type
{{TxCleanupMessage}}. Looks like the sync part of the
{{TxCleanupRequestHandler}} should either be optimized or dispatched onto a
different thread.
> Handling of TxCleanupMessage takes too much time on the network thread
> ---
>
> Key: IGNITE-22310
> URL: https://issues.apache.org/jira/browse/IGNITE-22310
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
>
> When running tests on my local machine, I've encountered a lot of messages
> like "Message handling has been too long" for messages of type
> {{{}TxCleanupMessage{}}}. Looks like the sync part of the
> {{TxCleanupRequestHandler}} should either be optimized or dispatched onto a
> different thread.
> The reason is that we have the following flow: tx finish (on commit
> partition) -> tx cleanup (on every node containing enlisted partitions) -> tx
> write intent switch (on every enlisted partition). In the case of commit
> partition all of this is executed on the same node, so the network engine
> does "send to self" without changing the thread. In other words, on commit
> partition the flow is following: tx finish (partition operations thread) ->
> tx cleanup (same thread) -> tx write intent switch (same thread).
> There is a network message handler measuring the time and writing the
> mentioned message to log. In the case of tx cleanup on commit partition it
> actually measures the tx write intent switch, which is not very fast and
> happens synchronously because we started tx cleanup already being within a
> partition operations thread. Seems that this time measuring handler should be
> aware of the thread permissions and not write any warnings when the current
> thread has (storage_read, storage_write) permissions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22396) Update xstream
[ https://issues.apache.org/jira/browse/IGNITE-22396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-22396: Fix Version/s: 2.17 > Update xstream > -- > > Key: IGNITE-22396 > URL: https://issues.apache.org/jira/browse/IGNITE-22396 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Minor > Labels: ise > Fix For: 2.17 > > > Update xstream to 1.4.20 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22396) Update xstream
Aleksandr Nikolaev created IGNITE-22396: --- Summary: Update xstream Key: IGNITE-22396 URL: https://issues.apache.org/jira/browse/IGNITE-22396 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Nikolaev Assignee: Aleksandr Nikolaev Update xstream to 1.4.20 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22396) Update xstream
[ https://issues.apache.org/jira/browse/IGNITE-22396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-22396: Labels: ise (was: ) > Update xstream > -- > > Key: IGNITE-22396 > URL: https://issues.apache.org/jira/browse/IGNITE-22396 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Minor > Labels: ise > > Update xstream to 1.4.20 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22301) Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-22301:
--
Fix Version/s: 3.0.0-beta2
> Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
>
>
> Key: IGNITE-22301
> URL: https://issues.apache.org/jira/browse/IGNITE-22301
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> From time to time the CatalogManagerSelfTest.alwaysWaitForActivationTime test
> fails with the following error ([test
> history|https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-3345017748753084393=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50]).
> {noformat}
> org.mockito.exceptions.verification.TooManyActualInvocations:
> testCommand.get();
> Wanted 2 times:
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerSelfTest$TestCommand.get(CatalogManagerSelfTest.java:472)
> But was 3 times:
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> {noformat}
> This failure reproduces locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22301) Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851637#comment-17851637
]
Iurii Gerzhedovich commented on IGNITE-22301:
-
[~korlov] LGTM
> Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
>
>
> Key: IGNITE-22301
> URL: https://issues.apache.org/jira/browse/IGNITE-22301
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> From time to time the CatalogManagerSelfTest.alwaysWaitForActivationTime test
> fails with the following error ([test
> history|https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-3345017748753084393=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50]).
> {noformat}
> org.mockito.exceptions.verification.TooManyActualInvocations:
> testCommand.get();
> Wanted 2 times:
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerSelfTest$TestCommand.get(CatalogManagerSelfTest.java:472)
> But was 3 times:
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> {noformat}
> This failure reproduces locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Incorrect Limit / Sort transformation
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
Patch IGNITE-16013 for AI-2 can not be applied for AI-3, because that patch
either (a) assumes that its inputs always returns
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Which is not correct, because fetch and offset are applied twice.
was:
IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation. It
transforms:
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Which is not correct, because fetch and offset are applied twice.
> Sql. Incorrect Limit / Sort transformation
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Patch IGNITE-16013 for AI-2 can not be applied for AI-3, because that patch
> either (a) assumes that its inputs always returns
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Which is not correct, because fetch and offset are applied twice.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22395) Remove assertions for paranoid leak detection property
Philipp Shergalis created IGNITE-22395: -- Summary: Remove assertions for paranoid leak detection property Key: IGNITE-22395 URL: https://issues.apache.org/jira/browse/IGNITE-22395 Project: Ignite Issue Type: Improvement Reporter: Philipp Shergalis Assignee: Philipp Shergalis -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22302) Thin 3.0: Data Streamer with Receiver - add resultSubscriber support
[ https://issues.apache.org/jira/browse/IGNITE-22302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-22302: - Epic Link: IGNITE-19537 > Thin 3.0: Data Streamer with Receiver - add resultSubscriber support > > > Key: IGNITE-22302 > URL: https://issues.apache.org/jira/browse/IGNITE-22302 > Project: Ignite > Issue Type: Improvement > Components: streaming, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > See TODOs with this ticket number. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22349) Ignite.NET support for priority ordering of Compute jobs
[
https://issues.apache.org/jira/browse/IGNITE-22349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851606#comment-17851606
]
Pavel Tupitsyn commented on IGNITE-22349:
-
[~kukushal] I would like to do a review, do you prefer to create a PR for that,
or use JIRA comments?
> Ignite.NET support for priority ordering of Compute jobs
>
>
> Key: IGNITE-22349
> URL: https://issues.apache.org/jira/browse/IGNITE-22349
> Project: Ignite
> Issue Type: Improvement
> Components: .NET, compute, platforms
>Affects Versions: 2.16
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Labels: .net, compute, ise, platforms
> Attachments: IGNITE-22349-README.md, ignite-22349.patch
>
>
> I want Apache Ignite to support [priority
> ordering|https://ignite.apache.org/docs/latest/distributed-computing/job-scheduling#priority-ordering]
> of Ignite.NET compute jobs on the same node.
> h4. Analysis
> {{PriorityQueueCollisionSpi}} does priority ordering. The problem is the
> {{PriorityQueueCollisionSpi}} expects the user to provide job priorities
> via the {{ComputeTaskSession}}'s "{{grid.task.priority}}" attribute and the
> {{ComputeTaskSession}} is not available in Ignite.NET.
> It looks like the requirement is to add an injectable {{ComputeTaskSession}}
> in Ignite.NET exposing the {{SetAttributes}} operation similar to how it
> works in Java.
> h4. Reproducer
> I expect more or less ordered output from the below reproducer. The output
> may not be completely ordered since completely ordered output requires all
> the jobs to land on the server node in single batch and this reproducer
> cannot guarantee that:
> {noformat}
> >>> Completed job with priority 0
> >>> Completed job with priority 9
> >>> Completed job with priority 8
> >>> Completed job with priority 7
> >>> Completed job with priority 6
> >>> Completed job with priority 5
> >>> Completed job with priority 4
> >>> Completed job with priority 3
> >>> Completed job with priority 2
> >>> Completed job with priority 1
> {noformat}
> {{PriorityQueueCollisionSpiTest.cs}}:
> {code:java}
> public class PriorityQueueCollisionSpiTest
> {
> private static ITestOutputHelper? _output;
> public PriorityQueueCollisionSpiTest(ITestOutputHelper output)
> {
> _output = output;
> }
> ///
> /// Schedules jobs according to cref="IComputeTask{TArg,TJobRes,TRes}"/>'s priority.
> ///
> [Fact]
> public void SchedulesJobsAccordingToTaskPriority()
> {
> // Given an Ignite cluster consisting of server and client nodes
> using var ignored = Ignition.Start(GetIgniteConfiguration("server1"));
> var igniteConfiguration = GetIgniteConfiguration("app1");
> igniteConfiguration.ClientMode = true;
> using var ignite = Ignition.Start(igniteConfiguration);
> var igniteCompute = ignite.GetCompute();
>
> // And the user asynchronously executes multiple tasks, each task
> starting a job having increasing priority
> const int jobCount = 10;
> ICollection futureResultCollection = new List(jobCount);
> for (var priority = 0; priority < jobCount; priority++)
> {
> var task = new PriorityTask(priority);
> var futureResult = igniteCompute.ExecuteAsync(task, jobCount);
> futureResultCollection.Add(futureResult);
> }
> // When all the jobs complete
> Task.WaitAll(futureResultCollection.ToArray());
>
> // Then the ">>> Completed job with priority" console output
> demonstrates that the jobs completed in the
> // decreasing priority order, more or less.
> }
> private static IgniteConfiguration GetIgniteConfiguration(string
> igniteName) =>
> new()
> {
> ConsistentId = igniteName,
> IgniteInstanceName = igniteName,
> SpringConfigUrl = "ignite-sandbox.xml",
> DiscoverySpi = new TcpDiscoverySpi
> {
> IpFinder = new TcpDiscoveryStaticIpFinder {Endpoints = new
> List {"127.0.0.1:48700"}},
> LocalPort = 48700
> },
> FailureDetectionTimeout = TimeSpan.FromMinutes(10),
> ClientFailureDetectionTimeout = TimeSpan.FromMinutes(10),
> JvmOptions = new List
> {"-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005"}
> };
> ///
> /// implementation that
> single s with
> /// the specified priority.
> ///
> [ComputeTaskSessionFullSupport]
> private sealed class PriorityTask : ComputeTaskSplitAdapter bool>
> {
> private readonly int _priority;
> [TaskSessionResource] private
[jira] [Created] (IGNITE-22394) Bad CLI error message when connecting to port 10800
Igor Gusev created IGNITE-22394: --- Summary: Bad CLI error message when connecting to port 10800 Key: IGNITE-22394 URL: https://issues.apache.org/jira/browse/IGNITE-22394 Project: Ignite Issue Type: Task Reporter: Igor Gusev When attempting to connect to port 10800, you get an uninformative error message: ``` unexpected end of stream on http://localhost:10800/... ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20451) Introduce WorkerRegistery
[ https://issues.apache.org/jira/browse/IGNITE-20451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-20451. -- Resolution: Duplicate > Introduce WorkerRegistery > - > > Key: IGNITE-20451 > URL: https://issues.apache.org/jira/browse/IGNITE-20451 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > Each Ignite node has a number of system-critical threads. We should implement > a periodic check that calls the failure handler when one of the following > conditions has been detected: > - Critical thread is not alive anymore. > - Critical thread 'hangs' for a long time, e.g. while executing a task > extracted from the task queue. > In case of failure condition, call stacks of all threads should be logged > before invoking failure handler. > Implementations based on separate diagnostic thread seem fragile, cause this > thread become a vulnerable point with respect to thread termination and CPU > resource starvation. So we are to use self-monitoring approach: critical > threads themselves should monitor each other. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20450) Failure handler configuration
[
https://issues.apache.org/jira/browse/IGNITE-20450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20450:
-
Description:
*Motivation:*
The user should be able to configure the following properties related to
failure handling:
- First of all, the user should be able to choose a concrete strategy for
failure handling from the provided out-of-the-box:
{_}StopNodeFailureHandler{_}, {_}StopNodeOrHaltFailureHandler,
NoOpFailureHandler{_}. The default value is {_}NoOpFailureHandler{_}.
- A list of ignored failure types. The default value is:
{_}SYSTEM_WORKER_BLOCKED{_}, _SYSTEM_CRITICAL_OPERATION_TIMEOUT_
was:
*Motivation:*
The user should be able to configure the following properties related to
failure handling:
- first of all, the user should be able to choose a concrete strategy of
failure handling from the provided out-of-the-box: _StopNodeFailureHandler_,
_StopNodeOrHaltFailureHandler_. The default value is _StopNodeFailureHandler_.
- Enabling thread dump on failure. The default value is _true_.
- Timeout for throttling of thread dumps generation. The default value is
10sec.
- System worker blocked timeout. The default value is 10sec.
- Size of buffer that is used to handle OOM. The default value is 64Kb.
- Perhaps, it can be useful to configure a list of ignored failure types. The
default value is: _SYSTEM_WORKER_BLOCKED_, _SYSTEM_CRITICAL_OPERATION_TIMEOUT_
> Failure handler configuration
> -
>
> Key: IGNITE-20450
> URL: https://issues.apache.org/jira/browse/IGNITE-20450
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> *Motivation:*
> The user should be able to configure the following properties related to
> failure handling:
> - First of all, the user should be able to choose a concrete strategy for
> failure handling from the provided out-of-the-box:
> {_}StopNodeFailureHandler{_}, {_}StopNodeOrHaltFailureHandler,
> NoOpFailureHandler{_}. The default value is {_}NoOpFailureHandler{_}.
> - A list of ignored failure types. The default value is:
> {_}SYSTEM_WORKER_BLOCKED{_}, _SYSTEM_CRITICAL_OPERATION_TIMEOUT_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22393) FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field
[
https://issues.apache.org/jira/browse/IGNITE-22393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-22393:
--
Fix Version/s: 3.0.0-beta2
> FieldAccessor does not set the correct BinaryMode when a TypeConverter is
> used to Map a POJO field
> --
>
> Key: IGNITE-22393
> URL: https://issues.apache.org/jira/browse/IGNITE-22393
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> I'm using the Mapper API with a TypeConverter to convert a POJO field into
> and Instant/Timestamp column.
> However, the FieldAccessor code is very strict. It tries to find the binary
> mode directly from the original field type (in the POJO) instead of the
> target type of my TypeConverter.
> [Here is the
> culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]
> Stacktrace:
> {code:java}
> Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59 java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:610)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValue(ClientKeyValueView.java:590)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.lambda$putAsync$9(ClientKeyValueView.java:235)
> at
> app//org.apache.ignite.internal.client.table.ClientTable.lambda$doSchemaOutInOpAsync$5(ClientTable.java:460)
> at
> app//org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:332)
> ... 30 more
> Caused by: org.apache.ignite.internal.marshaller.MarshallerException:
> IGN-CMN-65535 TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59
> java.lang.ClassCastException: class java.time.LocalDate cannot be cast to
> class [B (java.time.LocalDate and [B are in module java.base of loader
> 'bootstrap')
> at
> app//org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:401)
> at
> app//org.apache.ignite.internal.marshaller.Marshaller$PojoMarshaller.writeField(Marshaller.java:300)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:606)
> ... 34 more
> Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:809)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:399)
> ... 36 more
> Caused by: java.lang.ClassCastException: class java.time.LocalDate cannot be
> cast to class [B (java.time.LocalDate and [B are in module java.base of
> loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.writeRefObject(FieldAccessor.java:381)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:807)
> ... 37 more {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22393) FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field
[
https://issues.apache.org/jira/browse/IGNITE-22393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-22393:
--
Priority: Blocker (was: Major)
> FieldAccessor does not set the correct BinaryMode when a TypeConverter is
> used to Map a POJO field
> --
>
> Key: IGNITE-22393
> URL: https://issues.apache.org/jira/browse/IGNITE-22393
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> I'm using the Mapper API with a TypeConverter to convert a POJO field into
> and Instant/Timestamp column.
> However, the FieldAccessor code is very strict. It tries to find the binary
> mode directly from the original field type (in the POJO) instead of the
> target type of my TypeConverter.
> [Here is the
> culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]
> Stacktrace:
> {code:java}
> Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59 java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:610)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValue(ClientKeyValueView.java:590)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.lambda$putAsync$9(ClientKeyValueView.java:235)
> at
> app//org.apache.ignite.internal.client.table.ClientTable.lambda$doSchemaOutInOpAsync$5(ClientTable.java:460)
> at
> app//org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:332)
> ... 30 more
> Caused by: org.apache.ignite.internal.marshaller.MarshallerException:
> IGN-CMN-65535 TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59
> java.lang.ClassCastException: class java.time.LocalDate cannot be cast to
> class [B (java.time.LocalDate and [B are in module java.base of loader
> 'bootstrap')
> at
> app//org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:401)
> at
> app//org.apache.ignite.internal.marshaller.Marshaller$PojoMarshaller.writeField(Marshaller.java:300)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:606)
> ... 34 more
> Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:809)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:399)
> ... 36 more
> Caused by: java.lang.ClassCastException: class java.time.LocalDate cannot be
> cast to class [B (java.time.LocalDate and [B are in module java.base of
> loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.writeRefObject(FieldAccessor.java:381)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:807)
> ... 37 more {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22393) FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field
[
https://issues.apache.org/jira/browse/IGNITE-22393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851576#comment-17851576
]
Tiago Marques Godinho commented on IGNITE-22393:
Left a test to reproduce the issue.
> FieldAccessor does not set the correct BinaryMode when a TypeConverter is
> used to Map a POJO field
> --
>
> Key: IGNITE-22393
> URL: https://issues.apache.org/jira/browse/IGNITE-22393
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Priority: Major
> Labels: ignite-3
>
> I'm using the Mapper API with a TypeConverter to convert a POJO field into
> and Instant/Timestamp column.
> However, the FieldAccessor code is very strict. It tries to find the binary
> mode directly from the original field type (in the POJO) instead of the
> target type of my TypeConverter.
> [Here is the
> culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]
> Stacktrace:
> {code:java}
> Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59 java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:610)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValue(ClientKeyValueView.java:590)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.lambda$putAsync$9(ClientKeyValueView.java:235)
> at
> app//org.apache.ignite.internal.client.table.ClientTable.lambda$doSchemaOutInOpAsync$5(ClientTable.java:460)
> at
> app//org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:332)
> ... 30 more
> Caused by: org.apache.ignite.internal.marshaller.MarshallerException:
> IGN-CMN-65535 TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59
> java.lang.ClassCastException: class java.time.LocalDate cannot be cast to
> class [B (java.time.LocalDate and [B are in module java.base of loader
> 'bootstrap')
> at
> app//org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:401)
> at
> app//org.apache.ignite.internal.marshaller.Marshaller$PojoMarshaller.writeField(Marshaller.java:300)
> at
> app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:606)
> ... 34 more
> Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:809)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:399)
> ... 36 more
> Caused by: java.lang.ClassCastException: class java.time.LocalDate cannot be
> cast to class [B (java.time.LocalDate and [B are in module java.base of
> loader 'bootstrap')
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.writeRefObject(FieldAccessor.java:381)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:807)
> ... 37 more {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22393) FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field
[
https://issues.apache.org/jira/browse/IGNITE-22393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tiago Marques Godinho updated IGNITE-22393:
---
Description:
I'm using the Mapper API with a TypeConverter to convert a POJO field into and
Instant/Timestamp column.
However, the FieldAccessor code is very strict. It tries to find the binary
mode directly from the original field type (in the POJO) instead of the target
type of my TypeConverter.
[Here is the
culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]
Stacktrace:
{code:java}
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59 java.lang.ClassCastException:
class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
[B are in module java.base of loader 'bootstrap')
at
app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:610)
at
app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValue(ClientKeyValueView.java:590)
at
app//org.apache.ignite.internal.client.table.ClientKeyValueView.lambda$putAsync$9(ClientKeyValueView.java:235)
at
app//org.apache.ignite.internal.client.table.ClientTable.lambda$doSchemaOutInOpAsync$5(ClientTable.java:460)
at
app//org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:332)
... 30 more
Caused by: org.apache.ignite.internal.marshaller.MarshallerException:
IGN-CMN-65535 TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59
java.lang.ClassCastException: class java.time.LocalDate cannot be cast to class
[B (java.time.LocalDate and [B are in module java.base of loader 'bootstrap')
at
app//org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:401)
at
app//org.apache.ignite.internal.marshaller.Marshaller$PojoMarshaller.writeField(Marshaller.java:300)
at
app//org.apache.ignite.internal.client.table.ClientKeyValueView.writeKeyValueRaw(ClientKeyValueView.java:606)
... 34 more
Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException:
class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
[B are in module java.base of loader 'bootstrap')
at
org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:809)
at
org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:399)
... 36 more
Caused by: java.lang.ClassCastException: class java.time.LocalDate cannot be
cast to class [B (java.time.LocalDate and [B are in module java.base of loader
'bootstrap')
at
org.apache.ignite.internal.marshaller.FieldAccessor.writeRefObject(FieldAccessor.java:381)
at
org.apache.ignite.internal.marshaller.FieldAccessor$ReferenceFieldAccessor.write0(FieldAccessor.java:807)
... 37 more {code}
was:
I'm using the Mapper API with a TypeConverter to convert a POJO field into and
Instant/Timestamp column.
However, the FieldAccessor code is very strict. It tries to find the binary
mode directly from the original field type (in the POJO) instead of the target
type of my TypeConverter.
[Here is the
culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]
> FieldAccessor does not set the correct BinaryMode when a TypeConverter is
> used to Map a POJO field
> --
>
> Key: IGNITE-22393
> URL: https://issues.apache.org/jira/browse/IGNITE-22393
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Priority: Major
> Labels: ignite-3
>
> I'm using the Mapper API with a TypeConverter to convert a POJO field into
> and Instant/Timestamp column.
> However, the FieldAccessor code is very strict. It tries to find the binary
> mode directly from the original field type (in the POJO) instead of the
> target type of my TypeConverter.
> [Here is the
> culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]
> Stacktrace:
> {code:java}
> Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:c3ef0478-fd84-4d47-a33b-2a19a1f67e59 java.lang.ClassCastException:
> class java.time.LocalDate cannot be cast to class [B (java.time.LocalDate and
> [B are in module java.base of loader 'bootstrap')
> at
>
[jira] [Updated] (IGNITE-22393) FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field
[ https://issues.apache.org/jira/browse/IGNITE-22393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiago Marques Godinho updated IGNITE-22393: --- Description: I'm using the Mapper API with a TypeConverter to convert a POJO field into and Instant/Timestamp column. However, the FieldAccessor code is very strict. It tries to find the binary mode directly from the original field type (in the POJO) instead of the target type of my TypeConverter. [Here is the culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79] was: I'm using the Mapper API with a TypeConverter to convert a POJO field into and Instant/Timestamp column. However, the FieldAccessor code is very strict. It tries to find the binary mode directly from the original field type (in the POJO) instead of the target type of my TypeConverter. [Here is the culpit|#L73-L79]] > FieldAccessor does not set the correct BinaryMode when a TypeConverter is > used to Map a POJO field > -- > > Key: IGNITE-22393 > URL: https://issues.apache.org/jira/browse/IGNITE-22393 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Tiago Marques Godinho >Priority: Major > Labels: ignite-3 > > I'm using the Mapper API with a TypeConverter to convert a POJO field into > and Instant/Timestamp column. > However, the FieldAccessor code is very strict. It tries to find the binary > mode directly from the original field type (in the POJO) instead of the > target type of my TypeConverter. > [Here is the > culpit|https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22393) FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field
[ https://issues.apache.org/jira/browse/IGNITE-22393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiago Marques Godinho updated IGNITE-22393: --- Description: I'm using the Mapper API with a TypeConverter to convert a POJO field into and Instant/Timestamp column. However, the FieldAccessor code is very strict. It tries to find the binary mode directly from the original field type (in the POJO) instead of the target type of my TypeConverter. [Here is the culpit|#L73-L79]] was: I'm using the Mapper API with a TypeConverter to convert a POJO field into and Instant/Timestamp column. However, the FieldAccessor code is very strict. It tries to find the binary mode directly from the original field type (in the POJO) instead of the target type of my TypeConverter. [Here is the culpit|[https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]]: > FieldAccessor does not set the correct BinaryMode when a TypeConverter is > used to Map a POJO field > -- > > Key: IGNITE-22393 > URL: https://issues.apache.org/jira/browse/IGNITE-22393 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Tiago Marques Godinho >Priority: Major > Labels: ignite-3 > > I'm using the Mapper API with a TypeConverter to convert a POJO field into > and Instant/Timestamp column. > However, the FieldAccessor code is very strict. It tries to find the binary > mode directly from the original field type (in the POJO) instead of the > target type of my TypeConverter. > [Here is the culpit|#L73-L79]] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22393) FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field
Tiago Marques Godinho created IGNITE-22393: -- Summary: FieldAccessor does not set the correct BinaryMode when a TypeConverter is used to Map a POJO field Key: IGNITE-22393 URL: https://issues.apache.org/jira/browse/IGNITE-22393 Project: Ignite Issue Type: Bug Affects Versions: 3.0.0-beta1 Reporter: Tiago Marques Godinho I'm using the Mapper API with a TypeConverter to convert a POJO field into and Instant/Timestamp column. However, the FieldAccessor code is very strict. It tries to find the binary mode directly from the original field type (in the POJO) instead of the target type of my TypeConverter. [Here is the culpit|[https://github.com/apache/ignite-3/blob/ceac03f6b8574c1cbe23aed64ce082a6a4978ea1/modules/marshaller-common/src/main/java/org/apache/ignite/internal/marshaller/FieldAccessor.java#L73-L79]]: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Incorrect Limit / Sort transformation
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation. It
transforms:
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
..Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
..Sort(ordering=ord, offset=o, fetch=f)
Scan
{noformat}
Which is not correct, because fetch and offset are applied twice.
was:
IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation. It
transforms:
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
-> Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
-> Sort(ordering=ord, offset=o, fetch=f)
-> Scan
{noformat}
Which is not correct, because fetch and offset are applied twice.
> Sql. Incorrect Limit / Sort transformation
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation. It
> transforms:
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> ..Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> ..Sort(ordering=ord, offset=o, fetch=f)
> Scan
> {noformat}
> Which is not correct, because fetch and offset are applied twice.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Incorrect Limit / Sort transformation
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation. It
transforms:
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
>Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
>Sort(ordering=ord, offset=o, fetch=f)
>>Scan
{noformat}
Which is not correct, because fetch and offset are applied twice.
was:
IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation. It
transforms:
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
..Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
..Sort(ordering=ord, offset=o, fetch=f)
Scan
{noformat}
Which is not correct, because fetch and offset are applied twice.
> Sql. Incorrect Limit / Sort transformation
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation. It
> transforms:
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> >Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> >Sort(ordering=ord, offset=o, fetch=f)
> >>Scan
> {noformat}
> Which is not correct, because fetch and offset are applied twice.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Incorrect Limit / Sort transformation
[ https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-22204: -- Summary: Sql. Incorrect Limit / Sort transformation (was: Sql. Set operation. Incorrect query transformation for a query with limit / offset that uses the same table) > Sql. Incorrect Limit / Sort transformation > -- > > Key: IGNITE-22204 > URL: https://issues.apache.org/jira/browse/IGNITE-22204 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Critical > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation > It transforms Sort(ordering=abc, offset=o, fetch=f) into Limit (offset=o, > fetch=f) -> Sort(ordering=abc, offset=o, fetch=f), which is not correct, > since fetch and offset are applied twice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Incorrect Limit / Sort transformation
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation. It
transforms:
{noformat}
Sort(ordering=ord, offset=o, fetch=f)
-> Scan
{noformat}
into
{noformat}
Limit (offset=o, fetch=f)
-> Sort(ordering=ord, offset=o, fetch=f)
-> Scan
{noformat}
Which is not correct, because fetch and offset are applied twice.
was:
IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation
It transforms Sort(ordering=abc, offset=o, fetch=f) into Limit (offset=o,
fetch=f) -> Sort(ordering=abc, offset=o, fetch=f), which is not correct, since
fetch and offset are applied twice.
> Sql. Incorrect Limit / Sort transformation
> --
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation. It
> transforms:
> {noformat}
> Sort(ordering=ord, offset=o, fetch=f)
> -> Scan
> {noformat}
> into
> {noformat}
> Limit (offset=o, fetch=f)
> -> Sort(ordering=ord, offset=o, fetch=f)
> -> Scan
> {noformat}
> Which is not correct, because fetch and offset are applied twice.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22204) Sql. Set operation. Incorrect query transformation for a query with limit / offset that uses the same table
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22204:
--
Description:
IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation
It transforms Sort(ordering=abc, offset=o, fetch=f) into Limit (offset=o,
fetch=f) -> Sort(ordering=abc, offset=o, fetch=f), which is not correct, since
fetch and offset are applied twice.
was:
Combination of LIMIT / OFFSET and set operator results in incorrect
transformation of a plan tree:
{noformat}
statement ok
CREATE TABLE test (a INTEGER);
statement ok
INSERT INTO test VALUES (1), (2), (3), (4);
# query 1
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
2
# query 2
query I rowsort
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
4
# combined query should return 2, 4
# but it returns 2
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
UNION ALL
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
2
4
{noformat}
Query 1
{noformat}
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
Limit(offset=[1], fetch=[1]), id = 80
Exchange(distribution=[single]), id = 79
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 78
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 50
{noformat}
Query 2
{noformat}
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
Limit(offset=[1]), id = 201
Limit(offset=[2], fetch=[3]), id = 200
Exchange(distribution=[single]), id = 199
Sort(sort0=[$0], dir0=[ASC], offset=[2], fetch=[3]), id = 198
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 168
{noformat}
Combine queries using UNION ALL
{noformat}
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
UNION ALL
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
UnionAll(all=[true]), id = 403
Limit(offset=[1], fetch=[1]), id = 400
Exchange(distribution=[single]), id = 399 # subtree is duplicated in
another part of a query
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398 #
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
Limit(offset=[1]), id = 402
Limit(offset=[2], fetch=[3]), id = 401
Exchange(distribution=[single]), id = 399 # duplicate
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
{noformat}
When tables are different, results are correct.
> Sql. Set operation. Incorrect query transformation for a query with limit /
> offset that uses the same table
> ---
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IGNITE-16013 incorrectly handles Sort(offset, fetch) transformation
> It transforms Sort(ordering=abc, offset=o, fetch=f) into Limit (offset=o,
> fetch=f) -> Sort(ordering=abc, offset=o, fetch=f), which is not correct,
> since fetch and offset are applied twice.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22204) Sql. Set operation. Incorrect query transformation for a query with limit / offset that uses the same table
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851564#comment-17851564
]
Maksim Zhuravkov commented on IGNITE-22204:
---
The previous issue is moved to
https://issues.apache.org/jira/browse/IGNITE-22392.
> Sql. Set operation. Incorrect query transformation for a query with limit /
> offset that uses the same table
> ---
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Combination of LIMIT / OFFSET and set operator results in incorrect
> transformation of a plan tree:
> {noformat}
> statement ok
> CREATE TABLE test (a INTEGER);
> statement ok
> INSERT INTO test VALUES (1), (2), (3), (4);
> # query 1
> query I rowsort
> SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
>
> 2
> # query 2
> query I rowsort
> SELECT a FROM
> (SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
> ORDER BY a OFFSET 1
> ) t(a)
>
> 4
> # combined query should return 2, 4
> # but it returns 2
> query I rowsort
> SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
> UNION ALL
> SELECT a FROM
> (SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
> ORDER BY a OFFSET 1
> ) t(a)
>
> 2
> 4
> {noformat}
> Query 1
> {noformat}
> SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
> Limit(offset=[1], fetch=[1]), id = 80
> Exchange(distribution=[single]), id = 79
>Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 78
> TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 50
> {noformat}
> Query 2
> {noformat}
> SELECT a FROM
> (SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
> ORDER BY a OFFSET 1
> ) t(a)
> Limit(offset=[1]), id = 201
>Limit(offset=[2], fetch=[3]), id = 200
> Exchange(distribution=[single]), id = 199
>Sort(sort0=[$0], dir0=[ASC], offset=[2], fetch=[3]), id = 198
> TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 168
> {noformat}
> Combine queries using UNION ALL
> {noformat}
> SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
> UNION ALL
> SELECT a FROM
> (SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
> ORDER BY a OFFSET 1
> ) t(a)
> UnionAll(all=[true]), id = 403
> Limit(offset=[1], fetch=[1]), id = 400
> Exchange(distribution=[single]), id = 399 # subtree is duplicated in
> another part of a query
> Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398 #
> TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
> Limit(offset=[1]), id = 402
> Limit(offset=[2], fetch=[3]), id = 401
> Exchange(distribution=[single]), id = 399 # duplicate
> Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398
> TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
> {noformat}
> When tables are different, results are correct.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22392) Sql. Set operation. Incorrect query transformation for a query with limit / offset that uses the same table (When RemoveSortInSubQuery is enabled)
[
https://issues.apache.org/jira/browse/IGNITE-22392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22392:
--
Description:
Combination of LIMIT / OFFSET and set operator results in incorrect
transformation of a plan tree. This issue is caused by incorrect by incorrect
handling of the `RemoveSortInSubQuery` flag inside SqlToRelConverter internals.
ATM this issue is migrated by disabling that flag.
{noformat}
statement ok
CREATE TABLE test (a INTEGER);
statement ok
INSERT INTO test VALUES (1), (2), (3), (4);
# query 1
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
2
# query 2
query I rowsort
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
4
# combined query should return 2, 4
# but it returns 2
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
UNION ALL
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
2
4
{noformat}
Query 1
{noformat}
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
Limit(offset=[1], fetch=[1]), id = 80
Exchange(distribution=[single]), id = 79
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 78
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 50
{noformat}
Query 2
{noformat}
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
Limit(offset=[1]), id = 201
Limit(offset=[2], fetch=[3]), id = 200
Exchange(distribution=[single]), id = 199
Sort(sort0=[$0], dir0=[ASC], offset=[2], fetch=[3]), id = 198
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 168
{noformat}
Combine queries using UNION ALL
{noformat}
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
UNION ALL
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
UnionAll(all=[true]), id = 403
Limit(offset=[1], fetch=[1]), id = 400
Exchange(distribution=[single]), id = 399 # subtree is duplicated in
another part of a query
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398 #
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
Limit(offset=[1]), id = 402
Limit(offset=[2], fetch=[3]), id = 401
Exchange(distribution=[single]), id = 399 # duplicate
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
{noformat}
When tables are different, results are correct.
Reproducible in vanila calcite:
{noformat}
EnumerableUnion(all=[true])
> EnumerableCalc(expr#0..1=[{inputs}], A=[$t0])
> EnumerableLimit(offset=[1], fetch=[1])
> EnumerableSort(sort0=[$0], dir0=[ASC])
> EnumerableTableScan(table=[[BLANK, TEST]])
> EnumerableCalc(expr#0..1=[{inputs}], A=[$t0])
> EnumerableLimit(offset=[2], fetch=[3])
> EnumerableSort(sort0=[$0], dir0=[ASC])
> EnumerableTableScan(table=[[BLANK, TEST]])
{noformat}
was:
Combination of LIMIT / OFFSET and set operator results in incorrect
transformation of a plan tree. This issue is caused by incorrect by incorrect
handling of the `RemoveSortInSubQuery` flag inside SqlToRelConverter internals.
ATM this issue is migrated by disabling that flag.
{noformat}
statement ok
CREATE TABLE test (a INTEGER);
statement ok
INSERT INTO test VALUES (1), (2), (3), (4);
# query 1
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
2
# query 2
query I rowsort
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
4
# combined query should return 2, 4
# but it returns 2
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
UNION ALL
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
2
4
{noformat}
Query 1
{noformat}
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
Limit(offset=[1], fetch=[1]), id = 80
Exchange(distribution=[single]), id = 79
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 78
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 50
{noformat}
Query 2
{noformat}
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
Limit(offset=[1]), id = 201
Limit(offset=[2], fetch=[3]), id = 200
Exchange(distribution=[single]), id = 199
Sort(sort0=[$0], dir0=[ASC], offset=[2], fetch=[3]), id = 198
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id
[jira] [Created] (IGNITE-22392) Sql. Set operation. Incorrect query transformation for a query with limit / offset that uses the same table (When RemoveSortInSubQuery is enabled)
Maksim Zhuravkov created IGNITE-22392:
-
Summary: Sql. Set operation. Incorrect query transformation for a
query with limit / offset that uses the same table (When RemoveSortInSubQuery
is enabled)
Key: IGNITE-22392
URL: https://issues.apache.org/jira/browse/IGNITE-22392
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Combination of LIMIT / OFFSET and set operator results in incorrect
transformation of a plan tree. This issue is caused by incorrect by incorrect
handling of the `RemoveSortInSubQuery` flag inside SqlToRelConverter internals.
ATM this issue is migrated by disabling that flag.
{noformat}
statement ok
CREATE TABLE test (a INTEGER);
statement ok
INSERT INTO test VALUES (1), (2), (3), (4);
# query 1
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
2
# query 2
query I rowsort
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
4
# combined query should return 2, 4
# but it returns 2
query I rowsort
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
UNION ALL
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
2
4
{noformat}
Query 1
{noformat}
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
Limit(offset=[1], fetch=[1]), id = 80
Exchange(distribution=[single]), id = 79
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 78
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 50
{noformat}
Query 2
{noformat}
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
Limit(offset=[1]), id = 201
Limit(offset=[2], fetch=[3]), id = 200
Exchange(distribution=[single]), id = 199
Sort(sort0=[$0], dir0=[ASC], offset=[2], fetch=[3]), id = 198
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 168
{noformat}
Combine queries using UNION ALL
{noformat}
SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
UNION ALL
SELECT a FROM
(SELECT a FROM
(SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
ORDER BY a OFFSET 1
) t(a)
UnionAll(all=[true]), id = 403
Limit(offset=[1], fetch=[1]), id = 400
Exchange(distribution=[single]), id = 399 # subtree is duplicated in
another part of a query
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398 #
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
Limit(offset=[1]), id = 402
Limit(offset=[2], fetch=[3]), id = 401
Exchange(distribution=[single]), id = 399 # duplicate
Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398
TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
{noformat}
When tables are different, results are correct.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22355) TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay don't work properly
[
https://issues.apache.org/jira/browse/IGNITE-22355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-22355:
-
Reviewer: Mirza Aliev
> TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay
> don't work properly
> -
>
> Key: IGNITE-22355
> URL: https://issues.apache.org/jira/browse/IGNITE-22355
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Description*
> In tests table creation method there is code like below:
>
> {code:java}
> try (MockedStatic affinityServiceMock =
> mockStatic(AffinityUtils.class)) {
> ArrayList> assignment = new ArrayList<>(PARTITIONS);
> for (int part = 0; part < PARTITIONS; part++) {
> assignment.add(new ArrayList<>(Collections.singleton(node)));
> }
> affinityServiceMock.when(() -> AffinityUtils.calculateAssignments(any(),
> anyInt(), anyInt()))
> .thenReturn(assignment);
> }{code}
> As the result {{AffinityUtils#calculateAssignments}} calls outside of
> try-with-resources returns List of empty sets, but desired behavior is list
> of sets with the given {{{}node{}}}.
> *Definition of done*
> {{AffinityUtils#calculateAssignments}} call inside
> {{TableManager#getOrCreateAssignments}} must returns list of non-empty sets
> with single node.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22355) TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay don't work properly
[
https://issues.apache.org/jira/browse/IGNITE-22355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851555#comment-17851555
]
Mirza Aliev commented on IGNITE-22355:
--
[~jakutenshi] LGTM
> TableManagerTest's static mocks from #mockManagersAndCreateTableWithDelay
> don't work properly
> -
>
> Key: IGNITE-22355
> URL: https://issues.apache.org/jira/browse/IGNITE-22355
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Efremov
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Description*
> In tests table creation method there is code like below:
>
> {code:java}
> try (MockedStatic affinityServiceMock =
> mockStatic(AffinityUtils.class)) {
> ArrayList> assignment = new ArrayList<>(PARTITIONS);
> for (int part = 0; part < PARTITIONS; part++) {
> assignment.add(new ArrayList<>(Collections.singleton(node)));
> }
> affinityServiceMock.when(() -> AffinityUtils.calculateAssignments(any(),
> anyInt(), anyInt()))
> .thenReturn(assignment);
> }{code}
> As the result {{AffinityUtils#calculateAssignments}} calls outside of
> try-with-resources returns List of empty sets, but desired behavior is list
> of sets with the given {{{}node{}}}.
> *Definition of done*
> {{AffinityUtils#calculateAssignments}} call inside
> {{TableManager#getOrCreateAssignments}} must returns list of non-empty sets
> with single node.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22140) Possible pagination bug in GridCacheQueryManager#runQuery()
[ https://issues.apache.org/jira/browse/IGNITE-22140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-22140: Ignite Flags: (was: Docs Required,Release Notes Required) > Possible pagination bug in GridCacheQueryManager#runQuery() > --- > > Key: IGNITE-22140 > URL: https://issues.apache.org/jira/browse/IGNITE-22140 > Project: Ignite > Issue Type: Task >Reporter: Oleg Valuyskiy >Assignee: Oleg Valuyskiy >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 40m > Remaining Estimate: 0h > > It looks like there is a pagination bug in the > GridCacheQueryManager#runQuery() method caused by fact that the ‘cnt’ counter > doesn’t get reset after sending the first page with query results. > It is advised to find out whether the bug really exists and fix it if that’s > the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22140) Possible pagination bug in GridCacheQueryManager#runQuery()
[ https://issues.apache.org/jira/browse/IGNITE-22140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-22140: Fix Version/s: 2.17 > Possible pagination bug in GridCacheQueryManager#runQuery() > --- > > Key: IGNITE-22140 > URL: https://issues.apache.org/jira/browse/IGNITE-22140 > Project: Ignite > Issue Type: Task >Reporter: Oleg Valuyskiy >Assignee: Oleg Valuyskiy >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 40m > Remaining Estimate: 0h > > It looks like there is a pagination bug in the > GridCacheQueryManager#runQuery() method caused by fact that the ‘cnt’ counter > doesn’t get reset after sending the first page with query results. > It is advised to find out whether the bug really exists and fix it if that’s > the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21985) Extend test coverage for SQL T624(Common logarithm functions)
[ https://issues.apache.org/jira/browse/IGNITE-21985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-21985: --- Assignee: Evgeny Stanilovsky > Extend test coverage for SQL T624(Common logarithm functions) > - > > Key: IGNITE-21985 > URL: https://issues.apache.org/jira/browse/IGNITE-21985 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Test coverage for SQL T624(Common logarithm functions) is poor. > Let's increase the test coverage. > > ref - test/sql/function/numeric/test_pg_math.test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22301) Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-22301:
-
Assignee: Konstantin Orlov
> Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
>
>
> Key: IGNITE-22301
> URL: https://issues.apache.org/jira/browse/IGNITE-22301
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> From time to time the CatalogManagerSelfTest.alwaysWaitForActivationTime test
> fails with the following error ([test
> history|https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-3345017748753084393=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50]).
> {noformat}
> org.mockito.exceptions.verification.TooManyActualInvocations:
> testCommand.get();
> Wanted 2 times:
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerSelfTest$TestCommand.get(CatalogManagerSelfTest.java:472)
> But was 3 times:
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> {noformat}
> This failure reproduces locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
