[jira] [Created] (IGNITE-18170) Deadlock in TableManager#updateAssignmentInternal()
Roman Puchkovskiy created IGNITE-18170: -- Summary: Deadlock in TableManager#updateAssignmentInternal() Key: IGNITE-18170 URL: https://issues.apache.org/jira/browse/IGNITE-18170 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18163) Old-style join on different column types fails with ClassCastException
[
https://issues.apache.org/jira/browse/IGNITE-18163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-18163:
Labels: calcite3-required ignite-3 (was: ignite-3)
> Old-style join on different column types fails with ClassCastException
> --
>
> Key: IGNITE-18163
> URL: https://issues.apache.org/jira/browse/IGNITE-18163
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Query:
> {code}
> select _T0.KEY, _T1.VAL from PUBLIC.TBL1 as _T0, PUBLIC.TBL_INT32 as _T1
> where _T0.KEY IS NOT DISTINCT FROM _T1.KEY
> {code}
> Result:
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:ef4217b1-04ef-4f08-b1c3-76effc3fc262 class java.lang.Long cannot be
> cast to class java.lang.Integer (java.lang.Long and java.lang.Integer are in
> module java.base of loader 'bootstrap')
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.onError(MergeJoinNode.java:124)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:205)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.lambda$start$2(ExchangeServiceImpl.java:81)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$3(MessageServiceImpl.java:133)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class java.lang.Long cannot be cast
> to class java.lang.Integer (java.lang.Long and java.lang.Integer are in
> module java.base of loader 'bootstrap')
> at java.base/java.lang.Integer.compareTo(Integer.java:59)
> at
> org.apache.calcite.rel.RelFieldCollation.compare(RelFieldCollation.java:43)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.compare(ExpressionFactoryImpl.java:235)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl$2.compare(ExpressionFactoryImpl.java:217)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$InnerJoin.join(MergeJoinNode.java:318)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode.pushLeft(MergeJoinNode.java:162)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.push(MergeJoinNode.java:112)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.pushOrdered(Inbox.java:259)
> at
> org.apache.ignite.intern
[jira] [Updated] (IGNITE-18168) SQL: incorrect sum of several FLOAT values
[
https://issues.apache.org/jira/browse/IGNITE-18168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18168:
---
Labels: calcite calcite2-required calcite3-required (was:
calcite2-required calcite3-required)
> SQL: incorrect sum of several FLOAT values
> --
>
> Key: IGNITE-18168
> URL: https://issues.apache.org/jira/browse/IGNITE-18168
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
>
> This behavior seems incorrect:
> {code:sql}
> create table xx (key_field INT PRIMARY KEY,field2 FLOAT);
> insert into xx (key_field,field2) values (1, 10);
> insert into xx (key_field,field2) values (2, 5);
> insert into xx (key_field,field2) values (3, 3);
> insert into xx (key_field,field2) values (4, 5.1);
> insert into xx (key_field,field2) values (5, 3);
> insert into xx (key_field,field2) values (6, 4);
> insert into xx (key_field,field2) values (7, 2);
> insert into xx (key_field,field2) values (8, 8);
> insert into xx (key_field,field2) values (9, 3);
> insert into xx (key_field,field2) values (10,9);
> insert into xx (key_field,field2) values (11,9);
> SELECT SUM(field2) FROM xx;
> --> returns 61.1015625, expected 61.1
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18168) SQL: incorrect sum of several FLOAT values
[
https://issues.apache.org/jira/browse/IGNITE-18168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18168:
---
Labels: calcite2-required calcite3-required (was: ignite-3)
> SQL: incorrect sum of several FLOAT values
> --
>
> Key: IGNITE-18168
> URL: https://issues.apache.org/jira/browse/IGNITE-18168
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> This behavior seems incorrect:
> {code:sql}
> create table xx (key_field INT PRIMARY KEY,field2 FLOAT);
> insert into xx (key_field,field2) values (1, 10);
> insert into xx (key_field,field2) values (2, 5);
> insert into xx (key_field,field2) values (3, 3);
> insert into xx (key_field,field2) values (4, 5.1);
> insert into xx (key_field,field2) values (5, 3);
> insert into xx (key_field,field2) values (6, 4);
> insert into xx (key_field,field2) values (7, 2);
> insert into xx (key_field,field2) values (8, 8);
> insert into xx (key_field,field2) values (9, 3);
> insert into xx (key_field,field2) values (10,9);
> insert into xx (key_field,field2) values (11,9);
> SELECT SUM(field2) FROM xx;
> --> returns 61.1015625, expected 61.1
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18166) SQL: LIKE predicate is not supported for BINARY data
[
https://issues.apache.org/jira/browse/IGNITE-18166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18166:
---
Labels: calcite calcite2-required calcite3-required (was: )
> SQL: LIKE predicate is not supported for BINARY data
>
>
> Key: IGNITE-18166
> URL: https://issues.apache.org/jira/browse/IGNITE-18166
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
>
> A 'T022' feature in SQL standard allows to use LIKE predicate for BINARY
> data. Unfortunately, it is not supported in AI3 beta1:
> {code:sql}
> create table tmp_table_binary (key_field INT PRIMARY KEY,field1 BINARY);
> INSERT INTO tmp_table_binary (key_field, field1) values(1, '00ffaa');
> INSERT INTO tmp_table_binary (key_field, field1) values(2, 'ffcc');
> select * from tmp_table_binary where field1 like '%ff%'; --
> expected to return both rows
> select * from tmp_table_binary where field1 like '_f%'; --
> expected to return 'ffcc'
> select * from tmp_table_binary where field1 like '_fc_'; --
> expected to return 'ffcc'
> {code}
> Instead of returning data, all queries show the following error:
> {code:java}
> Error: Exception while executing query [query=select * from tmp_table_binary
> where field1 like '%ff%']. Error message:From line 1, column 38 to line 1,
> column 55: Cannot apply 'LIKE' to arguments of type 'LIKE(,
> )'. Supported form(s): 'LIKE(, , )'
> (state=5,code=0)
> java.sql.SQLException: Exception while executing query [query=select * from
> tmp_table_binary where field1 like '%ff%']. Error message:From line 1, column
> 38 to line 1, column 55: Cannot apply 'LIKE' to arguments of type
> 'LIKE(, )'. Supported form(s): 'LIKE(, ,
> )'
> at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:148)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute(JdbcStatement.java:341)
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18167) SQL: incorrect NULLIF behavior
[
https://issues.apache.org/jira/browse/IGNITE-18167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18167:
---
Labels: calcite calcite2-required calcite3-required (was: )
> SQL: incorrect NULLIF behavior
> --
>
> Key: IGNITE-18167
> URL: https://issues.apache.org/jira/browse/IGNITE-18167
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
>
> A SQL spec says the following:
> ??NULLIF (V1 , V2) is equivalent to the following : CASE
> WHEN V1 = V2 THEN NULL ELSE V1 END??
> When I try to run it, the rule above is true only for the simplest cases.
> {code:sql}
> select NULLIF(25, 25); --> null(OK)
> select NULLIF(24, 25); --> 24 (OK)
> select NULLIF('test', 'abc'); --> 'test' (OK)
> select NULLIF('test', 'test'); --> '' (should be null!)
> select NULLIF(24 + 1, 26 - 1); --> error IGN-SQL-27(should be null!)
> {code}
> Probably, there are two defects: one is for wrong return value in case of
> textual data, and another one is for error when expression within NULLIF is
> used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18168) SQL: incorrect sum of several FLOAT values
[
https://issues.apache.org/jira/browse/IGNITE-18168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18168:
---
Labels: ignite-3 (was: )
> SQL: incorrect sum of several FLOAT values
> --
>
> Key: IGNITE-18168
> URL: https://issues.apache.org/jira/browse/IGNITE-18168
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3
>
> This behavior seems incorrect:
> {code:sql}
> create table xx (key_field INT PRIMARY KEY,field2 FLOAT);
> insert into xx (key_field,field2) values (1, 10);
> insert into xx (key_field,field2) values (2, 5);
> insert into xx (key_field,field2) values (3, 3);
> insert into xx (key_field,field2) values (4, 5.1);
> insert into xx (key_field,field2) values (5, 3);
> insert into xx (key_field,field2) values (6, 4);
> insert into xx (key_field,field2) values (7, 2);
> insert into xx (key_field,field2) values (8, 8);
> insert into xx (key_field,field2) values (9, 3);
> insert into xx (key_field,field2) values (10,9);
> insert into xx (key_field,field2) values (11,9);
> SELECT SUM(field2) FROM xx;
> --> returns 61.1015625, expected 61.1
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18169) IoomFailureHandlerTest.testIoomErrorPdsHandling fails on 64 core machines
Semyon Danilov created IGNITE-18169: --- Summary: IoomFailureHandlerTest.testIoomErrorPdsHandling fails on 64 core machines Key: IGNITE-18169 URL: https://issues.apache.org/jira/browse/IGNITE-18169 Project: Ignite Issue Type: Bug Affects Versions: 2.14 Reporter: Semyon Danilov Assignee: Semyon Danilov It seems like minimal fragment size of the data region is 1 megabyte. The quantity of fragments is equal to concurrency level + 1 (checkpoint buffer). So in case if we set up region size to 10 megabytes and we have 64 cores, then by default we will have concurrency level 64 and instead of 10 megabytes region size + 10 megabytes checkpoint buffer size we will have 64 megabytes region size. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18168) SQL: incorrect sum of several FLOAT values
Andrey Khitrin created IGNITE-18168:
---
Summary: SQL: incorrect sum of several FLOAT values
Key: IGNITE-18168
URL: https://issues.apache.org/jira/browse/IGNITE-18168
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin
This behavior seems incorrect:
{code:sql}
create table xx (key_field INT PRIMARY KEY,field2 FLOAT);
insert into xx (key_field,field2) values (1, 10);
insert into xx (key_field,field2) values (2, 5);
insert into xx (key_field,field2) values (3, 3);
insert into xx (key_field,field2) values (4, 5.1);
insert into xx (key_field,field2) values (5, 3);
insert into xx (key_field,field2) values (6, 4);
insert into xx (key_field,field2) values (7, 2);
insert into xx (key_field,field2) values (8, 8);
insert into xx (key_field,field2) values (9, 3);
insert into xx (key_field,field2) values (10,9);
insert into xx (key_field,field2) values (11,9);
SELECT SUM(field2) FROM xx;
--> returns 61.1015625, expected 61.1
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18167) SQL: incorrect NULLIF behavior
Andrey Khitrin created IGNITE-18167:
---
Summary: SQL: incorrect NULLIF behavior
Key: IGNITE-18167
URL: https://issues.apache.org/jira/browse/IGNITE-18167
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin
A SQL spec says the following:
??NULLIF (V1 , V2) is equivalent to the following : CASE
WHEN V1 = V2 THEN NULL ELSE V1 END??
When I try to run it, the rule above is true only for the simplest cases.
{code:sql}
select NULLIF(25, 25); --> null(OK)
select NULLIF(24, 25); --> 24 (OK)
select NULLIF('test', 'abc'); --> 'test' (OK)
select NULLIF('test', 'test'); --> '' (should be null!)
select NULLIF(24 + 1, 26 - 1); --> error IGN-SQL-27(should be null!)
{code}
Probably, there are two defects: one is for wrong return value in case of
textual data, and another one is for error when expression within NULLIF is
used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18166) SQL: LIKE predicate is not supported for BINARY data
Andrey Khitrin created IGNITE-18166:
---
Summary: SQL: LIKE predicate is not supported for BINARY data
Key: IGNITE-18166
URL: https://issues.apache.org/jira/browse/IGNITE-18166
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin
A 'T022' feature in SQL standard allows to use LIKE predicate for BINARY data.
Unfortunately, it is not supported in AI3 beta1:
{code:sql}
create table tmp_table_binary (key_field INT PRIMARY KEY,field1 BINARY);
INSERT INTO tmp_table_binary (key_field, field1) values(1, '00ffaa');
INSERT INTO tmp_table_binary (key_field, field1) values(2, 'ffcc');
select * from tmp_table_binary where field1 like '%ff%'; --
expected to return both rows
select * from tmp_table_binary where field1 like '_f%'; --
expected to return 'ffcc'
select * from tmp_table_binary where field1 like '_fc_'; --
expected to return 'ffcc'
{code}
Instead of returning data, all queries show the following error:
{code:java}
Error: Exception while executing query [query=select * from tmp_table_binary
where field1 like '%ff%']. Error message:From line 1, column 38 to line 1,
column 55: Cannot apply 'LIKE' to arguments of type 'LIKE(,
)'. Supported form(s): 'LIKE(, , )'
(state=5,code=0)
java.sql.SQLException: Exception while executing query [query=select * from
tmp_table_binary where field1 like '%ff%']. Error message:From line 1, column
38 to line 1, column 55: Cannot apply 'LIKE' to arguments of type
'LIKE(, )'. Supported form(s): 'LIKE(, ,
)'
at
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:148)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute(JdbcStatement.java:341)
...
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18052) Introduce short term locks for sorted indexes operations
[
https://issues.apache.org/jira/browse/IGNITE-18052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634536#comment-17634536
]
Denis Chudov commented on IGNITE-18052:
---
[~v.pyatkov] lgtm.
> Introduce short term locks for sorted indexes operations
>
>
> Key: IGNITE-18052
> URL: https://issues.apache.org/jira/browse/IGNITE-18052
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> *Motivation:*
> In some case, required to release a specific lock before to release all locks
> for the key in transaction. This temporary lock is also called a short term
> lock.
> The issue is the implementation of HeapLockManager is release all locks for
> specific key just worth to invoke a release method one time.
> There are no counters to conduct how many times lock was taken.
> *Definition of done:*
> Short term locks are acquired and released as described above.
> *Implementation notes:*
> A new method should be added:
> {code:java}
> // Some comments here
> void release(UUID txId, LockKey lockKey, LockMode lockMode);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18052) Introduce short term locks for sorted indexes operations
[
https://issues.apache.org/jira/browse/IGNITE-18052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18052:
--
Reviewer: Denis Chudov
> Introduce short term locks for sorted indexes operations
>
>
> Key: IGNITE-18052
> URL: https://issues.apache.org/jira/browse/IGNITE-18052
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation:*
> In some case, required to release a specific lock before to release all locks
> for the key in transaction. This temporary lock is also called a short term
> lock.
> The issue is the implementation of HeapLockManager is release all locks for
> specific key just worth to invoke a release method one time.
> There are no counters to conduct how many times lock was taken.
> *Definition of done:*
> Short term locks are acquired and released as described above.
> *Implementation notes:*
> A new method should be added:
> {code:java}
> // Some comments here
> void release(UUID txId, LockKey lockKey, LockMode lockMode);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-18162) PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky
[ https://issues.apache.org/jira/browse/IGNITE-18162 ] Vyacheslav Koptilin deleted comment on IGNITE-18162: -- was (Author: slava.koptilin): LGTM > PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky > > > Key: IGNITE-18162 > URL: https://issues.apache.org/jira/browse/IGNITE-18162 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > History: > https://ci.ignite.apache.org/project.html?branch_ignite3_Test=__all_branches__&tab=testDetails&projectId=ignite3_Test&testNameId=-7002518451967434454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18052) Introduce short term locks for sorted indexes operations
[
https://issues.apache.org/jira/browse/IGNITE-18052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-18052:
---
Description:
*Motivation:*
In some case, required to release a specific lock before to release all locks
for the key in transaction. This temporary lock is also called a short term
lock.
The issue is the implementation of HeapLockManager is release all locks for
specific key just worth to invoke a release method one time.
There are no counters to conduct how many times lock was taken.
*Definition of done:*
Short term locks are acquired and released as described above.
*Implementation notes:*
A new method should be added:
{code:java}
// Some comments here
void release(UUID txId, LockKey lockKey, LockMode lockMode);
{code}
was:
*Motivation:*
According to the transaction protocol IEP [1] insert operation in RW
transactions for sortex index looks as follows:
_Unique index:_
// insert
IX_short(nextKey) // released after the insertion
X_commit(currentKey) // acquired before releasing IX_short
_Non-unique index:_
// insert
IX_short(nextKey)
X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
IX_commit(currentKey) otherwise
This is necessary to avoid races between insert and scan operations. However,
it's not yet implemented.
*Definition of done:*
Short term locks are acquired and released as described above.
*Implementation notes:*
For the code related to locks for indexes, see
{{org.apache.ignite.internal.table.distributed.IndexLocker}}. We are interested
in {{SortedIndexLocker}} implementation, method {{locksForInsert}}. Actually,
there is some draft, but it is commented.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
> Introduce short term locks for sorted indexes operations
>
>
> Key: IGNITE-18052
> URL: https://issues.apache.org/jira/browse/IGNITE-18052
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation:*
> In some case, required to release a specific lock before to release all locks
> for the key in transaction. This temporary lock is also called a short term
> lock.
> The issue is the implementation of HeapLockManager is release all locks for
> specific key just worth to invoke a release method one time.
> There are no counters to conduct how many times lock was taken.
> *Definition of done:*
> Short term locks are acquired and released as described above.
> *Implementation notes:*
> A new method should be added:
> {code:java}
> // Some comments here
> void release(UUID txId, LockKey lockKey, LockMode lockMode);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18165) Apply short term loks to sorted indexes
[ https://issues.apache.org/jira/browse/IGNITE-18165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-18165: --- Description: *Motivation:* Transaction isolation requires using short term locks in insert operation over sorted indexes. It was not implemented because short term locks had not supported. According to the transaction protocol IEP [1] insert operation in RW transactions for sortex index looks as follows: Unique index: // insert IX_short(nextKey) // released after the insertion X_commit(currentKey) // acquired before releasing IX_short Non-unique index: // insert IX_short(nextKey) X_commit(currentKey) if nextKey previously locked in S, X or SIX mode IX_commit(currentKey) otherwise *Implementation notes:* For the code related to locks for indexes, see org.apache.ignite.internal.table.distributed.IndexLocker. We are interested in SortedIndexLocker implementation, method locksForInsert. Actually, there is some draft, but it is commented. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol was: *Motivation:* Transaction isolation requires using short term locks in insert operation over sorted indexes. It was not implemented because short term locks had not supported. *Implementation notes:* According to the transaction protocol IEP [1] insert operation in RW transactions for sortex index looks as follows: Unique index: // insert IX_short(nextKey) // released after the insertion X_commit(currentKey) // acquired before releasing IX_short Non-unique index: // insert IX_short(nextKey) X_commit(currentKey) if nextKey previously locked in S, X or SIX mode IX_commit(currentKey) otherwise [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol > Apply short term loks to sorted indexes > --- > > Key: IGNITE-18165 > URL: https://issues.apache.org/jira/browse/IGNITE-18165 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > > *Motivation:* > Transaction isolation requires using short term locks in insert operation > over sorted indexes. It was not implemented because short term locks had not > supported. > According to the transaction protocol IEP [1] insert operation in RW > transactions for sortex index looks as follows: > Unique index: > // insert > IX_short(nextKey) // released after the insertion > X_commit(currentKey) // acquired before releasing IX_short > Non-unique index: > // insert > IX_short(nextKey) > X_commit(currentKey) if nextKey previously locked in S, X or SIX mode > IX_commit(currentKey) otherwise > *Implementation notes:* > For the code related to locks for indexes, see > org.apache.ignite.internal.table.distributed.IndexLocker. We are interested > in SortedIndexLocker implementation, method locksForInsert. Actually, there > is some draft, but it is commented. > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18165) Apply short term loks to sorted indexes
Vladislav Pyatkov created IGNITE-18165: -- Summary: Apply short term loks to sorted indexes Key: IGNITE-18165 URL: https://issues.apache.org/jira/browse/IGNITE-18165 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov *Motivation:* Transaction isolation requires using short term locks in insert operation over sorted indexes. It was not implemented because short term locks had not supported. *Implementation notes:* According to the transaction protocol IEP [1] insert operation in RW transactions for sortex index looks as follows: Unique index: // insert IX_short(nextKey) // released after the insertion X_commit(currentKey) // acquired before releasing IX_short Non-unique index: // insert IX_short(nextKey) X_commit(currentKey) if nextKey previously locked in S, X or SIX mode IX_commit(currentKey) otherwise [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18162) PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky
[ https://issues.apache.org/jira/browse/IGNITE-18162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov reassigned IGNITE-18162: - Assignee: Aleksandr Polovtcev (was: Denis Chudov) > PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky > > > Key: IGNITE-18162 > URL: https://issues.apache.org/jira/browse/IGNITE-18162 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > History: > https://ci.ignite.apache.org/project.html?branch_ignite3_Test=__all_branches__&tab=testDetails&projectId=ignite3_Test&testNameId=-7002518451967434454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18162) PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky
[ https://issues.apache.org/jira/browse/IGNITE-18162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov reassigned IGNITE-18162: - Assignee: Denis Chudov (was: Aleksandr Polovtcev) > PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky > > > Key: IGNITE-18162 > URL: https://issues.apache.org/jira/browse/IGNITE-18162 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > History: > https://ci.ignite.apache.org/project.html?branch_ignite3_Test=__all_branches__&tab=testDetails&projectId=ignite3_Test&testNameId=-7002518451967434454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18162) PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky
[ https://issues.apache.org/jira/browse/IGNITE-18162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634456#comment-17634456 ] Vyacheslav Koptilin commented on IGNITE-18162: -- LGTM > PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky > > > Key: IGNITE-18162 > URL: https://issues.apache.org/jira/browse/IGNITE-18162 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > History: > https://ci.ignite.apache.org/project.html?branch_ignite3_Test=__all_branches__&tab=testDetails&projectId=ignite3_Test&testNameId=-7002518451967434454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18164) Interface javadoc link to internals
Alexander Belyak created IGNITE-18164:
-
Summary: Interface javadoc link to internals
Key: IGNITE-18164
URL: https://issues.apache.org/jira/browse/IGNITE-18164
Project: Ignite
Issue Type: Improvement
Components: documentation
Affects Versions: 2.14
Reporter: Alexander Belyak
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/Ignite.java]
contains links to the internal
{color:#00}+org.apache.ignite.internal.util.typedef.G+
{color}
{color:#00}interface. Instead, for example, of {color}
+{color:#172b4d}org.apache.ignite.Ignition{color}+
Let's clean interface documentation from internal links.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17478) CLI commands with argument groups reuse previous option values
[
https://issues.apache.org/jira/browse/IGNITE-17478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17478:
-
Fix Version/s: 3.0.0-beta2
Reviewer: Kirill Gusakov
> CLI commands with argument groups reuse previous option values
> --
>
> Key: IGNITE-17478
> URL: https://issues.apache.org/jira/browse/IGNITE-17478
> Project: Ignite
> Issue Type: Bug
> Components: cli
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Due to the picocli [issue|https://github.com/remkop/picocli/issues/1768],
> running sql command first time with -f option and second time without
> produces incorrect result where second time it runs as if -f option was
> passed.
> {noformat}
> [test]> sql -f filename
> File with command not found.
> [test]> sql
> File with command not found.{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18163) Old-style join on different column types fails with ClassCastException
[
https://issues.apache.org/jira/browse/IGNITE-18163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18163:
Description:
Query:
{code}
select _T0.KEY, _T1.VAL from PUBLIC.TBL1 as _T0, PUBLIC.TBL_INT32 as _T1 where
_T0.KEY IS NOT DISTINCT FROM _T1.KEY
{code}
Result:
{code}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:ef4217b1-04ef-4f08-b1c3-76effc3fc262 class java.lang.Long cannot be
cast to class java.lang.Integer (java.lang.Long and java.lang.Integer are in
module java.base of loader 'bootstrap')
at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
at
org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
at
java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
at
java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
at
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
at
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
at
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
at
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
at
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
at
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
at
org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.onError(MergeJoinNode.java:124)
at
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
at
org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:205)
at
org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.lambda$start$2(ExchangeServiceImpl.java:81)
at
org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
at
org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$3(MessageServiceImpl.java:133)
at
org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.ClassCastException: class java.lang.Long cannot be cast to
class java.lang.Integer (java.lang.Long and java.lang.Integer are in module
java.base of loader 'bootstrap')
at java.base/java.lang.Integer.compareTo(Integer.java:59)
at
org.apache.calcite.rel.RelFieldCollation.compare(RelFieldCollation.java:43)
at
org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.compare(ExpressionFactoryImpl.java:235)
at
org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl$2.compare(ExpressionFactoryImpl.java:217)
at
org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$InnerJoin.join(MergeJoinNode.java:318)
at
org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode.pushLeft(MergeJoinNode.java:162)
at
org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.push(MergeJoinNode.java:112)
at
org.apache.ignite.internal.sql.engine.exec.rel.Inbox.pushOrdered(Inbox.java:259)
at
org.apache.ignite.internal.sql.engine.exec.rel.Inbox.push(Inbox.java:205)
at
org.apache.ignite.internal.sql.engine.exec.rel.Inbox.onBatchReceived(Inbox.java:181)
at
org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:203)
... 7 more
{code}
T0.KEY is int32, T1.KEY is int64.
was:
Query:
{code}
select _T0.KEY, _T1.VAL from PUBLIC.TBL1 as _T0, PUBLIC.TBL_INT32 as _T1 where
_T0.KEY IS NOT DISTINCT FROM _T1.KEY
{code}
Result:
{code}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:ef4217b1-04ef-4f08-b1c3-76effc3fc262 class java.lang.Long cannot be
cast to class java.lang.Integer (java.lang.Long and java.lan
[jira] [Updated] (IGNITE-18163) Old-style join on different column types fails with ClassCastException
[
https://issues.apache.org/jira/browse/IGNITE-18163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18163:
Description:
Query:
{code}
select _T0.KEY, _T1.VAL from PUBLIC.TBL1 as _T0, PUBLIC.TBL_INT32 as _T1 where
_T0.KEY IS NOT DISTINCT FROM _T1.KEY
{code}
Result:
{code}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:ef4217b1-04ef-4f08-b1c3-76effc3fc262 class java.lang.Long cannot be
cast to class java.lang.Integer (java.lang.Long and java.lang.Integer are in
module java.base of loader 'bootstrap')
at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
at
org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
at
java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
at
java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
at
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
at
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
at
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
at
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
at
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
at
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
at
org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.onError(MergeJoinNode.java:124)
at
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
at
org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:205)
at
org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.lambda$start$2(ExchangeServiceImpl.java:81)
at
org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
at
org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$3(MessageServiceImpl.java:133)
at
org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.ClassCastException: class java.lang.Long cannot be cast to
class java.lang.Integer (java.lang.Long and java.lang.Integer are in module
java.base of loader 'bootstrap')
at java.base/java.lang.Integer.compareTo(Integer.java:59)
at
org.apache.calcite.rel.RelFieldCollation.compare(RelFieldCollation.java:43)
at
org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.compare(ExpressionFactoryImpl.java:235)
at
org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl$2.compare(ExpressionFactoryImpl.java:217)
at
org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$InnerJoin.join(MergeJoinNode.java:318)
at
org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode.pushLeft(MergeJoinNode.java:162)
at
org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.push(MergeJoinNode.java:112)
at
org.apache.ignite.internal.sql.engine.exec.rel.Inbox.pushOrdered(Inbox.java:259)
at
org.apache.ignite.internal.sql.engine.exec.rel.Inbox.push(Inbox.java:205)
at
org.apache.ignite.internal.sql.engine.exec.rel.Inbox.onBatchReceived(Inbox.java:181)
at
org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:203)
... 7 more
{code}
> Old-style join on different column types fails with ClassCastException
> --
>
> Key: IGNITE-18163
> URL: https://issues.apache.org/jira/browse/IGNITE-18163
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>
[jira] [Updated] (IGNITE-18163) Old-style join on different column types fails with ClassCastException
[
https://issues.apache.org/jira/browse/IGNITE-18163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-18163:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Old-style join on different column types fails with ClassCastException
> --
>
> Key: IGNITE-18163
> URL: https://issues.apache.org/jira/browse/IGNITE-18163
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Query:
> {code}
> select _T0.KEY, _T1.VAL from PUBLIC.TBL1 as _T0, PUBLIC.TBL_INT32 as _T1
> where _T0.KEY IS NOT DISTINCT FROM _T1.KEY
> {code}
> Result:
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:ef4217b1-04ef-4f08-b1c3-76effc3fc262 class java.lang.Long cannot be
> cast to class java.lang.Integer (java.lang.Long and java.lang.Integer are in
> module java.base of loader 'bootstrap')
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.onError(MergeJoinNode.java:124)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:205)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.lambda$start$2(ExchangeServiceImpl.java:81)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$3(MessageServiceImpl.java:133)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class java.lang.Long cannot be cast
> to class java.lang.Integer (java.lang.Long and java.lang.Integer are in
> module java.base of loader 'bootstrap')
> at java.base/java.lang.Integer.compareTo(Integer.java:59)
> at
> org.apache.calcite.rel.RelFieldCollation.compare(RelFieldCollation.java:43)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.compare(ExpressionFactoryImpl.java:235)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl$2.compare(ExpressionFactoryImpl.java:217)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$InnerJoin.join(MergeJoinNode.java:318)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode.pushLeft(MergeJoinNode.java:162)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.push(MergeJoinNode.java:112)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.pushOrdered(Inbox.java:259)
> at
> org.apache.ignite.internal.sql.engi
[jira] [Created] (IGNITE-18163) Old-style join on different column types fails with ClassCastException
Pavel Tupitsyn created IGNITE-18163: --- Summary: Old-style join on different column types fails with ClassCastException Key: IGNITE-18163 URL: https://issues.apache.org/jira/browse/IGNITE-18163 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18161) Standalone JDBC driver
[ https://issues.apache.org/jira/browse/IGNITE-18161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18161: Labels: ignite-3 (was: ) > Standalone JDBC driver > --- > > Key: IGNITE-18161 > URL: https://issues.apache.org/jira/browse/IGNITE-18161 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > Need to pack jdbc driver into separate, stand alone (or fat) jar to use in > external tools, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18162) PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky
[ https://issues.apache.org/jira/browse/IGNITE-18162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-18162: Assignee: Aleksandr Polovtcev > PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky > > > Key: IGNITE-18162 > URL: https://issues.apache.org/jira/browse/IGNITE-18162 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > History: > https://ci.ignite.apache.org/project.html?branch_ignite3_Test=__all_branches__&tab=testDetails&projectId=ignite3_Test&testNameId=-7002518451967434454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17050) Bump commons-io version
[ https://issues.apache.org/jira/browse/IGNITE-17050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev resolved IGNITE-17050. -- Resolution: Duplicate > Bump commons-io version > --- > > Key: IGNITE-17050 > URL: https://issues.apache.org/jira/browse/IGNITE-17050 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Aleksandr >Priority: Major > Labels: ise > Time Spent: 20m > Remaining Estimate: 0h > > commons-io prior 2.7 version contains several CVEs. > We should bump version to the latest 2.11.0 > https://mvnrepository.com/artifact/commons-io/commons-io/2.6 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18156) Sql. Extend SQL grammar with CREATE/DROP ZONE statement
[
https://issues.apache.org/jira/browse/IGNITE-18156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18156:
---
Parent: IGNITE-18140
Issue Type: Sub-task (was: Task)
> Sql. Extend SQL grammar with CREATE/DROP ZONE statement
> ---
>
> Key: IGNITE-18156
> URL: https://issues.apache.org/jira/browse/IGNITE-18156
> Project: Ignite
> Issue Type: Sub-task
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We need to provide an ability to configure distribution zones by DDL
> commands.
> Let's extend SQL grammar with following syntax:
> {code:java}
> CREATE ZONE
> { fq_zone_name | simple_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> {code:java}
> DROP ZONE {fq_zone_name | simple_zone_name}{code}
> As a result the parser should be able to parse mentioned statements and
> provide a valid AST representing those statements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18162) PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky
Denis Chudov created IGNITE-18162: - Summary: PendingComparableValuesTrackerTest.testMultithreadedWaitFor is flaky Key: IGNITE-18162 URL: https://issues.apache.org/jira/browse/IGNITE-18162 Project: Ignite Issue Type: Bug Reporter: Denis Chudov History: https://ci.ignite.apache.org/project.html?branch_ignite3_Test=__all_branches__&tab=testDetails&projectId=ignite3_Test&testNameId=-7002518451967434454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18157) Sql. Provide commands and handlers for distributed zones related operations
[
https://issues.apache.org/jira/browse/IGNITE-18157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18157:
---
Parent: IGNITE-18140
Issue Type: Sub-task (was: Task)
> Sql. Provide commands and handlers for distributed zones related operations
> ---
>
> Key: IGNITE-18157
> URL: https://issues.apache.org/jira/browse/IGNITE-18157
> Project: Ignite
> Issue Type: Sub-task
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> After implementing IGNITE-18156 Need to provide DDL commands and their
> handlers to configure zones configuration in, as well as translation to these
> command from AST representation.
> As a result, we will be able to translate AST to a command (see
> {{{}DdlSqlToCommandConverter{}}}) and execute this command in order to apply
> changes to configuration (see {{{}DdlCommandHandler{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18158) Sql. Investigate possible syntax and abilities for ALTER ZONE command
[ https://issues.apache.org/jira/browse/IGNITE-18158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-18158: --- Parent: IGNITE-18140 Issue Type: Sub-task (was: Task) > Sql. Investigate possible syntax and abilities for ALTER ZONE command > - > > Key: IGNITE-18158 > URL: https://issues.apache.org/jira/browse/IGNITE-18158 > Project: Ignite > Issue Type: Sub-task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As we can CREATE and DROP a distributed zones [1] [2], need to have ability > to modify the distributed zones. Let's investigate possible syntax and > abilities for the modification. > As result we should have a few new tickets with proposed syntax and > integration into the system. > [1] https://issues.apache.org/jira/browse/IGNITE-18156 > [2] https://issues.apache.org/jira/browse/IGNITE-18157 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18156) Sql. Extend SQL grammar with CREATE/DROP ZONE statement
[
https://issues.apache.org/jira/browse/IGNITE-18156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18156:
---
Issue Type: Task (was: Improvement)
> Sql. Extend SQL grammar with CREATE/DROP ZONE statement
> ---
>
> Key: IGNITE-18156
> URL: https://issues.apache.org/jira/browse/IGNITE-18156
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We need to provide an ability to configure distribution zones by DDL
> commands.
> Let's extend SQL grammar with following syntax:
> {code:java}
> CREATE ZONE
> { fq_zone_name | simple_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> {code:java}
> DROP ZONE {fq_zone_name | simple_zone_name}{code}
> As a result the parser should be able to parse mentioned statements and
> provide a valid AST representing those statements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18157) Sql. Provide commands and handlers for distributed zones related operations
[
https://issues.apache.org/jira/browse/IGNITE-18157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18157:
---
Issue Type: Task (was: Improvement)
> Sql. Provide commands and handlers for distributed zones related operations
> ---
>
> Key: IGNITE-18157
> URL: https://issues.apache.org/jira/browse/IGNITE-18157
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> After implementing IGNITE-18156 Need to provide DDL commands and their
> handlers to configure zones configuration in, as well as translation to these
> command from AST representation.
> As a result, we will be able to translate AST to a command (see
> {{{}DdlSqlToCommandConverter{}}}) and execute this command in order to apply
> changes to configuration (see {{{}DdlCommandHandler{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18160) Delete physical data after a Raft Group is stopped
[
https://issues.apache.org/jira/browse/IGNITE-18160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634370#comment-17634370
]
Aleksandr Polovtcev commented on IGNITE-18160:
--
Looks like this method is already being implemented in Page Memory:
IGNITE-17132
> Delete physical data after a Raft Group is stopped
> --
>
> Key: IGNITE-18160
> URL: https://issues.apache.org/jira/browse/IGNITE-18160
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> After a Raft Group is stopped on a node as a consequence of partition
> reassignment, we need to remove the partition data and the corresponding Raft
> log. This implies that for every storage a {{destroy}} method should be
> implemented with the following behaviour: it should return control to the
> caller as soon as possible, i.e. be asynchronous. Ideally this method should
> perform some minimal actions to pose failover guarantees and not wait for the
> data to be removed.
> We need to check that every storage type supports this method and add
> corresponding tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18160) Delete physical data after a Raft Group is stopped
[
https://issues.apache.org/jira/browse/IGNITE-18160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18160:
-
Description:
After a Raft Group is stopped on a node as a consequence of partition
reassignment, we need to remove the partition data and the corresponding Raft
log. This implies that for every storage a {{destroy}} method should be
implemented with the following behaviour: it should return control to the
caller as soon as possible, i.e. be asynchronous. Ideally this method should
perform some minimal actions to pose failover guarantees and not wait for the
data to be removed.
We need to check that every storage type supports this method and add
corresponding tests.
> Delete physical data after a Raft Group is stopped
> --
>
> Key: IGNITE-18160
> URL: https://issues.apache.org/jira/browse/IGNITE-18160
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> After a Raft Group is stopped on a node as a consequence of partition
> reassignment, we need to remove the partition data and the corresponding Raft
> log. This implies that for every storage a {{destroy}} method should be
> implemented with the following behaviour: it should return control to the
> caller as soon as possible, i.e. be asynchronous. Ideally this method should
> perform some minimal actions to pose failover guarantees and not wait for the
> data to be removed.
> We need to check that every storage type supports this method and add
> corresponding tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18161) Standalone JDBC driver
Alexander Belyak created IGNITE-18161: - Summary: Standalone JDBC driver Key: IGNITE-18161 URL: https://issues.apache.org/jira/browse/IGNITE-18161 Project: Ignite Issue Type: Improvement Components: jdbc Affects Versions: 3.0 Reporter: Alexander Belyak Need to pack jdbc driver into separate, stand alone (or fat) jar to use in external tools, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[ https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18091: - Reviewer: Vladislav Pyatkov > Compare deadlock prevention implementations and work out decisions about > correct behavior in corner cases > - > > Key: IGNITE-18091 > URL: https://issues.apache.org/jira/browse/IGNITE-18091 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > Today we have several possible implementations of deadlock prevention: AI 3 > [1], transactions POC [2], and possible implementation based on concurrency > control paper [3]. Moreover, we have a multiple granularity lock model [4] > where some lock modes are compatible, others are not, which allows > reenterability in some cases, and sharing of locks between transactions. We > should understand the differences of behavior of each implementation in > different scenarios, and how it matches with our expectations. > *Definition of done* > Table with a set of scenarios and description of behavior, including the > expected one. > [1] org.apache.ignite.internal.tx.impl.HeapLockManager > [2] https://github.com/ascherbakoff/ai3-txn-mvp > [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260 > [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18160) Delete physical data after a Raft Group is stopped
Aleksandr Polovtcev created IGNITE-18160: Summary: Delete physical data after a Raft Group is stopped Key: IGNITE-18160 URL: https://issues.apache.org/jira/browse/IGNITE-18160 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18158) Sql. Investigate possible syntax and abilities for ALTER ZONE command
[ https://issues.apache.org/jira/browse/IGNITE-18158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-18158: --- Epic Link: (was: IGNITE-18140) > Sql. Investigate possible syntax and abilities for ALTER ZONE command > - > > Key: IGNITE-18158 > URL: https://issues.apache.org/jira/browse/IGNITE-18158 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As we can CREATE and DROP a distributed zones [1] [2], need to have ability > to modify the distributed zones. Let's investigate possible syntax and > abilities for the modification. > As result we should have a few new tickets with proposed syntax and > integration into the system. > [1] https://issues.apache.org/jira/browse/IGNITE-18156 > [2] https://issues.apache.org/jira/browse/IGNITE-18157 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18157) Sql. Provide commands and handlers for distributed zones related operations
[
https://issues.apache.org/jira/browse/IGNITE-18157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18157:
---
Epic Link: (was: IGNITE-18140)
> Sql. Provide commands and handlers for distributed zones related operations
> ---
>
> Key: IGNITE-18157
> URL: https://issues.apache.org/jira/browse/IGNITE-18157
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> After implementing IGNITE-18156 Need to provide DDL commands and their
> handlers to configure zones configuration in, as well as translation to these
> command from AST representation.
> As a result, we will be able to translate AST to a command (see
> {{{}DdlSqlToCommandConverter{}}}) and execute this command in order to apply
> changes to configuration (see {{{}DdlCommandHandler{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18140) Add ability to create, alter and drop distribution zones from within sql-like public API
[
https://issues.apache.org/jira/browse/IGNITE-18140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18140:
---
Epic Link: IGNITE-17924
> Add ability to create, alter and drop distribution zones from within sql-like
> public API
>
>
> Key: IGNITE-18140
> URL: https://issues.apache.org/jira/browse/IGNITE-18140
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> [IEP-97|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97%3A+Distribution+Zones]
> introduces new concept of distribution zone along with some assumptions of a
> corresponding [manager|https://issues.apache.org/jira/browse/IGNITE-18093]
> that will provide an API to create, alter, and drop zones. It's however an
> internal API and thus it's required to provide a public one:
> {code:java}
> CREATE ZONE
> { database_name.schema_name.distribution_zone_name |
> schema_name.distribution_zone_name | distribution_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> Few examples
> {code:java}
> Ex 1.1: CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_SCALE_UP = 300,
> PARTITIONS = 1024, REPLICAS = 3, AFFINITY_FUNCTION = rendezvous; // Scale up
> only.
>
> Ex 1.2: CREATE ZONE zone2 WITH DATA_NODES_AUTO_ADJUST_SCALE_UP = 300,
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = 300; // Both scale up and scale down.
> Default partitions count, replicas count and affinity function will be used.
>
> Ex 1.3: CREATE ZONE zone2 WITH DATA_NODES_AUTO_ADJUST = 100; // Same value
> for both scale up and scale down. Default partitions count, replicas count
> and affinity function will be used. {code}
> And yes, similar syntax is expected for altering and dropping distribution
> zones.
> h3. Definition of Done
> * It's possible to create/alter/drop distribution zones, meaning that
> corresponding methods of distribution zone manager are called.
> * Exceptions if any, e.g. validation ones are properly wrapped and returned
> back to the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18140) Add ability to create, alter and drop distribution zones from within sql-like public API
[
https://issues.apache.org/jira/browse/IGNITE-18140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18140:
---
Issue Type: Improvement (was: Epic)
> Add ability to create, alter and drop distribution zones from within sql-like
> public API
>
>
> Key: IGNITE-18140
> URL: https://issues.apache.org/jira/browse/IGNITE-18140
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> [IEP-97|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97%3A+Distribution+Zones]
> introduces new concept of distribution zone along with some assumptions of a
> corresponding [manager|https://issues.apache.org/jira/browse/IGNITE-18093]
> that will provide an API to create, alter, and drop zones. It's however an
> internal API and thus it's required to provide a public one:
> {code:java}
> CREATE ZONE
> { database_name.schema_name.distribution_zone_name |
> schema_name.distribution_zone_name | distribution_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> Few examples
> {code:java}
> Ex 1.1: CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_SCALE_UP = 300,
> PARTITIONS = 1024, REPLICAS = 3, AFFINITY_FUNCTION = rendezvous; // Scale up
> only.
>
> Ex 1.2: CREATE ZONE zone2 WITH DATA_NODES_AUTO_ADJUST_SCALE_UP = 300,
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = 300; // Both scale up and scale down.
> Default partitions count, replicas count and affinity function will be used.
>
> Ex 1.3: CREATE ZONE zone2 WITH DATA_NODES_AUTO_ADJUST = 100; // Same value
> for both scale up and scale down. Default partitions count, replicas count
> and affinity function will be used. {code}
> And yes, similar syntax is expected for altering and dropping distribution
> zones.
> h3. Definition of Done
> * It's possible to create/alter/drop distribution zones, meaning that
> corresponding methods of distribution zone manager are called.
> * Exceptions if any, e.g. validation ones are properly wrapped and returned
> back to the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18156) Sql. Extend SQL grammar with CREATE/DROP ZONE statement
[
https://issues.apache.org/jira/browse/IGNITE-18156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18156:
---
Epic Link: (was: IGNITE-18140)
> Sql. Extend SQL grammar with CREATE/DROP ZONE statement
> ---
>
> Key: IGNITE-18156
> URL: https://issues.apache.org/jira/browse/IGNITE-18156
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We need to provide an ability to configure distribution zones by DDL
> commands.
> Let's extend SQL grammar with following syntax:
> {code:java}
> CREATE ZONE
> { fq_zone_name | simple_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> {code:java}
> DROP ZONE {fq_zone_name | simple_zone_name}{code}
> As a result the parser should be able to parse mentioned statements and
> provide a valid AST representing those statements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18063) MessageService should use conistent IDs instead of node IDs
[
https://issues.apache.org/jira/browse/IGNITE-18063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18063:
-
Epic Link: IGNITE-17956
> MessageService should use conistent IDs instead of node IDs
> ---
>
> Key: IGNITE-18063
> URL: https://issues.apache.org/jira/browse/IGNITE-18063
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> For some reason {{MessageService}} class and its users (e.g.
> `InternalTable#assignments`) use node IDs, which can change if a node is
> restarted (and lead to unknown and untested bugs). This also leads to
> ineffective code in the implementation, because it has to scan over the whole
> topology to find a node by its ID. Instead, these classes should operate with
> consistent IDs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18159) Implement splitting of an Ignite node hosting a learner and a follower from the same Raft group
[
https://issues.apache.org/jira/browse/IGNITE-18159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18159:
-
Description:
As described in IGNITE-18070, we need to implement one of the scenarios that
will allow us to have a single Ignite node hosting a follower and a learner
from the same Raft group. This ticket focuses on a case when a node gets
"split", that is, when after calculating the assignments, a follower (or a
learner) gets moved to a different Ignite node.
The algorithm looks like the following: after stable assignments have been
changes, we simply destroy the follower's (or learner's, whichever gets moved)
storage data (looks like a good place for that would be inside the
{{metaStorageMgr.registerWatchByPrefix(ByteArray.fromString(STABLE_ASSIGNMENTS_PREFIX)}}
listener in the {{TableManager}}) on the node that gets "split" . The other
node should simply start the corresponding Raft service as usual, its data
would be transferred by Raft replication.
> Implement splitting of an Ignite node hosting a learner and a follower from
> the same Raft group
> ---
>
> Key: IGNITE-18159
> URL: https://issues.apache.org/jira/browse/IGNITE-18159
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> As described in IGNITE-18070, we need to implement one of the scenarios that
> will allow us to have a single Ignite node hosting a follower and a learner
> from the same Raft group. This ticket focuses on a case when a node gets
> "split", that is, when after calculating the assignments, a follower (or a
> learner) gets moved to a different Ignite node.
> The algorithm looks like the following: after stable assignments have been
> changes, we simply destroy the follower's (or learner's, whichever gets
> moved) storage data (looks like a good place for that would be inside the
> {{metaStorageMgr.registerWatchByPrefix(ByteArray.fromString(STABLE_ASSIGNMENTS_PREFIX)}}
> listener in the {{TableManager}}) on the node that gets "split" . The other
> node should simply start the corresponding Raft service as usual, its data
> would be transferred by Raft replication.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18159) Implement splitting of an Ignite node hosting a learner and a follower from the same Raft group
Aleksandr Polovtcev created IGNITE-18159: Summary: Implement splitting of an Ignite node hosting a learner and a follower from the same Raft group Key: IGNITE-18159 URL: https://issues.apache.org/jira/browse/IGNITE-18159 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-8801:
---
Release Note:
IGNITE_ALLOW_ATOMIC_OPS_IN_TX turned false by default. To return the previous
behaviour and to allow transactions in operations with atomic caches set
IGNITE_ALLOW_ATOMIC_OPS_IN_TX to true in IgniteSystemProperties
was:IGNITE_ALLOW_ATOMIC_OPS_IN_TX turned false by default
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> {{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As per the latest round of discussion on Ignite Dev List as of 28/10/2022 we
> agreed on the following:
> 1) Revert deprecation IGNITE-17916 - reverted
> 2) Change default value in 2.15.
> 3) Notify users in release notes, an exception message - how to change the
> behavior back.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18158) Sql. Investigate possible syntax and abilities for ALTER ZONE command
[ https://issues.apache.org/jira/browse/IGNITE-18158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-18158: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Investigate possible syntax and abilities for ALTER ZONE command > - > > Key: IGNITE-18158 > URL: https://issues.apache.org/jira/browse/IGNITE-18158 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As we can CREATE and DROP a distributed zones [1] [2], need to have ability > to modify the distributed zones. Let's investigate possible syntax and > abilities for the modification. > As result we should have a few new tickets with proposed syntax and > integration into the system. > [1] https://issues.apache.org/jira/browse/IGNITE-18156 > [2] https://issues.apache.org/jira/browse/IGNITE-18157 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18158) Sql. Investigate possible syntax and abilities for ALTER ZONE command
[ https://issues.apache.org/jira/browse/IGNITE-18158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-18158: -- Issue Type: Task (was: Improvement) > Sql. Investigate possible syntax and abilities for ALTER ZONE command > - > > Key: IGNITE-18158 > URL: https://issues.apache.org/jira/browse/IGNITE-18158 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As we can CREATE and DROP a distributed zones [1] [2], need to have ability > to modify the distributed zones. Let's investigate possible syntax and > abilities for the modification. > As result we should have a few new tickets with proposed syntax and > integration into the system. > [1] https://issues.apache.org/jira/browse/IGNITE-18156 > [2] https://issues.apache.org/jira/browse/IGNITE-18157 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18158) Sql. Investigate possible syntax and abilities for ALTER ZONE command
[ https://issues.apache.org/jira/browse/IGNITE-18158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-18158: --- Description: As we can CREATE and DROP a distributed zones [1] [2], need to have ability to modify the distributed zones. Let's investigate possible syntax and abilities for the modification. As result we should have a few new tickets with proposed syntax and integration into the system. [1] https://issues.apache.org/jira/browse/IGNITE-18156 [2] https://issues.apache.org/jira/browse/IGNITE-18157 was: As we can CREATE and DROP a distributed zones, need to have ability to modify the distributed zones. Let's investigate possible syntax and abilities for the modification. As result we should have a few new tickets with proposed syntax and integration into the system. > Sql. Investigate possible syntax and abilities for ALTER ZONE command > - > > Key: IGNITE-18158 > URL: https://issues.apache.org/jira/browse/IGNITE-18158 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As we can CREATE and DROP a distributed zones [1] [2], need to have ability > to modify the distributed zones. Let's investigate possible syntax and > abilities for the modification. > As result we should have a few new tickets with proposed syntax and > integration into the system. > [1] https://issues.apache.org/jira/browse/IGNITE-18156 > [2] https://issues.apache.org/jira/browse/IGNITE-18157 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18157) Sql. Provide commands and handlers for distributed zones related operations
[
https://issues.apache.org/jira/browse/IGNITE-18157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-18157:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Provide commands and handlers for distributed zones related operations
> ---
>
> Key: IGNITE-18157
> URL: https://issues.apache.org/jira/browse/IGNITE-18157
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> After implementing IGNITE-18156 Need to provide DDL commands and their
> handlers to configure zones configuration in, as well as translation to these
> command from AST representation.
> As a result, we will be able to translate AST to a command (see
> {{{}DdlSqlToCommandConverter{}}}) and execute this command in order to apply
> changes to configuration (see {{{}DdlCommandHandler{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18157) Sql. Provide commands and handlers for distributed zones related operations
[
https://issues.apache.org/jira/browse/IGNITE-18157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-18157:
--
Fix Version/s: 3.0.0-beta2
> Sql. Provide commands and handlers for distributed zones related operations
> ---
>
> Key: IGNITE-18157
> URL: https://issues.apache.org/jira/browse/IGNITE-18157
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> After implementing IGNITE-18156 Need to provide DDL commands and their
> handlers to configure zones configuration in, as well as translation to these
> command from AST representation.
> As a result, we will be able to translate AST to a command (see
> {{{}DdlSqlToCommandConverter{}}}) and execute this command in order to apply
> changes to configuration (see {{{}DdlCommandHandler{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18158) Sql. Investigate possible syntax and abilities for ALTER ZONE command
Yury Gerzhedovich created IGNITE-18158: -- Summary: Sql. Investigate possible syntax and abilities for ALTER ZONE command Key: IGNITE-18158 URL: https://issues.apache.org/jira/browse/IGNITE-18158 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich As we can CREATE and DROP a distributed zones, need to have ability to modify the distributed zones. Let's investigate possible syntax and abilities for the modification. As result we should have a few new tickets with proposed syntax and integration into the system. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18156) Sql. Extend SQL grammar with CREATE/DROP ZONE statement
[
https://issues.apache.org/jira/browse/IGNITE-18156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-18156:
--
Fix Version/s: 3.0.0-beta2
> Sql. Extend SQL grammar with CREATE/DROP ZONE statement
> ---
>
> Key: IGNITE-18156
> URL: https://issues.apache.org/jira/browse/IGNITE-18156
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We need to provide an ability to configure distribution zones by DDL
> commands.
> Let's extend SQL grammar with following syntax:
> {code:java}
> CREATE ZONE
> { fq_zone_name | simple_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> {code:java}
> DROP ZONE {fq_zone_name | simple_zone_name}{code}
> As a result the parser should be able to parse mentioned statements and
> provide a valid AST representing those statements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18157) Sql. Provide commands and handlers for distributed zones related operations
[
https://issues.apache.org/jira/browse/IGNITE-18157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18157:
---
Labels: ignite-3 (was: )
> Sql. Provide commands and handlers for distributed zones related operations
> ---
>
> Key: IGNITE-18157
> URL: https://issues.apache.org/jira/browse/IGNITE-18157
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> After implementing IGNITE-18156 Need to provide DDL commands and their
> handlers to configure zones configuration in, as well as translation to these
> command from AST representation.
> As a result, we will be able to translate AST to a command (see
> {{{}DdlSqlToCommandConverter{}}}) and execute this command in order to apply
> changes to configuration (see {{{}DdlCommandHandler{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18157) Sql. Provide commands and handlers for distributed zones related operations
Yury Gerzhedovich created IGNITE-18157:
--
Summary: Sql. Provide commands and handlers for distributed zones
related operations
Key: IGNITE-18157
URL: https://issues.apache.org/jira/browse/IGNITE-18157
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Yury Gerzhedovich
After implementing IGNITE-18156 Need to provide DDL commands and their handlers
to configure zones configuration in, as well as translation to these command
from AST representation.
As a result, we will be able to translate AST to a command (see
{{{}DdlSqlToCommandConverter{}}}) and execute this command in order to apply
changes to configuration (see {{{}DdlCommandHandler{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18156) Sql. Extend SQL grammar with CREATE/DROP ZONE statement
[
https://issues.apache.org/jira/browse/IGNITE-18156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18156:
---
Labels: ignite-3 (was: )
> Sql. Extend SQL grammar with CREATE/DROP ZONE statement
> ---
>
> Key: IGNITE-18156
> URL: https://issues.apache.org/jira/browse/IGNITE-18156
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> We need to provide an ability to configure distribution zones by DDL
> commands.
> Let's extend SQL grammar with following syntax:
> {code:java}
> CREATE ZONE
> { fq_zone_name | simple_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> {code:java}
> DROP ZONE {fq_zone_name | simple_zone_name}{code}
> As a result the parser should be able to parse mentioned statements and
> provide a valid AST representing those statements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18156) Sql. Extend SQL grammar with CREATE/DROP ZONE statement
[
https://issues.apache.org/jira/browse/IGNITE-18156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18156:
---
Epic Link: IGNITE-18140
> Sql. Extend SQL grammar with CREATE/DROP ZONE statement
> ---
>
> Key: IGNITE-18156
> URL: https://issues.apache.org/jira/browse/IGNITE-18156
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
>
> We need to provide an ability to configure distribution zones by DDL
> commands.
> Let's extend SQL grammar with following syntax:
> {code:java}
> CREATE ZONE
> { fq_zone_name | simple_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> {code:java}
> DROP ZONE {fq_zone_name | simple_zone_name}{code}
> As a result the parser should be able to parse mentioned statements and
> provide a valid AST representing those statements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18156) Sql. Extend SQL grammar with CREATE/DROP ZONE statement
Yury Gerzhedovich created IGNITE-18156:
--
Summary: Sql. Extend SQL grammar with CREATE/DROP ZONE statement
Key: IGNITE-18156
URL: https://issues.apache.org/jira/browse/IGNITE-18156
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Yury Gerzhedovich
We need to provide an ability to configure distribution zones by DDL commands.
Let's extend SQL grammar with following syntax:
CREATE ZONE
\{ fq_zone_name | simple_zone_name }
[WITH
[
|
DATA_NODES_FILTER filter |
(, DATA_NODES_FILTER filter)
],
[PARTITIONS = partitions],
[REPLICAS = replicas],
[AFFINITY_FUNCTION = function]
]
[;]
::= [
DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
(DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) | DATA_NODES_AUTO_ADJUST
= auto_adjust_value
]
{code:java}
DROP ZONE {fq_zone_name | simple_zone_name}{code}
As a result the parser should be able to parse mentioned statements and provide
a valid AST representing those statements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18156) Sql. Extend SQL grammar with CREATE/DROP ZONE statement
[
https://issues.apache.org/jira/browse/IGNITE-18156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18156:
---
Description:
We need to provide an ability to configure distribution zones by DDL commands.
Let's extend SQL grammar with following syntax:
{code:java}
CREATE ZONE
{ fq_zone_name | simple_zone_name }
[WITH
[
|
DATA_NODES_FILTER filter |
(, DATA_NODES_FILTER filter)
],
[PARTITIONS = partitions],
[REPLICAS = replicas],
[AFFINITY_FUNCTION = function]
]
[;]
::= [
DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
(DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) | DATA_NODES_AUTO_ADJUST
= auto_adjust_value
]{code}
{code:java}
DROP ZONE {fq_zone_name | simple_zone_name}{code}
As a result the parser should be able to parse mentioned statements and provide
a valid AST representing those statements.
was:
We need to provide an ability to configure distribution zones by DDL commands.
Let's extend SQL grammar with following syntax:
CREATE ZONE
\{ fq_zone_name | simple_zone_name }
[WITH
[
|
DATA_NODES_FILTER filter |
(, DATA_NODES_FILTER filter)
],
[PARTITIONS = partitions],
[REPLICAS = replicas],
[AFFINITY_FUNCTION = function]
]
[;]
::= [
DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
(DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) | DATA_NODES_AUTO_ADJUST
= auto_adjust_value
]
{code:java}
DROP ZONE {fq_zone_name | simple_zone_name}{code}
As a result the parser should be able to parse mentioned statements and provide
a valid AST representing those statements.
> Sql. Extend SQL grammar with CREATE/DROP ZONE statement
> ---
>
> Key: IGNITE-18156
> URL: https://issues.apache.org/jira/browse/IGNITE-18156
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
>
> We need to provide an ability to configure distribution zones by DDL
> commands.
> Let's extend SQL grammar with following syntax:
> {code:java}
> CREATE ZONE
> { fq_zone_name | simple_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> {code:java}
> DROP ZONE {fq_zone_name | simple_zone_name}{code}
> As a result the parser should be able to parse mentioned statements and
> provide a valid AST representing those statements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18140) Add ability to create, alter and drop distribution zones from within sql-like public API
[
https://issues.apache.org/jira/browse/IGNITE-18140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18140:
---
Issue Type: Epic (was: Improvement)
> Add ability to create, alter and drop distribution zones from within sql-like
> public API
>
>
> Key: IGNITE-18140
> URL: https://issues.apache.org/jira/browse/IGNITE-18140
> Project: Ignite
> Issue Type: Epic
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> [IEP-97|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97%3A+Distribution+Zones]
> introduces new concept of distribution zone along with some assumptions of a
> corresponding [manager|https://issues.apache.org/jira/browse/IGNITE-18093]
> that will provide an API to create, alter, and drop zones. It's however an
> internal API and thus it's required to provide a public one:
> {code:java}
> CREATE ZONE
> { database_name.schema_name.distribution_zone_name |
> schema_name.distribution_zone_name | distribution_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> Few examples
> {code:java}
> Ex 1.1: CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_SCALE_UP = 300,
> PARTITIONS = 1024, REPLICAS = 3, AFFINITY_FUNCTION = rendezvous; // Scale up
> only.
>
> Ex 1.2: CREATE ZONE zone2 WITH DATA_NODES_AUTO_ADJUST_SCALE_UP = 300,
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = 300; // Both scale up and scale down.
> Default partitions count, replicas count and affinity function will be used.
>
> Ex 1.3: CREATE ZONE zone2 WITH DATA_NODES_AUTO_ADJUST = 100; // Same value
> for both scale up and scale down. Default partitions count, replicas count
> and affinity function will be used. {code}
> And yes, similar syntax is expected for altering and dropping distribution
> zones.
> h3. Definition of Done
> * It's possible to create/alter/drop distribution zones, meaning that
> corresponding methods of distribution zone manager are called.
> * Exceptions if any, e.g. validation ones are properly wrapped and returned
> back to the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18140) Add ability to create, alter and drop distribution zones from within sql-like public API
[
https://issues.apache.org/jira/browse/IGNITE-18140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18140:
---
Epic Link: (was: IGNITE-17924)
> Add ability to create, alter and drop distribution zones from within sql-like
> public API
>
>
> Key: IGNITE-18140
> URL: https://issues.apache.org/jira/browse/IGNITE-18140
> Project: Ignite
> Issue Type: Epic
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> [IEP-97|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97%3A+Distribution+Zones]
> introduces new concept of distribution zone along with some assumptions of a
> corresponding [manager|https://issues.apache.org/jira/browse/IGNITE-18093]
> that will provide an API to create, alter, and drop zones. It's however an
> internal API and thus it's required to provide a public one:
> {code:java}
> CREATE ZONE
> { database_name.schema_name.distribution_zone_name |
> schema_name.distribution_zone_name | distribution_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> Few examples
> {code:java}
> Ex 1.1: CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_SCALE_UP = 300,
> PARTITIONS = 1024, REPLICAS = 3, AFFINITY_FUNCTION = rendezvous; // Scale up
> only.
>
> Ex 1.2: CREATE ZONE zone2 WITH DATA_NODES_AUTO_ADJUST_SCALE_UP = 300,
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = 300; // Both scale up and scale down.
> Default partitions count, replicas count and affinity function will be used.
>
> Ex 1.3: CREATE ZONE zone2 WITH DATA_NODES_AUTO_ADJUST = 100; // Same value
> for both scale up and scale down. Default partitions count, replicas count
> and affinity function will be used. {code}
> And yes, similar syntax is expected for altering and dropping distribution
> zones.
> h3. Definition of Done
> * It's possible to create/alter/drop distribution zones, meaning that
> corresponding methods of distribution zone manager are called.
> * Exceptions if any, e.g. validation ones are properly wrapped and returned
> back to the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17704) Get rid of usage of RelDataType in execution nodes
[
https://issues.apache.org/jira/browse/IGNITE-17704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634319#comment-17634319
]
Konstantin Orlov commented on IGNITE-17704:
---
[~xtern], LGTM!
> Get rid of usage of RelDataType in execution nodes
> --
>
> Key: IGNITE-17704
> URL: https://issues.apache.org/jira/browse/IGNITE-17704
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3, tech-debt
> Fix For: 3.0.0-beta2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Execution-related classes have no third-party dependencies except for apache
> calcite. The only thing connecting them is the RelDataType class, describing
> a type of the row.
> Seems the only actual usage of row type is inside
> {{CorrelatedNestedLoopJoinNode}}.
> So let's get rid of unnecessary coupling by reworking
> {{CorrelatedNestedLoopJoinNode}} class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18148) Dynamic completions improvements
[ https://issues.apache.org/jira/browse/IGNITE-18148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-18148: -- Assignee: Aleksandr > Dynamic completions improvements > > > Key: IGNITE-18148 > URL: https://issues.apache.org/jira/browse/IGNITE-18148 > Project: Ignite > Issue Type: Task > Components: rest >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Minor > Labels: ignite-3 > > The current state of DynamicCompletions is a first iteration that might be > improved. Also, some inconsistency might be observed for the following case: > - user sees the list of completions on `node config show` > - user adds one more configuration key, say key1.key2 > - `node config show` does not display key1.key2. > It happens because the list of keys is calculated once on the first call. > After the cached value is used. This is done just for simplicity and is > expected to be improved. > The goal of this ticket is to develop an API for operating with cluster state > from CLI perspective. The actual set of configuration keys, the actual map of > node names and urls, etc. > The API should be generic and flexible. In the future, we might use some > notification mechanism and this API should be extended by this easily. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17383:
Reviewer: Maksim Timonin
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappe
[jira] [Updated] (IGNITE-18000) Sql. Unmute SqlLogicTest
[ https://issues.apache.org/jira/browse/IGNITE-18000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-18000: -- Fix Version/s: 3.0.0-beta2 > Sql. Unmute SqlLogicTest > > > Key: IGNITE-18000 > URL: https://issues.apache.org/jira/browse/IGNITE-18000 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Due to the high instability of the ItSqlLogicTest, these tests were disabled > until the reason will be found and fixed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18070) Design the process of having a single storage for a follower and a learner on the same node
[
https://issues.apache.org/jira/browse/IGNITE-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634303#comment-17634303
]
Aleksandr Polovtcev commented on IGNITE-18070:
--
When implementing option 2, we have the following challenges:
# A node that hosts both a follower and a learner gets split, e.g. a learner
gets assigned to a different Ignite node. This case is pretty straightforward:
we can simply start the learner on the second node (data will be transferred to
it via Raft), but we need to destroy the old storage from the first node. Looks
like it can be done after the rebalance procedure completes, after Stable
Assignments Metastorage key gets updated and Raft groups are stopped.
# A node that hosts a follower and a node that hosts a learner get merged into
one. This is a tricky case, because we need to request a snapshot from the
leader (however, a leaner may copy the data from the follower it gets merge
into, but that is out of scope now), while buffering the incoming update and
avoiding corrupting the already existing raft log. I currently have no idea how
to do that, it requires additional investigation.
> Design the process of having a single storage for a follower and a learner on
> the same node
> ---
>
> Key: IGNITE-18070
> URL: https://issues.apache.org/jira/browse/IGNITE-18070
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Secondary Storage consistency is going to be implemented through the Raft
> Learners. However, there exists a challenge: what if a partition's Primary
> Storage will be assigned to the same node as its Secondary Storage? This
> means that both a follower and learner for the same partition will be hosted
> on a single node with the same consistent ID. Currently JRaft is not able to
> distinguish two nodes with the same consistent ID. There are two ways to
> solve this problem:
> # Use {{PeerId#idx}} functionality. This is a built-in JRaft mechanism to
> have multiple Raft nodes on a single physical nodes.
> # Use a single Raft node that will write into multiple storages.
> While option 1 is easy and straightforward to implement, this ticket focuses
> on investigation of the option 2. The second option has a priority because it
> is potentially more effective: since there will be less Raft nodes, there
> will be less network traffic. The main problem with this approach is when a
> learner or a follower hosted on such physical node gets moved to a different
> physical node (or two nodes get merged into one). We should check if this is
> technically possible to implement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634300#comment-17634300
]
Ignite TC Bot commented on IGNITE-17383:
{panel:title=Branch: [pull/10328/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10328/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 2{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6841400]]
* {color:#013220}IgnitePdsTestSuite2:
IgnitePdsCorruptedStoreTest.testNodeInvalidatedWhenPersistenceIsCorrupted -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6841329&buildTypeId=IgniteTests24Java8_RunAll]
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.interna
[jira] [Commented] (IGNITE-18154) Move from travis to github actions
[ https://issues.apache.org/jira/browse/IGNITE-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634285#comment-17634285 ] Nikita Amelchev commented on IGNITE-18154: -- [~ivandasch], LGTM. > Move from travis to github actions > -- > > Key: IGNITE-18154 > URL: https://issues.apache.org/jira/browse/IGNITE-18154 > Project: Ignite > Issue Type: Task >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18155) Update changePeersAsync method to support learners configuration
[
https://issues.apache.org/jira/browse/IGNITE-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18155:
-
Description:
Update {{RaftGroupService#changePeersAsync}} method to support changing
learners configuration. It should work the same way, we simply need to update
internal Raft configuration for learners as well as for peers. The new
signature will look like the following:
{code:java}
/**
* @param peers New peers.
* @param learners New leaners.
* @param term Current known leader term.
* If real raft group term will be different - changePeers will be
skipped.
* @return A future.
*/
CompletableFuture changePeersAsync(List peers, List learners,
long term);
{code}
This also implies changing the signature of
{{RaftGroupEventsListener#onNewPeersConfigurationApplied}}:
{code:java}
/**
* Invoked on the leader, when new peers' configuration applied to raft group.
*
* @param peers list of peers, which was applied by raft group membership
configuration.
* @param learners list of learners, which was applied by raft group membership
configuration.
*/
void onNewPeersConfigurationApplied(List peers, List learners);
{code}
was:
Update {{RaftGroupService#changePeersAsync}} method to support changing
learners configuration, for example:
{code:java}
/**
* @param peers New peers.
* @param learners New leaners.
* @param term Current known leader term.
* If real raft group term will be different - changePeers will be
skipped.
* @return A future.
*/
CompletableFuture changePeersAsync(List peers, List learners,
long term);
{code}
This also implies changing the signature of
{{RaftGroupEventsListener#onNewPeersConfigurationApplied}}:
{code:java}
/**
* Invoked on the leader, when new peers' configuration applied to raft group.
*
* @param peers list of peers, which was applied by raft group membership
configuration.
* @param learners list of learners, which was applied by raft group membership
configuration.
*/
void onNewPeersConfigurationApplied(List peers, List learners);
{code}
> Update changePeersAsync method to support learners configuration
>
>
> Key: IGNITE-18155
> URL: https://issues.apache.org/jira/browse/IGNITE-18155
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Update {{RaftGroupService#changePeersAsync}} method to support changing
> learners configuration. It should work the same way, we simply need to update
> internal Raft configuration for learners as well as for peers. The new
> signature will look like the following:
> {code:java}
> /**
> * @param peers New peers.
> * @param learners New leaners.
> * @param term Current known leader term.
> * If real raft group term will be different - changePeers will
> be skipped.
> * @return A future.
> */
> CompletableFuture changePeersAsync(List peers, List
> learners, long term);
> {code}
> This also implies changing the signature of
> {{RaftGroupEventsListener#onNewPeersConfigurationApplied}}:
> {code:java}
> /**
> * Invoked on the leader, when new peers' configuration applied to raft group.
> *
> * @param peers list of peers, which was applied by raft group membership
> configuration.
> * @param learners list of learners, which was applied by raft group
> membership configuration.
> */
> void onNewPeersConfigurationApplied(List peers, List
> learners);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18155) Update changePeersAsync method to support learners configuration
[
https://issues.apache.org/jira/browse/IGNITE-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18155:
-
Description:
Update {{RaftGroupService#changePeersAsync}} method to support changing
learners configuration, for example:
{code:java}
/**
* @param peers New peers.
* @param learners New leaners.
* @param term Current known leader term.
* If real raft group term will be different - changePeers will be
skipped.
* @return A future.
*/
CompletableFuture changePeersAsync(List peers, List learners,
long term);
{code}
This also implies changing the signature of
{{RaftGroupEventsListener#onNewPeersConfigurationApplied}}:
{code:java}
/**
* Invoked on the leader, when new peers' configuration applied to raft group.
*
* @param peers list of peers, which was applied by raft group membership
configuration.
* @param learners list of learners, which was applied by raft group membership
configuration.
*/
void onNewPeersConfigurationApplied(List peers, List learners);
{code}
> Update changePeersAsync method to support learners configuration
>
>
> Key: IGNITE-18155
> URL: https://issues.apache.org/jira/browse/IGNITE-18155
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Update {{RaftGroupService#changePeersAsync}} method to support changing
> learners configuration, for example:
> {code:java}
> /**
> * @param peers New peers.
> * @param learners New leaners.
> * @param term Current known leader term.
> * If real raft group term will be different - changePeers will
> be skipped.
> * @return A future.
> */
> CompletableFuture changePeersAsync(List peers, List
> learners, long term);
> {code}
> This also implies changing the signature of
> {{RaftGroupEventsListener#onNewPeersConfigurationApplied}}:
> {code:java}
> /**
> * Invoked on the leader, when new peers' configuration applied to raft group.
> *
> * @param peers list of peers, which was applied by raft group membership
> configuration.
> * @param learners list of learners, which was applied by raft group
> membership configuration.
> */
> void onNewPeersConfigurationApplied(List peers, List
> learners);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18154) Move from travis to github actions
[ https://issues.apache.org/jira/browse/IGNITE-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-18154: - Priority: Minor (was: Major) > Move from travis to github actions > -- > > Key: IGNITE-18154 > URL: https://issues.apache.org/jira/browse/IGNITE-18154 > Project: Ignite > Issue Type: Task >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18155) Update changePeersAsync method to support learners configuration
Aleksandr Polovtcev created IGNITE-18155: Summary: Update changePeersAsync method to support learners configuration Key: IGNITE-18155 URL: https://issues.apache.org/jira/browse/IGNITE-18155 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18154) Move from travis to github actions
[ https://issues.apache.org/jira/browse/IGNITE-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-18154: - Ignite Flags: (was: Docs Required,Release Notes Required) > Move from travis to github actions > -- > > Key: IGNITE-18154 > URL: https://issues.apache.org/jira/browse/IGNITE-18154 > Project: Ignite > Issue Type: Task >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18155) Update changePeersAsync method to support learners configuration
[ https://issues.apache.org/jira/browse/IGNITE-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-18155: - Labels: ignite-3 (was: ) > Update changePeersAsync method to support learners configuration > > > Key: IGNITE-18155 > URL: https://issues.apache.org/jira/browse/IGNITE-18155 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18055) Sql. Support index scans with NULL conditions.
[
https://issues.apache.org/jira/browse/IGNITE-18055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov resolved IGNITE-18055.
---
Resolution: Duplicate
> Sql. Support index scans with NULL conditions.
> --
>
> Key: IGNITE-18055
> URL: https://issues.apache.org/jira/browse/IGNITE-18055
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> Query {{SELECT * FROM T1 WHERE val IS NULL}} look fine, but next cases has to
> be fixed.
> * {{SELECT * FROM T1 WHERE val IS NOT NULL}} - returns nothing.
> * {{SELECT * FROM T1 WHERE (val <= 5) or (val IS NULL)}} - returns duplicate
> rows.
> Startpoint is ItSecondaryIndexTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[
https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634256#comment-17634256
]
Denis Chudov edited comment on IGNITE-18091 at 11/15/22 9:44 AM:
-
*Correct* means that the behavior matches the expectations.
||N||Scenario||Ignite 3||MVP||Expected||
|1|*testWaitDie0* \\ var tx1 = beginTx(); \\ var tx2 = beginTx(); \\ \\ var
key1 = key("test"); \\ \\ xlock(tx2, key1).join(); \\ \\ CompletableFuture
xlockFutTx1 = xlock(tx1, key1); \\ assertFalse(xlockFutTx1.isDone()); \\
commitTx(tx2); \\ xlockFutTx1.join();|Tx2 waits on attempt to acquire
x-lock.\\*Note:* works correctly with reverse transaction order.|correct|X-lock
for tx2 fails, as tx2 younger than tx1 and is not allowed to wait for tx1, it
should DIE instead.|
|2|*testWaitDie1* \\ \\ var tx1 = beginTx(); \\ var tx2 = beginTx(); \\ \\
var key1 = key("test"); \\ \\ xlock(tx2, key1).join(); \\ \\
CompletableFuture xlockFutTx1 = xlock(tx1, key1); \\
assertFalse(xlockFutTx1.isDone()); \\ \\ commitTx(tx2); \\
xlockFutTx1.join();|Tx1 fails on attempt of acquiring the x-lock \\ \\ Note:
works correctly with reverse transaction order.|correct|tx2 successfully
acquires x-lock. \\ tx1 waits on attempt of acquiring x-lock. \\ After tx2 is
committed, the future for tx1 is completed without exception. \\ |
|3|*testWaitDieSlocks0* \\ \\ var tx1 = beginTx(); \\ var tx2 = beginTx(); \\
\\ var key1 = key("test"); \\ \\ slock(tx1, key1).join(); \\ slock(tx2,
key1).join(); \\ \\ CompletableFuture xlockTx1 = xlock(tx1, key1); \\
assertFalse(xlockTx1.isDone()); \\ \\ commitTx(tx2); \\
xlockTx1.join();|X-lock for tx1 returns future that is completed exceptionally
with LockException \\ \\ Note: works correctly with reverse transaction
order.|correct|Tx1 waits for tx2 to commit, then x-lock for tx1 is acquired.|
|4|*testWaitDieSlocks1* \\ \\ var tx1 = beginTx(); \\ var tx2 = beginTx(); \\
\\ var key1 = key("test"); \\ \\ slock(tx1, key1).join(); \\ slock(tx2,
key1).join(); \\ \\ assertThrowsException(() -> xlock(tx2, key1));|Tx2 waits
on attempt to acquire x-lock. \\ \\ Note: works correctly with reverse
transaction order.|correct|Tx2 should fail on attempt to acquire x-lock, as tx1
is holding s-lock and tx2 can’t wait for tx1.|
|5|*testWaitDieSlocks2* \\ \\ var tx1 = beginTx(); \\ var tx2 = beginTx(); \\
\\ var key1 = key("test"); \\ \\ slock(tx1, key1).join(); \\ slock(tx2,
key1).join(); \\ \\ CompletableFuture xlockTx1 = xlock(tx1, key1); \\
assertFalse(xlockTx1.isDone()); \\ \\ assertThrowsException(() -> xlock(tx2,
key1)); \\ \\ rollbackTx(tx2); \\ \\ xlockTx1.join();|Tx2 waits on attempt to
acquire x-lock.|correct|Tx1 should wait after attempt to acquire x-lock, as tx2
is holding s-lock. \\ Tx2 should fail on attempt to acquire x-lock, as tx1 is
holding s-lock and tx2 can’t wait for tx1. \\ Then tx2 rolls back, and tx1
successfully acquires x-lock. \\ \\ |
|6|*testNonFair* \\ \\ var tx1 = beginTx(); \\ var tx2 = beginTx(); \\ var tx3
= beginTx(); \\ \\ var k = key("test"); \\ \\ slock(tx3, k).join(); \\ \\
CompletableFuture futTx2 = xlock(tx2, k); \\ assertFalse(futTx2.isDone());
\\ \\ CompletableFuture futTx1 = xlock(tx1, k); \\
assertFalse(futTx1.isDone()); \\ \\ commitTx(tx3); \\ \\ futTx2.join(); \\
\\ assertFalse(futTx1.isDone()); \\ \\ commitTx(tx2); \\ \\
futTx1.join();|Tx2 waits on attempt to acquire x-lock. \\ \\ Note: works
correctly with reverse transaction order.|correct|Tx1 and tx2 wait for tx3 to
commit in order to acquire x-lock. After tx3 is committed, tx2 as more young
acquires x-lock first, and tx1 continues to wait. After tx2 is committed, tx1
acquires x-lock. So conflict between waiting transactions is resolved in an
order allowing all transactions to succeed.|
|7|*testReenterWithConflict* \\ \\ var tx1 = beginTx(); \\ var tx2 =
beginTx(); \\ \\ var k = key("test"); \\ \\ slock(tx2, k).join(); \\
slock(tx1, k).join(); \\ \\ CompletableFuture futTx1 = xlock(tx1, k); \\
assertFalse(futTx1.isDone()); \\ \\ commitTx(tx2); \\ \\ futTx1.join();|Tx1
waits on attempt to acquire x-lock. \\ \\ Note: works correctly with reverse
transaction order.|correct|Tx1 should wait for tx1 to commit in order to
upgrade s-lock to x-lock.|
|8|*testReenterWithConflictAndAbort* \\ \\ var tx1 = beginTx(); \\ var tx2 =
beginTx(); \\ \\ var k = key("test"); \\ \\ slock(tx2, k).join(); \\
slock(tx1, k).join(); \\ \\assertThrowsException(() -> xlock(tx2, k));|Tx2
waits for tx1 \\ \\Note: works correctly with reverse transaction
order.|correct|Tx2 is not allowed to wait for tx1 to commit.|
|9|*testReenterAllowed* \\ \\ var tx1 = beginTx(); \\ \\ var k = key("test");
\\ \\ slock(tx1, k).join(); \\ xlock(tx1, k).join();|correct|correct|Reenter
allowed|
|10|*testNonFairConflictWithAlreadyWaiting* \\ \\ var tx1 =
[jira] [Comment Edited] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[
https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634256#comment-17634256
]
Denis Chudov edited comment on IGNITE-18091 at 11/15/22 9:29 AM:
-
*Correct* means that the behavior matches the expectations.
||N||Scenario||Ignite 3||MVP||Expected||
|1|*testWaitDie0*
var tx1 = beginTx();
var tx2 = beginTx();
var key1 = key("test");
xlock(tx2, key1).join();
CompletableFuture xlockFutTx1 = xlock(tx1, key1);
assertFalse(xlockFutTx1.isDone());
commitTx(tx2);
xlockFutTx1.join();|Tx2 waits on attempt to acquire x-lock.
*Note:* works correctly with reverse transaction order.|correct|X-lock for tx2
fails, as tx2 younger than tx1 and is not allowed to wait for tx1, it should
DIE instead.|
|2|*testWaitDie1*
var tx1 = beginTx();var tx2 = beginTx();
var key1 = key("test");
xlock(tx2, key1).join();
CompletableFuture xlockFutTx1 = xlock(tx1, key1);
{_}assertFalse{_}(xlockFutTx1.isDone());
commitTx(tx2);
xlockFutTx1.join();|Tx1 fails on attempt of acquiring the x-lock
*Note:* works correctly with reverse transaction order.|correct|tx2
successfully acquires x-lock.
tx1 waits on attempt of acquiring x-lock.
After tx2 is committed, the future for tx1 is completed without exception.|
|3|*testWaitDieSlocks0*
*var tx1 = beginTx();var tx2 = beginTx();
*
*var key1 = key("test");
*
*slock(tx1, key1).join();slock(tx2, key1).join();*
*CompletableFuture xlockTx1 = xlock(tx1, key1);
{_}assertFalse{_}(xlockTx1.isDone());*
*commitTx(tx2);xlockTx1.join();*|X-lock for tx1 returns future that is
completed exceptionally with LockException
*Note:* works correctly with reverse transaction order.|correct|Tx1 waits for
tx2 to commit, then x-lock for tx1 is acquired.|
was (Author: denis chudov):
*Correct* means that the behavior matches the expectations.
||N||Scenario||Ignite 3||MVP||Expected||
|1|*testWaitDie0*
var tx1 = beginTx();
var tx2 = beginTx();
var key1 = key("test");
xlock(tx2, key1).join();
CompletableFuture xlockFutTx1 = xlock(tx1, key1);
assertFalse(xlockFutTx1.isDone());
commitTx(tx2);
xlockFutTx1.join();|Tx2 waits on attempt to acquire x-lock.
*Note:* works correctly with reverse transaction order.|correct|X-lock for tx2
fails, as tx2 younger than tx1 and is not allowed to wait for tx1, it should
DIE instead.|
|2|*testWaitDie1*
var tx1 = beginTx();var tx2 = beginTx();
var key1 = key("test");
xlock(tx2, key1).join();
CompletableFuture xlockFutTx1 = xlock(tx1, key1);
{_}assertFalse{_}(xlockFutTx1.isDone());
commitTx(tx2);
xlockFutTx1.join();|Tx1 fails on attempt of acquiring the x-lock
*Note:* works correctly with reverse transaction order.|correct|tx2
successfully acquires x-lock.
tx1 waits on attempt of acquiring x-lock.
After tx2 is committed, the future for tx1 is completed without exception.|
> Compare deadlock prevention implementations and work out decisions about
> correct behavior in corner cases
> -
>
> Key: IGNITE-18091
> URL: https://issues.apache.org/jira/browse/IGNITE-18091
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Today we have several possible implementations of deadlock prevention: AI 3
> [1], transactions POC [2], and possible implementation based on concurrency
> control paper [3]. Moreover, we have a multiple granularity lock model [4]
> where some lock modes are compatible, others are not, which allows
> reenterability in some cases, and sharing of locks between transactions. We
> should understand the differences of behavior of each implementation in
> different scenarios, and how it matches with our expectations.
> *Definition of done*
> Table with a set of scenarios and description of behavior, including the
> expected one.
> [1] org.apache.ignite.internal.tx.impl.HeapLockManager
> [2] https://github.com/ascherbakoff/ai3-txn-mvp
> [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260
> [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[
https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634256#comment-17634256
]
Denis Chudov edited comment on IGNITE-18091 at 11/15/22 9:28 AM:
-
*Correct* means that the behavior matches the expectations.
||N||Scenario||Ignite 3||MVP||Expected||
|1|*testWaitDie0*
var tx1 = beginTx();
var tx2 = beginTx();
var key1 = key("test");
xlock(tx2, key1).join();
CompletableFuture xlockFutTx1 = xlock(tx1, key1);
assertFalse(xlockFutTx1.isDone());
commitTx(tx2);
xlockFutTx1.join();|Tx2 waits on attempt to acquire x-lock.
*Note:* works correctly with reverse transaction order.|correct|X-lock for tx2
fails, as tx2 younger than tx1 and is not allowed to wait for tx1, it should
DIE instead.|
|2|*testWaitDie1*
var tx1 = beginTx();var tx2 = beginTx();
var key1 = key("test");
xlock(tx2, key1).join();
CompletableFuture xlockFutTx1 = xlock(tx1, key1);
{_}assertFalse{_}(xlockFutTx1.isDone());
commitTx(tx2);
xlockFutTx1.join();|Tx1 fails on attempt of acquiring the x-lock
*Note:* works correctly with reverse transaction order.|correct|tx2
successfully acquires x-lock.
tx1 waits on attempt of acquiring x-lock.
After tx2 is committed, the future for tx1 is completed without exception.|
was (Author: denis chudov):
*Correct* means that the behavior matches the expectations.
||N||Scenario||Ignite 3||MVP||Expected||
|1|*testWaitDie0*
var tx1 = beginTx();
var tx2 = beginTx();
var key1 = key("test");
xlock(tx2, key1).join();
CompletableFuture xlockFutTx1 = xlock(tx1, key1);
assertFalse(xlockFutTx1.isDone());
commitTx(tx2);
xlockFutTx1.join();|Tx2 waits on attempt to acquire x-lock.
*Note:* works correctly with reverse transaction order.|correct|X-lock for tx2
fails, as tx2 younger than tx1 and is not allowed to wait for tx1, it should
DIE instead.|
|2|*testWaitDie1*
*var tx1 = beginTx();var tx2 = beginTx();
*
*var key1 = key("test");
*
*xlock(tx2, key1).join();*
*CompletableFuture xlockFutTx1 = xlock(tx1, key1);
{_}assertFalse{_}(xlockFutTx1.isDone());
*
*commitTx(tx2);
xlockFutTx1.join();*|Tx1 fails on attempt of acquiring the x-lock
*Note:* works correctly with reverse transaction order.|correct|tx2
successfully acquires x-lock.
tx1 waits on attempt of acquiring x-lock.
After tx2 is committed, the future for tx1 is completed without exception.|
> Compare deadlock prevention implementations and work out decisions about
> correct behavior in corner cases
> -
>
> Key: IGNITE-18091
> URL: https://issues.apache.org/jira/browse/IGNITE-18091
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Today we have several possible implementations of deadlock prevention: AI 3
> [1], transactions POC [2], and possible implementation based on concurrency
> control paper [3]. Moreover, we have a multiple granularity lock model [4]
> where some lock modes are compatible, others are not, which allows
> reenterability in some cases, and sharing of locks between transactions. We
> should understand the differences of behavior of each implementation in
> different scenarios, and how it matches with our expectations.
> *Definition of done*
> Table with a set of scenarios and description of behavior, including the
> expected one.
> [1] org.apache.ignite.internal.tx.impl.HeapLockManager
> [2] https://github.com/ascherbakoff/ai3-txn-mvp
> [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260
> [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[
https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634256#comment-17634256
]
Denis Chudov edited comment on IGNITE-18091 at 11/15/22 9:27 AM:
-
*Correct* means that the behavior matches the expectations.
||N||Scenario||Ignite 3||MVP||Expected||
|1|*testWaitDie0*
var tx1 = beginTx();
var tx2 = beginTx();
var key1 = key("test");
xlock(tx2, key1).join();
CompletableFuture xlockFutTx1 = xlock(tx1, key1);
assertFalse(xlockFutTx1.isDone());
commitTx(tx2);
xlockFutTx1.join();|Tx2 waits on attempt to acquire x-lock.
*Note:* works correctly with reverse transaction order.|correct|X-lock for tx2
fails, as tx2 younger than tx1 and is not allowed to wait for tx1, it should
DIE instead.|
|2|*testWaitDie1*
*var tx1 = beginTx();var tx2 = beginTx();
*
*var key1 = key("test");
*
*xlock(tx2, key1).join();*
*CompletableFuture xlockFutTx1 = xlock(tx1, key1);
{_}assertFalse{_}(xlockFutTx1.isDone());
*
*commitTx(tx2);
xlockFutTx1.join();*|Tx1 fails on attempt of acquiring the x-lock
*Note:* works correctly with reverse transaction order.|correct|tx2
successfully acquires x-lock.
tx1 waits on attempt of acquiring x-lock.
After tx2 is committed, the future for tx1 is completed without exception.|
was (Author: denis chudov):
*Correct* means that the behavior matches the expectations.
||N||Scenario||Ignite 3||MVP||Expected||
|1|*testWaitDie0* \\ var tx1 = beginTx(); \\ var tx2 = beginTx(); \\ \\ var
key1 = key("test"); \\ \\ xlock(tx2, key1).join(); \\ \\ CompletableFuture
xlockFutTx1 = xlock(tx1, key1); \\ assertFalse(xlockFutTx1.isDone()); \\
commitTx(tx2); \\ xlockFutTx1.join();|Tx2 waits on attempt to acquire
x-lock.\\*Note:* works correctly with reverse transaction order.|correct|X-lock
for tx2 fails, as tx2 younger than tx1 and is not allowed to wait for tx1, it
should DIE instead.|
> Compare deadlock prevention implementations and work out decisions about
> correct behavior in corner cases
> -
>
> Key: IGNITE-18091
> URL: https://issues.apache.org/jira/browse/IGNITE-18091
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Today we have several possible implementations of deadlock prevention: AI 3
> [1], transactions POC [2], and possible implementation based on concurrency
> control paper [3]. Moreover, we have a multiple granularity lock model [4]
> where some lock modes are compatible, others are not, which allows
> reenterability in some cases, and sharing of locks between transactions. We
> should understand the differences of behavior of each implementation in
> different scenarios, and how it matches with our expectations.
> *Definition of done*
> Table with a set of scenarios and description of behavior, including the
> expected one.
> [1] org.apache.ignite.internal.tx.impl.HeapLockManager
> [2] https://github.com/ascherbakoff/ai3-txn-mvp
> [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260
> [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[
https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634256#comment-17634256
]
Denis Chudov edited comment on IGNITE-18091 at 11/15/22 9:24 AM:
-
*Correct* means that the behavior matches the expectations.
||N||Scenario||Ignite 3||MVP||Expected||
|1|*testWaitDie0* \\ var tx1 = beginTx(); \\ var tx2 = beginTx(); \\ \\ var
key1 = key("test"); \\ \\ xlock(tx2, key1).join(); \\ \\ CompletableFuture
xlockFutTx1 = xlock(tx1, key1); \\ assertFalse(xlockFutTx1.isDone()); \\
commitTx(tx2); \\ xlockFutTx1.join();|Tx2 waits on attempt to acquire
x-lock.\\Note: works correctly with reverse transaction order.|correct|X-lock
for tx2 fails, as tx2 younger than tx1 and is not allowed to wait for tx1, it
should DIE instead.|
was (Author: denis chudov):
||Heading 1||Heading 2||
|Col A1 \\ w\\a|Col A2|
> Compare deadlock prevention implementations and work out decisions about
> correct behavior in corner cases
> -
>
> Key: IGNITE-18091
> URL: https://issues.apache.org/jira/browse/IGNITE-18091
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Today we have several possible implementations of deadlock prevention: AI 3
> [1], transactions POC [2], and possible implementation based on concurrency
> control paper [3]. Moreover, we have a multiple granularity lock model [4]
> where some lock modes are compatible, others are not, which allows
> reenterability in some cases, and sharing of locks between transactions. We
> should understand the differences of behavior of each implementation in
> different scenarios, and how it matches with our expectations.
> *Definition of done*
> Table with a set of scenarios and description of behavior, including the
> expected one.
> [1] org.apache.ignite.internal.tx.impl.HeapLockManager
> [2] https://github.com/ascherbakoff/ai3-txn-mvp
> [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260
> [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[
https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634256#comment-17634256
]
Denis Chudov edited comment on IGNITE-18091 at 11/15/22 9:24 AM:
-
*Correct* means that the behavior matches the expectations.
||N||Scenario||Ignite 3||MVP||Expected||
|1|*testWaitDie0* \\ var tx1 = beginTx(); \\ var tx2 = beginTx(); \\ \\ var
key1 = key("test"); \\ \\ xlock(tx2, key1).join(); \\ \\ CompletableFuture
xlockFutTx1 = xlock(tx1, key1); \\ assertFalse(xlockFutTx1.isDone()); \\
commitTx(tx2); \\ xlockFutTx1.join();|Tx2 waits on attempt to acquire
x-lock.\\*Note:* works correctly with reverse transaction order.|correct|X-lock
for tx2 fails, as tx2 younger than tx1 and is not allowed to wait for tx1, it
should DIE instead.|
was (Author: denis chudov):
*Correct* means that the behavior matches the expectations.
||N||Scenario||Ignite 3||MVP||Expected||
|1|*testWaitDie0* \\ var tx1 = beginTx(); \\ var tx2 = beginTx(); \\ \\ var
key1 = key("test"); \\ \\ xlock(tx2, key1).join(); \\ \\ CompletableFuture
xlockFutTx1 = xlock(tx1, key1); \\ assertFalse(xlockFutTx1.isDone()); \\
commitTx(tx2); \\ xlockFutTx1.join();|Tx2 waits on attempt to acquire
x-lock.\\Note: works correctly with reverse transaction order.|correct|X-lock
for tx2 fails, as tx2 younger than tx1 and is not allowed to wait for tx1, it
should DIE instead.|
> Compare deadlock prevention implementations and work out decisions about
> correct behavior in corner cases
> -
>
> Key: IGNITE-18091
> URL: https://issues.apache.org/jira/browse/IGNITE-18091
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Today we have several possible implementations of deadlock prevention: AI 3
> [1], transactions POC [2], and possible implementation based on concurrency
> control paper [3]. Moreover, we have a multiple granularity lock model [4]
> where some lock modes are compatible, others are not, which allows
> reenterability in some cases, and sharing of locks between transactions. We
> should understand the differences of behavior of each implementation in
> different scenarios, and how it matches with our expectations.
> *Definition of done*
> Table with a set of scenarios and description of behavior, including the
> expected one.
> [1] org.apache.ignite.internal.tx.impl.HeapLockManager
> [2] https://github.com/ascherbakoff/ai3-txn-mvp
> [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260
> [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[ https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634256#comment-17634256 ] Denis Chudov edited comment on IGNITE-18091 at 11/15/22 9:21 AM: - ||Heading 1||Heading 2|| |Col A1 \\ w\\a|Col A2| was (Author: denis chudov): ||Heading 1||Heading 2|| |Col A1 |Col A2| > Compare deadlock prevention implementations and work out decisions about > correct behavior in corner cases > - > > Key: IGNITE-18091 > URL: https://issues.apache.org/jira/browse/IGNITE-18091 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > Today we have several possible implementations of deadlock prevention: AI 3 > [1], transactions POC [2], and possible implementation based on concurrency > control paper [3]. Moreover, we have a multiple granularity lock model [4] > where some lock modes are compatible, others are not, which allows > reenterability in some cases, and sharing of locks between transactions. We > should understand the differences of behavior of each implementation in > different scenarios, and how it matches with our expectations. > *Definition of done* > Table with a set of scenarios and description of behavior, including the > expected one. > [1] org.apache.ignite.internal.tx.impl.HeapLockManager > [2] https://github.com/ascherbakoff/ai3-txn-mvp > [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260 > [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18154) Move from travis to github actions
Ivan Daschinsky created IGNITE-18154: Summary: Move from travis to github actions Key: IGNITE-18154 URL: https://issues.apache.org/jira/browse/IGNITE-18154 Project: Ignite Issue Type: Task Reporter: Ivan Daschinsky Assignee: Ivan Daschinsky -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[ https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634256#comment-17634256 ] Denis Chudov commented on IGNITE-18091: --- ||Heading 1||Heading 2|| |Col A1 |Col A2| > Compare deadlock prevention implementations and work out decisions about > correct behavior in corner cases > - > > Key: IGNITE-18091 > URL: https://issues.apache.org/jira/browse/IGNITE-18091 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > Today we have several possible implementations of deadlock prevention: AI 3 > [1], transactions POC [2], and possible implementation based on concurrency > control paper [3]. Moreover, we have a multiple granularity lock model [4] > where some lock modes are compatible, others are not, which allows > reenterability in some cases, and sharing of locks between transactions. We > should understand the differences of behavior of each implementation in > different scenarios, and how it matches with our expectations. > *Definition of done* > Table with a set of scenarios and description of behavior, including the > expected one. > [1] org.apache.ignite.internal.tx.impl.HeapLockManager > [2] https://github.com/ascherbakoff/ai3-txn-mvp > [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260 > [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[ https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634254#comment-17634254 ] Denis Chudov edited comment on IGNITE-18091 at 11/15/22 9:17 AM: - ||Heading 1||Heading 2|| |Col A1|Col A2| Col A3|Col A4| was (Author: denis chudov): ||Heading 1||Heading 2|| |Col A1|Col A2| |Col A3|Col A4| > Compare deadlock prevention implementations and work out decisions about > correct behavior in corner cases > - > > Key: IGNITE-18091 > URL: https://issues.apache.org/jira/browse/IGNITE-18091 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > Today we have several possible implementations of deadlock prevention: AI 3 > [1], transactions POC [2], and possible implementation based on concurrency > control paper [3]. Moreover, we have a multiple granularity lock model [4] > where some lock modes are compatible, others are not, which allows > reenterability in some cases, and sharing of locks between transactions. We > should understand the differences of behavior of each implementation in > different scenarios, and how it matches with our expectations. > *Definition of done* > Table with a set of scenarios and description of behavior, including the > expected one. > [1] org.apache.ignite.internal.tx.impl.HeapLockManager > [2] https://github.com/ascherbakoff/ai3-txn-mvp > [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260 > [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[ https://issues.apache.org/jira/browse/IGNITE-18091 ] Denis Chudov deleted comment on IGNITE-18091: --- was (Author: denis chudov): ||Heading 1||Heading 2|| |Col A1|Col A2| Col A3|Col A4| > Compare deadlock prevention implementations and work out decisions about > correct behavior in corner cases > - > > Key: IGNITE-18091 > URL: https://issues.apache.org/jira/browse/IGNITE-18091 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > Today we have several possible implementations of deadlock prevention: AI 3 > [1], transactions POC [2], and possible implementation based on concurrency > control paper [3]. Moreover, we have a multiple granularity lock model [4] > where some lock modes are compatible, others are not, which allows > reenterability in some cases, and sharing of locks between transactions. We > should understand the differences of behavior of each implementation in > different scenarios, and how it matches with our expectations. > *Definition of done* > Table with a set of scenarios and description of behavior, including the > expected one. > [1] org.apache.ignite.internal.tx.impl.HeapLockManager > [2] https://github.com/ascherbakoff/ai3-txn-mvp > [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260 > [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18091) Compare deadlock prevention implementations and work out decisions about correct behavior in corner cases
[ https://issues.apache.org/jira/browse/IGNITE-18091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634254#comment-17634254 ] Denis Chudov commented on IGNITE-18091: --- ||Heading 1||Heading 2|| |Col A1|Col A2| |Col A3|Col A4| > Compare deadlock prevention implementations and work out decisions about > correct behavior in corner cases > - > > Key: IGNITE-18091 > URL: https://issues.apache.org/jira/browse/IGNITE-18091 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > Today we have several possible implementations of deadlock prevention: AI 3 > [1], transactions POC [2], and possible implementation based on concurrency > control paper [3]. Moreover, we have a multiple granularity lock model [4] > where some lock modes are compatible, others are not, which allows > reenterability in some cases, and sharing of locks between transactions. We > should understand the differences of behavior of each implementation in > different scenarios, and how it matches with our expectations. > *Definition of done* > Table with a set of scenarios and description of behavior, including the > expected one. > [1] org.apache.ignite.internal.tx.impl.HeapLockManager > [2] https://github.com/ascherbakoff/ai3-txn-mvp > [3] https://dl.acm.org/doi/pdf/10.1145/320251.320260 > [4] https://web.stanford.edu/class/cs245/readings/granularity-of-locks.pdf -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18142) Update Ignite dependency: PostgreSQL JDBC to 42.5.0
[ https://issues.apache.org/jira/browse/IGNITE-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634225#comment-17634225 ] Nikita Amelchev commented on IGNITE-18142: -- LGTM. Merged into the master. [~aonikolaev], Thank you for the contribution. > Update Ignite dependency: PostgreSQL JDBC to 42.5.0 > --- > > Key: IGNITE-18142 > URL: https://issues.apache.org/jira/browse/IGNITE-18142 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ise > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Update Ignite dependency: PostgreSQL JDBC 42.3.3 to 42.5.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18043) Replaceable deadlock prevention mechanism
[ https://issues.apache.org/jira/browse/IGNITE-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov reassigned IGNITE-18043: - Assignee: Denis Chudov > Replaceable deadlock prevention mechanism > - > > Key: IGNITE-18043 > URL: https://issues.apache.org/jira/browse/IGNITE-18043 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation:* > We have an embedded deadlock prevention strategy (presently, it is > _Wait-Die_). Although, [the original > paper|https://dl.acm.org/doi/pdf/10.1145/320251.320260] about deadlock > prevention contains another two strategies: _priorities_ and _Wound-Wait_. > Also, the mechanism should give a possibility to not use any strategy to > prevent deadlock. > All told, above shows we need to separate the prevention strategy in dedicate > interface (which even has one implementation _Wait-Die_). Another > implementation will be released by necessary. > *Definition of Done:* > A deadlock resolution strategy (_ResolutionStrategy_) has to be extracted to > interface, which parametrizes _LockManager_. Wait-Die strategy > (_WaitDieLockResolutionStrategy_) will be the only one implementation of > _ResolutionStrategy_. > _HeapLockManager_ should be parametrized by _WaitDieLockResolutionStrategy_. -- This message was sent by Atlassian Jira (v8.20.10#820010)
