date:20220217



[ 
https://issues.apache.org/jira/browse/IGNITE-16542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494433#comment-17494433
 ] 

Yury Gerzhedovich commented on IGNITE-16542:


CVE-2018-10054 - duplicate of IGNITE-11765 and not a problem
CVE-2018-14335 - duplicate of IGNITE-11765 and not a problem
CVE-2021-42392  - covered by IGNITE-11333
CVE-2022-23221, CVE-2021-23463 - Unfortunately, update to the newest H2 version 
is not possible, since H2 removed the Ignite support ( 
https://github.com/h2database/h2database/pull/2227 ) . 

> Ignite h2 security vulnerabilities
> --
>
> Key: IGNITE-16542
> URL: https://issues.apache.org/jira/browse/IGNITE-16542
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Pratiksha P
>Priority: Major
>
> I face below vulnaribilities while using ignite 2.12.0 or 2.11.0 version
>  # CVE-2018-10054
>  # CVE-2018-14335
>  # CVE-2022-23221
>  # CVE-2021-42392
>  # CVE-2021-23463
> Is there is any solution available for above issues.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16580) Calcite. Merge returns unexpected results.



 [ 
https://issues.apache.org/jira/browse/IGNITE-16580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgeny Stanilovsky updated IGNITE-16580:

Issue Type: Bug  (was: Improvement)

> Calcite. Merge returns unexpected results.
> --
>
> Key: IGNITE-16580
> URL: https://issues.apache.org/jira/browse/IGNITE-16580
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
>  Labels: calcite, calcite2-required
>
> {noformat}
> @Test
> public void testMerge0() {
> sql("CREATE TABLE test1 (k1 int, k2 int, a int, b varchar, c varchar, 
> CONSTRAINT PK PRIMARY KEY (k1, k2))");
> sql("INSERT INTO test1 VALUES (111, 111, 0, 'a', '0')");
> sql("INSERT INTO test1 VALUES (222, 222, 1, 'b', '1')");
> sql("CREATE TABLE test2 (k1 int, k2 int, a int, b varchar, c varchar, 
> CONSTRAINT PK PRIMARY KEY (k1, k2))");
> sql("INSERT INTO test2 VALUES (333, 333, 0, '100', '')");
> sql("INSERT INTO test2 VALUES (444, 444, 2, '200', '')");
> String sql = "MERGE INTO test2 dst USING test1 src ON dst.a = src.a " 
> +
> "WHEN MATCHED THEN UPDATE SET b = src.b " +
> "WHEN NOT MATCHED THEN INSERT (a, b) VALUES (src.a, src.b)";
> 
> assertQuery(sql).matches(QueryChecker.containsSubPlan("IgniteTableSpool")).check();
> assertQuery("SELECT * FROM test2 ORDER BY k1")
> .returns(222, 222, 1, "b", "1")
> .returns(333, 333, 0, "a", "")
> .returns(444, 444, 2, "200", "")
> .check();
> }
> {noformat}
> Caused by: java.lang.ClassNotFoundException: 
> SQL_PUBLIC_TEST1_3be0511e_d245_4726_b535_0514ab769875_KEY
> {noformat}
> public void testMerge1() {
> sql("CREATE TABLE test1 (a int, b varchar, c varchar)");
> sql("INSERT INTO test1 VALUES (0, 'a', '0')");
> sql("INSERT INTO test1 VALUES (1, 'b', '1')");
> sql("CREATE TABLE test2 (a int, b varchar, c varchar)");
> sql("INSERT INTO test2 VALUES (0, '100', '')");
> sql("INSERT INTO test2 VALUES (2, '200', '')");
> String sql = "MERGE INTO test2 dst USING test1 src ON dst.a = src.a " 
> +
> "WHEN MATCHED THEN UPDATE SET b = src.b " +
> "WHEN NOT MATCHED THEN INSERT (a, b) VALUES (src.a, src.b)";
> 
> assertQuery(sql).matches(QueryChecker.containsSubPlan("IgniteTableSpool")).check();
> assertQuery("SELECT * FROM test2")
> .returns(1, "b", "1")
> .returns(0, "a", "")
> .returns(2, "200", "")
> .check();
> }
> {noformat}
> Expected: [[0, a, ], [1, b, 1], [2, 200, ]]
> Actual:   [[0, a, ], [1, b, null], [2, 200, ]]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (IGNITE-16580) Calcite. Merge returns unexpected results.

Evgeny Stanilovsky created IGNITE-16580:
---

 Summary: Calcite. Merge returns unexpected results.
 Key: IGNITE-16580
 URL: https://issues.apache.org/jira/browse/IGNITE-16580
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Evgeny Stanilovsky



{noformat}
@Test
public void testMerge0() {
sql("CREATE TABLE test1 (k1 int, k2 int, a int, b varchar, c varchar, 
CONSTRAINT PK PRIMARY KEY (k1, k2))");
sql("INSERT INTO test1 VALUES (111, 111, 0, 'a', '0')");
sql("INSERT INTO test1 VALUES (222, 222, 1, 'b', '1')");

sql("CREATE TABLE test2 (k1 int, k2 int, a int, b varchar, c varchar, 
CONSTRAINT PK PRIMARY KEY (k1, k2))");
sql("INSERT INTO test2 VALUES (333, 333, 0, '100', '')");
sql("INSERT INTO test2 VALUES (444, 444, 2, '200', '')");

String sql = "MERGE INTO test2 dst USING test1 src ON dst.a = src.a " +
"WHEN MATCHED THEN UPDATE SET b = src.b " +
"WHEN NOT MATCHED THEN INSERT (a, b) VALUES (src.a, src.b)";


assertQuery(sql).matches(QueryChecker.containsSubPlan("IgniteTableSpool")).check();

assertQuery("SELECT * FROM test2 ORDER BY k1")
.returns(222, 222, 1, "b", "1")
.returns(333, 333, 0, "a", "")
.returns(444, 444, 2, "200", "")
.check();
}
{noformat}

Caused by: java.lang.ClassNotFoundException: 
SQL_PUBLIC_TEST1_3be0511e_d245_4726_b535_0514ab769875_KEY

{noformat}
public void testMerge1() {
sql("CREATE TABLE test1 (a int, b varchar, c varchar)");
sql("INSERT INTO test1 VALUES (0, 'a', '0')");
sql("INSERT INTO test1 VALUES (1, 'b', '1')");

sql("CREATE TABLE test2 (a int, b varchar, c varchar)");
sql("INSERT INTO test2 VALUES (0, '100', '')");
sql("INSERT INTO test2 VALUES (2, '200', '')");

String sql = "MERGE INTO test2 dst USING test1 src ON dst.a = src.a " +
"WHEN MATCHED THEN UPDATE SET b = src.b " +
"WHEN NOT MATCHED THEN INSERT (a, b) VALUES (src.a, src.b)";


assertQuery(sql).matches(QueryChecker.containsSubPlan("IgniteTableSpool")).check();

assertQuery("SELECT * FROM test2")
.returns(1, "b", "1")
.returns(0, "a", "")
.returns(2, "200", "")
.check();
}
{noformat}

Expected: [[0, a, ], [1, b, 1], [2, 200, ]]
Actual:   [[0, a, ], [1, b, null], [2, 200, ]]




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-16547) Sql. Adopt MERGE command.



[ 
https://issues.apache.org/jira/browse/IGNITE-16547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494394#comment-17494394
 ] 

Evgeny Stanilovsky commented on IGNITE-16547:
-

[~korlov] i complete with all of your comments, plz take a look.

> Sql. Adopt MERGE command.
> -
>
> Key: IGNITE-16547
> URL: https://issues.apache.org/jira/browse/IGNITE-16547
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
>  Labels: calcite3-required, ignite-3
> Fix For: 3.0.0-alpha5
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> MERGE command was implemented 
> [here|https://issues.apache.org/jira/browse/IGNITE-12695]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-16462) .NET: Thin client: implement heartbeats



[ 
https://issues.apache.org/jira/browse/IGNITE-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494393#comment-17494393
 ] 

Pavel Tupitsyn commented on IGNITE-16462:
-

Merged to master: 800997f7b3c7599469089b27249e947a71b3c6ba

> .NET: Thin client: implement heartbeats
> ---
>
> Key: IGNITE-16462
> URL: https://issues.apache.org/jira/browse/IGNITE-16462
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: iep-83
> Fix For: 2.13
>
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> Implement heartbeats as described in [IEP-83 Thin Client 
> Keepalive|https://cwiki.apache.org/confluence/display/IGNITE/IEP-83+Thin+Client+Keepalive].



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16569) Fix several ducktests



 [ 
https://issues.apache.org/jira/browse/IGNITE-16569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Korotkov updated IGNITE-16569:
-
Description: 
There are several problems in ducktest which should be fixed to let them run in 
different configurations:
 # The *PersistenceUpgradeTest* fails if SSL is enabled via the --globals 
options. The immediate reason is that control.sh doesn't support the SSL 
options (like key_store_path) in the 2.7.6 version which is the starting point 
for the test incremental migrations of the PDS. Solution is to ignore test if 
SSL is enabled.
 # The *AuthenticationTests* uses the hardcoded username and password and 
ignores ones passed via the globals.

  was:
There are several problems in ducktest which should be fixed to let them run in 
different configurations:
 # The *PersistenceUpgradeTest* fails if SSL is enabled via the --globals 
options. The immediate reason is that control.sh doesn't support the SSL 
options (like key_store_path) in the 2.7.6 version which is the starting point 
for the test incremental migrations of the PDS.
 # The *AuthenticationTests* uses the hardcoded username and password and 
ignores ones passed via the globals


> Fix several ducktests
> -
>
> Key: IGNITE-16569
> URL: https://issues.apache.org/jira/browse/IGNITE-16569
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
>  Labels: ducktests
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are several problems in ducktest which should be fixed to let them run 
> in different configurations:
>  # The *PersistenceUpgradeTest* fails if SSL is enabled via the --globals 
> options. The immediate reason is that control.sh doesn't support the SSL 
> options (like key_store_path) in the 2.7.6 version which is the starting 
> point for the test incremental migrations of the PDS. Solution is to ignore 
> test if SSL is enabled.
>  # The *AuthenticationTests* uses the hardcoded username and password and 
> ignores ones passed via the globals.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16569) Fix several ducktests



 [ 
https://issues.apache.org/jira/browse/IGNITE-16569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Korotkov updated IGNITE-16569:
-
Description: 
There are several problems in ducktest which should be fixed to let them run in 
different configurations:
 # The *PersistenceUpgradeTest* fails if SSL is enabled via the --globals 
options. The immediate reason is that control.sh doesn't support the SSL 
options (like key_store_path) in the 2.7.6 version which is the starting point 
for the test incremental migrations of the PDS.
 # The *AuthenticationTests* uses the hardcoded username and password and 
ignores ones passed via the globals

  was:
The PersistenceUpgradeTest fails if SSL is enabled via the --globals options.

The immediate reason is that control.sh doesn't support the SSL options (like 
key_store_path) in the 2.7.6 version which is the starting point for the test 
incremental migrations of the PDS .


> Fix several ducktests
> -
>
> Key: IGNITE-16569
> URL: https://issues.apache.org/jira/browse/IGNITE-16569
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
>  Labels: ducktests
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are several problems in ducktest which should be fixed to let them run 
> in different configurations:
>  # The *PersistenceUpgradeTest* fails if SSL is enabled via the --globals 
> options. The immediate reason is that control.sh doesn't support the SSL 
> options (like key_store_path) in the 2.7.6 version which is the starting 
> point for the test incremental migrations of the PDS.
>  # The *AuthenticationTests* uses the hardcoded username and password and 
> ignores ones passed via the globals



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16569) Fix several ducktests



 [ 
https://issues.apache.org/jira/browse/IGNITE-16569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Korotkov updated IGNITE-16569:
-
Summary: Fix several ducktests  (was: PersistenceUpgradeTest ducktest fails 
if SSL is enabled)

> Fix several ducktests
> -
>
> Key: IGNITE-16569
> URL: https://issues.apache.org/jira/browse/IGNITE-16569
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
>  Labels: ducktests
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The PersistenceUpgradeTest fails if SSL is enabled via the --globals options.
> The immediate reason is that control.sh doesn't support the SSL options (like 
> key_store_path) in the 2.7.6 version which is the starting point for the test 
> incremental migrations of the PDS .



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-16462) .NET: Thin client: implement heartbeats

2022-02-17 Thread Ignite TC Bot (Jira)



[ 
https://issues.apache.org/jira/browse/IGNITE-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494381#comment-17494381
 ] 

Ignite TC Bot commented on IGNITE-16462:


{panel:title=Branch: [pull/9817/head] Base: [master] : Possible Blockers 
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=6413451]]

{color:#d04437}PDS (Indexing){color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=6413453]]
* IgnitePdsWithIndexingCoreTestSuite: 
IgnitePdsBinaryMetadataAsyncWritingTest.testPutRequestFromServerCompletesIfMetadataWriteHangOnBackup
 - Test has low fail rate in base branch 0,0% and is not flaky

{panel}
{panel:title=Branch: [pull/9817/head] Base: [master] : New Tests 
(12)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Core Linux){color} [[tests 
6|https://ci.ignite.apache.org/viewLog.html?buildId=6421213]]
* {color:#013220}dll: 
ClientHeartbeatTest.TestServerDisconnectsIdleClientWithoutHeartbeats - 
PASSED{color}
* {color:#013220}dll: 
ClientHeartbeatTest.TestServerDoesNotDisconnectIdleClientWithHeartbeats - 
PASSED{color}
* {color:#013220}dll: 
ClientHeartbeatTest.TestCustomHeartbeatIntervalOverridesCalculatedFromIdleTimeout
 - PASSED{color}
* {color:#013220}dll: 
ClientHeartbeatTest.TestDefaultZeroIdleTimeoutUsesConfiguredHeartbeatInterval - 
PASSED{color}
* {color:#013220}dll: 
ClientHeartbeatTest.TestZeroOrNegativeHeartbeatIntervalThrows - PASSED{color}
* {color:#013220}dll: 
ClientHeartbeatTest.TestCustomHeartbeatIntervalLongerThanRecommendedDoesNotOverrideCalculatedFromIdleTimeout
 - PASSED{color}

{color:#8b}Platform .NET (Windows){color} [[tests 
6|https://ci.ignite.apache.org/viewLog.html?buildId=6421355]]
* {color:#013220}exe: 
ClientHeartbeatTest.TestServerDisconnectsIdleClientWithoutHeartbeats - 
PASSED{color}
* {color:#013220}exe: 
ClientHeartbeatTest.TestServerDoesNotDisconnectIdleClientWithHeartbeats - 
PASSED{color}
* {color:#013220}exe: 
ClientHeartbeatTest.TestCustomHeartbeatIntervalLongerThanRecommendedDoesNotOverrideCalculatedFromIdleTimeout
 - PASSED{color}
* {color:#013220}exe: 
ClientHeartbeatTest.TestCustomHeartbeatIntervalOverridesCalculatedFromIdleTimeout
 - PASSED{color}
* {color:#013220}exe: 
ClientHeartbeatTest.TestDefaultZeroIdleTimeoutUsesConfiguredHeartbeatInterval - 
PASSED{color}
* {color:#013220}exe: 
ClientHeartbeatTest.TestZeroOrNegativeHeartbeatIntervalThrows - PASSED{color}

{panel}
[TeamCity *--> Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6413382&buildTypeId=IgniteTests24Java8_RunAll]

> .NET: Thin client: implement heartbeats
> ---
>
> Key: IGNITE-16462
> URL: https://issues.apache.org/jira/browse/IGNITE-16462
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: iep-83
> Fix For: 2.13
>
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> Implement heartbeats as described in [IEP-83 Thin Client 
> Keepalive|https://cwiki.apache.org/confluence/display/IGNITE/IEP-83+Thin+Client+Keepalive].



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.



[ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481846#comment-17481846
 ] 

Pavel Pereslegin edited comment on IGNITE-15450 at 2/17/22, 6:01 PM:
-

The final solution is to add a "--sync" option to wait for the entire operation 
to complete.

*Create*
{noformat}
  Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--sync]

Parameters:
  snapshot_name  - Snapshot name.
  sync   - Run the operation synchronously, the command will wait 
for the entire operation to complete. Otherwise, it will be performed in the 
background, and the command will immediately return control.
{noformat}

*Restore*
{noformat}
  Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name --start [--groups 
group1,...groupN] [--sync]

Parameters:
  snapshot_name - Snapshot name.
  group1,...groupN  - Cache group names.
  sync  - Run the operation synchronously, the command will 
wait for the entire operation to complete. Otherwise, it will be performed in 
the background, and the command will immediately return control.
{noformat}

Example of an error output in the console if cache exists:
{noformat}
Command [SNAPSHOT] started
Arguments: --snapshot restore snapshot_02052020 --start --sync --yes 

Unable to restore cache group - directory is not empty. Cache group should be 
destroyed manually before perform restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest1/cache-test-cache]
Command [SNAPSHOT] finished with code: 4
Error stack trace:
class org.apache.ignite.IgniteException: Unable to restore cache group - 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest1/cache-test-cache]
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1114)
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.convertException(IgniteFutureImpl.java:186)
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:155)
at 
org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask$VisorSnapshotStartRestoreJob.run(VisorSnapshotRestoreTask.java:70)
at 
org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask$VisorSnapshotStartRestoreJob.run(VisorSnapshotRestoreTask.java:52)
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:7334)
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:590)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:570)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:223)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:162)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest0(GridRestProcessor.java:317)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:303)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.access$000(GridRestProcessor.java:108)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:189)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at 
java.util.concurrent.ThreadPoolExecu

[jira] [Comment Edited] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.



[ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481846#comment-17481846
 ] 

Pavel Pereslegin edited comment on IGNITE-15450 at 2/17/22, 6:01 PM:
-

The final solution is to add a "--sync" option to wait for the entire operation 
to complete.

*Create*
{noformat}
  Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--sync]

Parameters:
  snapshot_name  - Snapshot name.
  sync   - Run the operation synchronously, the command will wait 
for the entire operation to complete. Otherwise, it will be performed in the 
background, and the command will immediately return control.
{noformat}

*Restore*
{noformat}
  Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name --start [--groups 
group1,...groupN] [--sync]

Parameters:
  snapshot_name - Snapshot name.
  group1,...groupN  - Cache group names.
  sync  - Run the operation synchronously, the command will 
wait for the entire operation to complete. Otherwise, it will be performed in 
the background, and the command will immediately return control.
{noformat}


Example of an *error output* in the console if cache exists:
{noformat}
Command [SNAPSHOT] started
Arguments: --snapshot restore snapshot_02052020 --start --sync --yes 

Unable to restore cache group - directory is not empty. Cache group should be 
destroyed manually before perform restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest1/cache-test-cache]
Command [SNAPSHOT] finished with code: 4
Error stack trace:
class org.apache.ignite.IgniteException: Unable to restore cache group - 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest1/cache-test-cache]
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1114)
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.convertException(IgniteFutureImpl.java:186)
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:155)
at 
org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask$VisorSnapshotStartRestoreJob.run(VisorSnapshotRestoreTask.java:70)
at 
org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask$VisorSnapshotStartRestoreJob.run(VisorSnapshotRestoreTask.java:52)
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:7334)
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:590)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:570)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:223)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:162)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest0(GridRestProcessor.java:317)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:303)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.access$000(GridRestProcessor.java:108)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:189)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at 
java.util.concurrent.ThreadPoolEx

[jira] [Updated] (IGNITE-16579) Cluster deactivation can get stuck



 [ 
https://issues.apache.org/jira/browse/IGNITE-16579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-16579:
-
Priority: Blocker  (was: Critical)

> Cluster deactivation can get stuck
> --
>
> Key: IGNITE-16579
> URL: https://issues.apache.org/jira/browse/IGNITE-16579
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Blocker
>
> Cluster deactivation that is executed via Java API or control utility without 
> --force flag can get stuck in the case when the cluster contains persistent 
> caches and client nodes that do not provide DataStorageConfiguration. In that 
> case, client nodes can erroneously consider that all caches are in-memory and 
> therefore will not start the corresponding exchange process at all, unlike 
> server nodes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (IGNITE-16579) Cluster deactivation can get stuck

Vyacheslav Koptilin created IGNITE-16579:


 Summary: Cluster deactivation can get stuck
 Key: IGNITE-16579
 URL: https://issues.apache.org/jira/browse/IGNITE-16579
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.12
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin


Cluster deactivation that is executed via Java API or control utility without 
--force flag can get stuck in the case when the cluster contains persistent 
caches and client nodes that do not provide DataStorageConfiguration. In that 
case, client nodes can erroneously consider that all caches are in-memory and 
therefore will not start the corresponding exchange process at all, unlike 
server nodes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16579) Cluster deactivation can get stuck



 [ 
https://issues.apache.org/jira/browse/IGNITE-16579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-16579:
-
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Cluster deactivation can get stuck
> --
>
> Key: IGNITE-16579
> URL: https://issues.apache.org/jira/browse/IGNITE-16579
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Critical
>
> Cluster deactivation that is executed via Java API or control utility without 
> --force flag can get stuck in the case when the cluster contains persistent 
> caches and client nodes that do not provide DataStorageConfiguration. In that 
> case, client nodes can erroneously consider that all caches are in-memory and 
> therefore will not start the corresponding exchange process at all, unlike 
> server nodes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16579) Cluster deactivation can get stuck



 [ 
https://issues.apache.org/jira/browse/IGNITE-16579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-16579:
-
Priority: Critical  (was: Major)

> Cluster deactivation can get stuck
> --
>
> Key: IGNITE-16579
> URL: https://issues.apache.org/jira/browse/IGNITE-16579
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Critical
>
> Cluster deactivation that is executed via Java API or control utility without 
> --force flag can get stuck in the case when the cluster contains persistent 
> caches and client nodes that do not provide DataStorageConfiguration. In that 
> case, client nodes can erroneously consider that all caches are in-memory and 
> therefore will not start the corresponding exchange process at all, unlike 
> server nodes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (IGNITE-16578) Sql. Implement validation of inserts with composite PK and partially determined PK consistent columns.

Evgeny Stanilovsky created IGNITE-16578:
---

 Summary: Sql. Implement validation of inserts with composite PK 
and partially determined PK consistent columns.
 Key: IGNITE-16578
 URL: https://issues.apache.org/jira/browse/IGNITE-16578
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Evgeny Stanilovsky
Assignee: Evgeny Stanilovsky
 Fix For: 3.0.0-alpha5


Partial PK update possibilities:

{noformat}
CREATE TABLE test1 (k1 int, k2 int, a int, b int, CONSTRAINT PK PRIMARY KEY 
(k1, k2));
INSERT INTO test1 (k2, b) VALUES (1, 1); <-- need to be rejected

CREATE TABLE test2 (k1 int DEFAULT 0, k2 int, a int, b int, CONSTRAINT PK 
PRIMARY KEY (k1, k2));
INSERT INTO test1 (k2, b) VALUES (1, 1);  <-- it`s all ok there.
{noformat}




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-16493) Calcite engine. Decorrelation after subquery rewrite

2022-02-17 Thread Aleksey Plekhanov (Jira)



[ 
https://issues.apache.org/jira/browse/IGNITE-16493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494024#comment-17494024
 ] 

Aleksey Plekhanov commented on IGNITE-16493:


Looks like there are some problems in decorrelation procedure in Calcite, for 
example, query:
{noformat}
CREATE TABLE integers(i INTEGER) WITH TEMPLATE=REPLICATED;
INSERT INTO integers VALUES (1), (2), (3), (NULL);
SELECT i, EXISTS(SELECT i FROM integers WHERE i IS NULL OR i>i1.i*10) FROM 
integers i1;{noformat}
Produces plan like:
{noformat}
IgniteProject(I=[$2], EXPR$1=[IS NOT NULL($5)]): rowcount = 4.15, cumulative 
cost = IgniteCost [rowCount=37.15, cpu=73.15, memory=28.0, io=0.0, 
network=0.0], id = 3318
  IgniteNestedLoopJoin(condition=[=($3, $4)], joinType=[left], 
variablesSet=[[]]): rowcount = 4.15, cumulative cost = IgniteCost 
[rowCount=33.0, cpu=69.0, memory=28.0, io=0.0, network=0.0], id = 3317
    IgniteTableScan(table=[[PUBLIC, INTEGERS]], projects=[[$t0, $t1, $t2, 
*($t2, 10)]], requiredColumns=[{0, 1, 2}]): rowcount = 4.0, cumulative cost = 
IgniteCost [rowCount=4.0, cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 1048
    IgniteProject($f3=[$0], $f1=[true]): rowcount = 1.0, cumulative cost = 
IgniteCost [rowCount=25.0, cpu=49.0, memory=20.0, io=0.0, network=0.0], id = 
3316
      IgniteSingleHashAggregate(group=[{0}]): rowcount = 1.0, cumulative cost = 
IgniteCost [rowCount=24.0, cpu=48.0, memory=20.0, io=0.0, network=0.0], id = 
3315
        IgniteProject($f3=[$3]): rowcount = 2.0, cumulative cost = IgniteCost 
[rowCount=22.0, cpu=46.0, memory=16.0, io=0.0, network=0.0], id = 3314
          IgniteNestedLoopJoin(condition=[OR(IS NULL($2), >($2, $3))], 
joinType=[inner], variablesSet=[[]]): rowcount = 2.0, cumulative cost = 
IgniteCost [rowCount=20.0, cpu=44.0, memory=16.0, io=0.0, network=0.0], id = 
3313
            IgniteTableScan(table=[[PUBLIC, INTEGERS]]): rowcount = 4.0, 
cumulative cost = IgniteCost [rowCount=4.0, cpu=4.0, memory=0.0, io=0.0, 
network=0.0], id = 269
            IgniteSingleHashAggregate(group=[{0}]): rowcount = 2.0, cumulative 
cost = IgniteCost [rowCount=8.0, cpu=8.0, memory=8.0, io=0.0, network=0.0], id 
= 3312
              IgniteTableScan(table=[[PUBLIC, INTEGERS]], projects=[[*($t0, 
10)]], requiredColumns=[{2}]): rowcount = 4.0, cumulative cost = IgniteCost 
[rowCount=4.0, cpu=4.0, memory=0.0, io=0.0, network=0.0], id = 282{noformat}
In this plan {{IgniteNestedLoopJoin(condition=[=($3, $4)], joinType=[left])}} 
filter out {{null}} values derived from the right hand and return wrong result 
(\{{(null, false)}} instead of {{{}(null, true){}}})

 

> Calcite engine. Decorrelation after subquery rewrite
> 
>
> Key: IGNITE-16493
> URL: https://issues.apache.org/jira/browse/IGNITE-16493
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Priority: Major
>  Labels: calcite, calcite2-required, calcite3-required
>
> Currently decorrelation is performed in {{SqlToRelConverter}}, but after this 
> {{PlannerPhase.HEP_DECORRELATE}} planning phase is executed (which actually 
> rewrites subqueries into correlates, but doesn't perform decorrelation). In 
> some cases, other types of join can cost less than correlated nested loop 
> join, so we can try to decorrelate the query plan again after 
> {{PlannerPhase.HEP_DECORRELATE}} phase (call 
> {{RelDecorrelator.decorrelateQuery}}).
> {{PlannerPhase.HEP_DECORRELATE}} should be also renamed to something like 
> "HEP_REWRITE_SUBQUERY".



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16577) MultiInvokeCommand must extend WriteCommand



 [ 
https://issues.apache.org/jira/browse/IGNITE-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-16577:
-
Fix Version/s: 3.0.0-alpha5

> MultiInvokeCommand must extend WriteCommand
> ---
>
> Key: IGNITE-16577
> URL: https://issues.apache.org/jira/browse/IGNITE-16577
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Blocker
>  Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16577) MultiInvokeCommand must extend WriteCommand



 [ 
https://issues.apache.org/jira/browse/IGNITE-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-16577:
-
Description: _MultiInvokeCommand _must extend _WriteCommand _instead of 
_Command_

> MultiInvokeCommand must extend WriteCommand
> ---
>
> Key: IGNITE-16577
> URL: https://issues.apache.org/jira/browse/IGNITE-16577
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Blocker
>  Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> _MultiInvokeCommand _must extend _WriteCommand _instead of _Command_



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16577) MultiInvokeCommand must extend WriteCommand



 [ 
https://issues.apache.org/jira/browse/IGNITE-16577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-16577:
-
Description: _MultiInvokeCommand_ must extend _WriteCommand_ instead of 
_Command_  (was: _MultiInvokeCommand _must extend _WriteCommand _instead of 
_Command_)

> MultiInvokeCommand must extend WriteCommand
> ---
>
> Key: IGNITE-16577
> URL: https://issues.apache.org/jira/browse/IGNITE-16577
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Blocker
>  Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> _MultiInvokeCommand_ must extend _WriteCommand_ instead of _Command_



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (IGNITE-16577) MultiInvokeCommand must extend WriteCommand

Vyacheslav Koptilin created IGNITE-16577:


 Summary: MultiInvokeCommand must extend WriteCommand
 Key: IGNITE-16577
 URL: https://issues.apache.org/jira/browse/IGNITE-16577
 Project: Ignite
  Issue Type: Bug
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin






--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-16567) Remove GSON dependency

2022-02-17 Thread Kirill Gusakov (Jira)



[ 
https://issues.apache.org/jira/browse/IGNITE-16567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493979#comment-17493979
 ] 

Kirill Gusakov commented on IGNITE-16567:
-

LGTM

> Remove GSON dependency
> --
>
> Key: IGNITE-16567
> URL: https://issues.apache.org/jira/browse/IGNITE-16567
> Project: Ignite
>  Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
>  Labels: ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Ignite 3 has both GSON and Jackson as dependencies, which serve the same 
> purpose. Since more code uses Jackson, it is proposed to remove GSON.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16266) Add unique id for indexes

2022-02-17 Thread Andrey Mashenkov (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-16266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Mashenkov updated IGNITE-16266:
--
Component/s: sql

> Add unique id for indexes
> -
>
> Key: IGNITE-16266
> URL: https://issues.apache.org/jira/browse/IGNITE-16266
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3, sql
> Fix For: 3.0.0-alpha5
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As of now we address to index by name even internally. It could lead read 
> another version of index wchi was dropped and created with another set of 
> column . Let's introduce unique id (as we already have for tables) which 
> could be accessed only internally and use as identifier of indexes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16266) Add unique id for indexes

2022-02-17 Thread Andrey Mashenkov (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-16266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Mashenkov updated IGNITE-16266:
--
Fix Version/s: 3.0.0-alpha5

> Add unique id for indexes
> -
>
> Key: IGNITE-16266
> URL: https://issues.apache.org/jira/browse/IGNITE-16266
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yury Gerzhedovich
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3, sql
> Fix For: 3.0.0-alpha5
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As of now we address to index by name even internally. It could lead read 
> another version of index wchi was dropped and created with another set of 
> column . Let's introduce unique id (as we already have for tables) which 
> could be accessed only internally and use as identifier of indexes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16266) Add unique id for indexes

2022-02-17 Thread Andrey Mashenkov (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-16266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Mashenkov updated IGNITE-16266:
--
Summary: Add unique id for indexes  (was: Indexes unique id)

> Add unique id for indexes
> -
>
> Key: IGNITE-16266
> URL: https://issues.apache.org/jira/browse/IGNITE-16266
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yury Gerzhedovich
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3, sql
>
> As of now we address to index by name even internally. It could lead read 
> another version of index wchi was dropped and created with another set of 
> column . Let's introduce unique id (as we already have for tables) which 
> could be accessed only internally and use as identifier of indexes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-15554) Add logic for assignment recalculation in case of replicas changes

2022-02-17 Thread Kirill Gusakov (Jira)



[ 
https://issues.apache.org/jira/browse/IGNITE-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493969#comment-17493969
 ] 

Kirill Gusakov commented on IGNITE-15554:
-

LGTM

> Add logic for assignment recalculation in case of replicas changes
> --
>
> Key: IGNITE-15554
> URL: https://issues.apache.org/jira/browse/IGNITE-15554
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexander Lapin
>Assignee: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
>
> We need to provide the trigger when the number of partition replicas changes. 
> At the moment, replicas is a table configuration. But at the same time, 
> rebalance trigger mechanism assumes that changes triggered by metastore’s key 
> change (IGNITE-16063). So, we need provide the bridge between configuration 
> changes and metastore key, it can be:
> separate metastore key, which duplicate the field from configuration and 
> mirror all configuration changes
> any better ways here…



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-16569) PersistenceUpgradeTest ducktest fails if SSL is enabled



[ 
https://issues.apache.org/jira/browse/IGNITE-16569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493959#comment-17493959
 ] 

Sergey Korotkov commented on IGNITE-16569:
--

[~northdragon] [~ivandasch] would you please review

> PersistenceUpgradeTest ducktest fails if SSL is enabled
> ---
>
> Key: IGNITE-16569
> URL: https://issues.apache.org/jira/browse/IGNITE-16569
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
>  Labels: ducktests
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The PersistenceUpgradeTest fails if SSL is enabled via the --globals options.
> The immediate reason is that control.sh doesn't support the SSL options (like 
> key_store_path) in the 2.7.6 version which is the starting point for the test 
> incremental migrations of the PDS .



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (IGNITE-13389) Append additional settings to obtain full stack trace on thin client side if an error occurs on server side.



[ 
https://issues.apache.org/jira/browse/IGNITE-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493949#comment-17493949
 ] 

Pavel Tupitsyn edited comment on IGNITE-13389 at 2/17/22, 1:54 PM:
---

Merged to master: 2311878802b57a50a07b842447fa86f9dbc059a7

[~RyzhovSV] thanks for driving this to completion!


was (Author: ptupitsyn):
Merged to master: 2311878802b57a50a07b842447fa86f9dbc059a7

> Append additional settings to obtain full stack trace on thin client side if 
> an error occurs on server side.
> 
>
> Key: IGNITE-13389
> URL: https://issues.apache.org/jira/browse/IGNITE-13389
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 2.8.1
>Reporter: Evgeny Stanilovsky
>Assignee: Sergei Ryzhov
>Priority: Major
>  Labels: ise
> Fix For: 2.13
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> Some server side errors have deeply nested _suppressed_ or _caused by_ errors 
> which contains informative messages for further problem recognition. Possible 
> such mechanism need to be disabled on production environment. Example of non 
> informative error on client side:
> {noformat}
> org.apache.ignite.internal.client.thin.ClientServerError: Ignite failed to 
> process request [1]: Failed to update keys (retry update if possible).: [1] 
> (server status code [1])
> {noformat}
> but full stack holds the root case:
> {noformat}
> Caused by: class 
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
>  Failed to update keys (retry update if possible).: [1]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2567)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2544)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1316)
>   ... 13 more
>   Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
> update keys.
>   ... 23 more
>   Suppressed: class org.apache.ignite.IgniteCheckedException: 
> Runtime failure on search row: SearchRow
>   ... 25 more
>   Caused by: class org.apache.ignite.IgniteCheckedException: 
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to 
> org.apache.ignite.client.IgniteBinaryTest$ThinBinaryValue <-- here !!!
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6379)
>   ... 30 more
> {noformat}
> looks like it would be useful to have additional setting in 
> ThinClientConfiguration#showFullStackOnClientSide configured both as direct 
> setting and through JMX (ClientProcessorMXBean#showFullStackOnClientSide).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-13389) Append additional settings to obtain full stack trace on thin client side if an error occurs on server side.



 [ 
https://issues.apache.org/jira/browse/IGNITE-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-13389:

Release Note: Thin client: added an option to append server exception stack 
trace to the error messages

> Append additional settings to obtain full stack trace on thin client side if 
> an error occurs on server side.
> 
>
> Key: IGNITE-13389
> URL: https://issues.apache.org/jira/browse/IGNITE-13389
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 2.8.1
>Reporter: Evgeny Stanilovsky
>Assignee: Sergei Ryzhov
>Priority: Major
>  Labels: ise
> Fix For: 2.13
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> Some server side errors have deeply nested _suppressed_ or _caused by_ errors 
> which contains informative messages for further problem recognition. Possible 
> such mechanism need to be disabled on production environment. Example of non 
> informative error on client side:
> {noformat}
> org.apache.ignite.internal.client.thin.ClientServerError: Ignite failed to 
> process request [1]: Failed to update keys (retry update if possible).: [1] 
> (server status code [1])
> {noformat}
> but full stack holds the root case:
> {noformat}
> Caused by: class 
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
>  Failed to update keys (retry update if possible).: [1]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2567)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2544)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1316)
>   ... 13 more
>   Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
> update keys.
>   ... 23 more
>   Suppressed: class org.apache.ignite.IgniteCheckedException: 
> Runtime failure on search row: SearchRow
>   ... 25 more
>   Caused by: class org.apache.ignite.IgniteCheckedException: 
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to 
> org.apache.ignite.client.IgniteBinaryTest$ThinBinaryValue <-- here !!!
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6379)
>   ... 30 more
> {noformat}
> looks like it would be useful to have additional setting in 
> ThinClientConfiguration#showFullStackOnClientSide configured both as direct 
> setting and through JMX (ClientProcessorMXBean#showFullStackOnClientSide).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-13389) Append additional settings to obtain full stack trace on thin client side if an error occurs on server side.



[ 
https://issues.apache.org/jira/browse/IGNITE-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493949#comment-17493949
 ] 

Pavel Tupitsyn commented on IGNITE-13389:
-

Merged to master: 2311878802b57a50a07b842447fa86f9dbc059a7

> Append additional settings to obtain full stack trace on thin client side if 
> an error occurs on server side.
> 
>
> Key: IGNITE-13389
> URL: https://issues.apache.org/jira/browse/IGNITE-13389
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 2.8.1
>Reporter: Evgeny Stanilovsky
>Assignee: Sergei Ryzhov
>Priority: Major
>  Labels: ise
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> Some server side errors have deeply nested _suppressed_ or _caused by_ errors 
> which contains informative messages for further problem recognition. Possible 
> such mechanism need to be disabled on production environment. Example of non 
> informative error on client side:
> {noformat}
> org.apache.ignite.internal.client.thin.ClientServerError: Ignite failed to 
> process request [1]: Failed to update keys (retry update if possible).: [1] 
> (server status code [1])
> {noformat}
> but full stack holds the root case:
> {noformat}
> Caused by: class 
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
>  Failed to update keys (retry update if possible).: [1]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2567)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2544)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1316)
>   ... 13 more
>   Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
> update keys.
>   ... 23 more
>   Suppressed: class org.apache.ignite.IgniteCheckedException: 
> Runtime failure on search row: SearchRow
>   ... 25 more
>   Caused by: class org.apache.ignite.IgniteCheckedException: 
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to 
> org.apache.ignite.client.IgniteBinaryTest$ThinBinaryValue <-- here !!!
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6379)
>   ... 30 more
> {noformat}
> looks like it would be useful to have additional setting in 
> ThinClientConfiguration#showFullStackOnClientSide configured both as direct 
> setting and through JMX (ClientProcessorMXBean#showFullStackOnClientSide).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-15948) Basic class structure change handling



 [ 
https://issues.apache.org/jira/browse/IGNITE-15948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-15948:
---
Summary: Basic class structure change handling  (was: Implement class 
structure change handling)

> Basic class structure change handling
> -
>
> Key: IGNITE-15948
> URL: https://issues.apache.org/jira/browse/IGNITE-15948
> Project: Ignite
>  Issue Type: Task
>Reporter: Semyon Danilov
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> User objects may change their class definition (e.g. class can lose its final 
> modifier, can become private, or in other means inaccessible). Ignite should 
> make the best effort at merging different versions of descriptors and parsing 
> objects.
> See 
> https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md#handling-class-structure-changes



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.



[ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481846#comment-17481846
 ] 

Pavel Pereslegin edited comment on IGNITE-15450 at 2/17/22, 12:48 PM:
--

The final solution is to add a "--sync" option to wait for the entire operation 
to complete.

*Create*
{noformat}
  Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--sync]

Parameters:
  snapshot_name  - Snapshot name.
  sync   - Run the operation synchronously, the command will wait 
for the entire operation to complete. Otherwise, it will be performed in the 
background, and the command will immediately return control.
{noformat}

*Restore*
{noformat}
  Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name --start [--groups 
group1,...groupN] [--sync]

Parameters:
  snapshot_name - Snapshot name.
  group1,...groupN  - Cache group names.
  sync  - Run the operation synchronously, the command will 
wait for the entire operation to complete. Otherwise, it will be performed in 
the background, and the command will immediately return control.
{noformat}

Example of error message if cache exists: 
_class org.apache.ignite.IgniteException: Unable to restore cache group - 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest0/cache-test-cache]]_

Full console output for this type of error:
{noformat}
Command [SNAPSHOT] started
Arguments: --snapshot restore snapshot_02052020 --start --sync --yes 

Failed to perform operation.
Failed to reduce job results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask@1fd7cb69,
 err=class org.apache.ignite.IgniteException: Unable to restore cache group - 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest1/cache-test-cache]],
 trace=class org.apache.ignite.IgniteCheckedException: Failed to reduce job 
results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask@1fd7cb69,
 err=class org.apache.ignite.IgniteException: Unable to restore cache group - 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest1/cache-test-cache]]
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7836)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:172)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:259)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:253)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:253)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:162)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest0(GridRestProcessor.java:317)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:303)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.access$000(GridRestProcessor.java:108)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:189)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.compute.ComputeUserUndeclaredException: 
Failed to reduce job results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask@1fd7cb69,
 err=class org.apache.ignite.IgniteException: Unab

[jira] [Comment Edited] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.



[ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481846#comment-17481846
 ] 

Pavel Pereslegin edited comment on IGNITE-15450 at 2/17/22, 12:47 PM:
--

The final solution is to add a "--sync" option to wait for the entire operation 
to complete.

*Create*
{noformat}
  Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--sync]

Parameters:
  snapshot_name  - Snapshot name.
  sync   - Run the operation synchronously, the command will wait 
for the entire operation to complete. Otherwise, it will be performed in the 
background, and the command will immediately return control.
{noformat}

*Restore*
{noformat}
  Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name --start [--groups 
group1,...groupN] [--sync]

Parameters:
  snapshot_name - Snapshot name.
  group1,...groupN  - Cache group names.
  sync  - Run the operation synchronously, the command will 
wait for the entire operation to complete. Otherwise, it will be performed in 
the background, and the command will immediately return control.
{noformat}

Example of error message if cache exists: 
_class org.apache.ignite.IgniteException: Unable to restore cache group - 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest0/cache-test-cache]]_

Full console output:
{noformat}
Command [SNAPSHOT] started
Arguments: --snapshot restore snapshot_02052020 --start --sync --yes 

Failed to perform operation.
Failed to reduce job results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask@1fd7cb69,
 err=class org.apache.ignite.IgniteException: Unable to restore cache group - 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest1/cache-test-cache]],
 trace=class org.apache.ignite.IgniteCheckedException: Failed to reduce job 
results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask@1fd7cb69,
 err=class org.apache.ignite.IgniteException: Unable to restore cache group - 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest1/cache-test-cache]]
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7836)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:172)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:259)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:253)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:253)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:162)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest0(GridRestProcessor.java:317)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:303)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.access$000(GridRestProcessor.java:108)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:189)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.compute.ComputeUserUndeclaredException: 
Failed to reduce job results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask@1fd7cb69,
 err=class org.apache.ignite.IgniteException: Unable to restore cache gro

[jira] [Comment Edited] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.



[ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481846#comment-17481846
 ] 

Pavel Pereslegin edited comment on IGNITE-15450 at 2/17/22, 12:44 PM:
--

The final solution is to add a "--sync" option to wait for the entire operation 
to complete.

*Create*
{noformat}
  Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--sync]

Parameters:
  snapshot_name  - Snapshot name.
  sync   - Run the operation synchronously, the command will wait 
for the entire operation to complete. Otherwise, it will be performed in the 
background, and the command will immediately return control.
{noformat}

*Restore*
{noformat}
  Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name --start [--groups 
group1,...groupN] [--sync]

Parameters:
  snapshot_name - Snapshot name.
  group1,...groupN  - Cache group names.
  sync  - Run the operation synchronously, the command will 
wait for the entire operation to complete. Otherwise, it will be performed in 
the background, and the command will immediately return control.
{noformat}

Example of error message if cache exists: 
_class org.apache.ignite.IgniteException: Unable to restore cache group: 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest0/cache-test-cache]]_

Full console output:
{noformat}
Command [SNAPSHOT] started
Arguments: --snapshot restore snapshot_02052020 --start --sync --yes 

Failed to perform operation.
Failed to reduce job results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask@2286ae67,
 err=class org.apache.ignite.IgniteException: Unable to restore cache group: 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest0/cache-test-cache]],
 trace=class org.apache.ignite.IgniteCheckedException: Failed to reduce job 
results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask@2286ae67,
 err=class org.apache.ignite.IgniteException: Unable to restore cache group: 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest0/cache-test-cache]]
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7836)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:172)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:259)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:253)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener$$$capture(GridFutureAdapter.java:399)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:253)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:162)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest0(GridRestProcessor.java:317)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:303)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.access$000(GridRestProcessor.java:108)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:189)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.compute.ComputeUserUndeclaredException: 
Failed to reduce job results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.sn

[jira] [Updated] (IGNITE-16561) ItMixedQueriesTest.testSequentialInserts is flaky



 [ 
https://issues.apache.org/jira/browse/IGNITE-16561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-16561:
---
Component/s: (was: sql)

> ItMixedQueriesTest.testSequentialInserts is flaky
> -
>
> Key: IGNITE-16561
> URL: https://issues.apache.org/jira/browse/IGNITE-16561
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Blocker
>  Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_1651.log, 
> _Integration_Tests_Module_Runner_1653.log
>
>
> {{ItMixedQueriesTest#testSequentialInserts}} is flaky. It fails with a 
> different {{Unexpected exception}} on a different runs: 
> {noformat}
> 2022-02-15 12:07:09:954 +0300 
> [WARNING][%ItMixedQueriesTest_null_0%sqlExec-2][QueryTaskExecutorImpl] 
> Uncaught exception
> class org.apache.ignite.lang.IgniteInternalException: Unexpected exception
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:313)
>   at 
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:75)
>   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:834)
> Caused by: java.util.concurrent.CompletionException: class 
> org.apache.ignite.tx.TransactionException: 
> java.util.concurrent.TimeoutException
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
>   at 
> java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
>   at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
>   at 
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
>   at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
>   at 
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
>   at 
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by: class org.apache.ignite.tx.TransactionException: 
> java.util.concurrent.TimeoutException
>   at 
> org.apache.ignite.internal.tx.impl.TxManagerImpl.lambda$finishRemote$3(TxManagerImpl.java:260)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
>   ... 9 more
> {noformat}
> {noformat}
> 2022-02-15 12:31:28:310 +0300 
> [WARNING][%ItMixedQueriesTest_null_0%sqlExec-0][QueryTaskExecutorImpl] 
> Uncaught exception
>   class org.apache.ignite.lang.IgniteInternalException: Unexpected 
> exception
> at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:313)
> at 
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:75)
> 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:834)
>   Caused by: class org.apache.ignite.lang.IgniteInternalException: Failed 
> to INSERT some keys because they are already in cache. [rows=[Row[32, 32]]]
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.flushTuples(ModifyNode.java:213)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:169)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:142)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ProjectNode.end(ProjectNode.java:81)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ScanNode.push(ScanNode.java:132)
> at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:308)
> ... 4 more
>   2022-02-15 12:31:28:311 +0300 [INFO][main][ItMixedQueriesTest] >>> 
> Stopping test: ItMixedQueriesTest#testSequentialInserts, displayName: 
> testSequentialInserts(), cost: 11065ms.
> 12:33:50   org.apache.ignite

[jira] [Comment Edited] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.



[ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481846#comment-17481846
 ] 

Pavel Pereslegin edited comment on IGNITE-15450 at 2/17/22, 12:42 PM:
--

The final solution is to add a "--sync" option to wait for the entire operation 
to complete.

*Create*
{noformat}
  Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--sync]

Parameters:
  snapshot_name  - Snapshot name.
  sync   - Run the operation synchronously, the command will wait 
for the entire operation to complete. Otherwise, it will be performed in the 
background, and the command will immediately return control.
{noformat}

*Restore*
{noformat}
  Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name --start [--groups 
group1,...groupN] [--sync]

Parameters:
  snapshot_name - Snapshot name.
  group1,...groupN  - Cache group names.
  sync  - Run the operation synchronously, the command will 
wait for the entire operation to complete. Otherwise, it will be performed in 
the background, and the command will immediately return control.
{noformat}

Example of error output if cache exists:

{noformat}
Command [SNAPSHOT] started
Arguments: --snapshot restore snapshot_02052020 --start --sync --yes 

Failed to perform operation.
Failed to reduce job results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask@2286ae67,
 err=class org.apache.ignite.IgniteException: Unable to restore cache group: 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest0/cache-test-cache]],
 trace=class org.apache.ignite.IgniteCheckedException: Failed to reduce job 
results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask@2286ae67,
 err=class org.apache.ignite.IgniteException: Unable to restore cache group: 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTest0/cache-test-cache]]
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7836)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:172)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:259)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:253)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener$$$capture(GridFutureAdapter.java:399)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:253)
at 
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:162)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest0(GridRestProcessor.java:317)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:303)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor.access$000(GridRestProcessor.java:108)
at 
org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:189)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.compute.ComputeUserUndeclaredException: 
Failed to reduce job results due to undeclared user exception 
[task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotRestoreTask@2286ae67,
 err=class org.apache.ignite.IgniteException: Unable to restore cache group: 
directory is not empty. Cache group should be destroyed manually before perform 
restore operation [group=test-cache, 
dir=/home/xtern/src/java/ignite/source/work/db/gridCommandHandlerTes

[jira] [Created] (IGNITE-16576) Add an integration test for unmarshalling an object with changed schema

Roman Puchkovskiy created IGNITE-16576:
--

 Summary: Add an integration test for unmarshalling an object with 
changed schema
 Key: IGNITE-16576
 URL: https://issues.apache.org/jira/browse/IGNITE-16576
 Project: Ignite
  Issue Type: Improvement
  Components: networking
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
 Fix For: 3.0.0-alpha5


The idea is to marshal an object send it via our network mechanisms and then 
unmarshal it (on another node) using a different version of the same class 
(that is, adding some field and removing some other field).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (IGNITE-16575) Support readObjectNoData() in User Object Serialization

Roman Puchkovskiy created IGNITE-16575:
--

 Summary: Support readObjectNoData() in User Object Serialization
 Key: IGNITE-16575
 URL: https://issues.apache.org/jira/browse/IGNITE-16575
 Project: Ignite
  Issue Type: Improvement
  Components: networking
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
 Fix For: 3.0.0-alpha5


The standard Java Serialization defines readObjectNoData() hook for 
Serializable classes; it is invoked when locally its class is one of ancestor 
classes of the deserialized object, but remotely it was not in the lineage, so 
the stream does not contain any data for it. So this method can be used to init 
class fields to some 'default' state.

As we support Java Serialization features, we should also invoke this method on 
Serializable classes in similar circumstances.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16561) ItMixedQueriesTest.testSequentialInserts is flaky



 [ 
https://issues.apache.org/jira/browse/IGNITE-16561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-16561:
---
Component/s: sql

> ItMixedQueriesTest.testSequentialInserts is flaky
> -
>
> Key: IGNITE-16561
> URL: https://issues.apache.org/jira/browse/IGNITE-16561
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Mirza Aliev
>Priority: Blocker
>  Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_1651.log, 
> _Integration_Tests_Module_Runner_1653.log
>
>
> {{ItMixedQueriesTest#testSequentialInserts}} is flaky. It fails with a 
> different {{Unexpected exception}} on a different runs: 
> {noformat}
> 2022-02-15 12:07:09:954 +0300 
> [WARNING][%ItMixedQueriesTest_null_0%sqlExec-2][QueryTaskExecutorImpl] 
> Uncaught exception
> class org.apache.ignite.lang.IgniteInternalException: Unexpected exception
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:313)
>   at 
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:75)
>   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:834)
> Caused by: java.util.concurrent.CompletionException: class 
> org.apache.ignite.tx.TransactionException: 
> java.util.concurrent.TimeoutException
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
>   at 
> java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
>   at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
>   at 
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
>   at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
>   at 
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
>   at 
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by: class org.apache.ignite.tx.TransactionException: 
> java.util.concurrent.TimeoutException
>   at 
> org.apache.ignite.internal.tx.impl.TxManagerImpl.lambda$finishRemote$3(TxManagerImpl.java:260)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
>   ... 9 more
> {noformat}
> {noformat}
> 2022-02-15 12:31:28:310 +0300 
> [WARNING][%ItMixedQueriesTest_null_0%sqlExec-0][QueryTaskExecutorImpl] 
> Uncaught exception
>   class org.apache.ignite.lang.IgniteInternalException: Unexpected 
> exception
> at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:313)
> at 
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:75)
> 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:834)
>   Caused by: class org.apache.ignite.lang.IgniteInternalException: Failed 
> to INSERT some keys because they are already in cache. [rows=[Row[32, 32]]]
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.flushTuples(ModifyNode.java:213)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:169)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:142)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ProjectNode.end(ProjectNode.java:81)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ScanNode.push(ScanNode.java:132)
> at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:308)
> ... 4 more
>   2022-02-15 12:31:28:311 +0300 [INFO][main][ItMixedQueriesTest] >>> 
> Stopping test: ItMixedQueriesTest#testSequentialInserts, displayName: 
> testSequentialInserts(), cost: 11065ms.
> 12:33:50   o

[jira] [Updated] (IGNITE-16562) ItSortAggregateTest.initTestData is flaky



 [ 
https://issues.apache.org/jira/browse/IGNITE-16562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-16562:
---
Priority: Blocker  (was: Major)

> ItSortAggregateTest.initTestData is flaky
> -
>
> Key: IGNITE-16562
> URL: https://issues.apache.org/jira/browse/IGNITE-16562
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Blocker
>  Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_1655.log
>
>
> ItSortAggregateTest#initTestData could not be completed because of spamming 
> {noformat}
> 2022-02-15 12:34:59:608 +0300 
> [ERROR][%ItSortAggregateTest_null_2%Raft-Group-Client-8][RaftGroupServiceImpl]
>  Failed to refresh a leader 
> [groupId=a6328a6b-7da8-4a8f-a1b5-a27c75c6007b_part_9]
> java.util.concurrent.CompletionException: 
> java.util.concurrent.TimeoutException
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
>   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.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:502)
>   at 
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.lambda$accept$1(RaftGroupServiceImpl.java:544)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
>   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:834)
> Caused by: java.util.concurrent.TimeoutException
> {noformat}
> Log contains suspicions warnings from scalecube on a very beginning 
> {noformat}
> [12:34:57]W:   [org.apache.ignite:ignite-runner] 2022-02-15 
> 12:34:46:180 +0300 [WARNING][sc-cluster-3345-150][MetadataStore] 
> [default:ItSortAggregateTest_null_1:03483828-9532-4700-8fce-538486364fdf@172.17.0.6:3345][03483828-9532-4700-8fce-538486364fdf-1644917650003]
>  Timeout getting GetMetadataResp from 172.17.0.6:3346 within 1000 ms, cause: 
> java.util.concurrent.TimeoutException: Did not observe any item or terminal 
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been 
> configured)
> [12:34:57]W:   [org.apache.ignite:ignite-runner] 2022-02-15 
> 12:34:46:180 +0300 [WARNING][sc-cluster-3345-150][MembershipProtocol] 
> [default:ItSortAggregateTest_null_1:03483828-9532-4700-8fce-538486364fdf@172.17.0.6:3345][updateMembership][SYNC]
>  Skipping to add/update member: {m: 
> default:ItSortAggregateTest_null_2:40801246-c98f-4db1-8acd-bcda982bd343@172.17.0.6:3346,
>  s: ALIVE, inc: 0}, due to failed fetchMetadata call (cause: 
> java.util.concurrent.TimeoutException: Did not observe any item or terminal 
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been 
> configured))
> [12:34:57]W:   [org.apache.ignite:ignite-runner] 2022-02-15 
> 12:34:46:180 +0300 [WARNING][sc-cluster-3345-150][MetadataStore] 
> [default:ItSortAggregateTest_null_1:03483828-9532-4700-8fce-538486364fdf@172.17.0.6:3345][03483828-9532-4700-8fce-538486364fdf-1644917650004]
>  Timeout getting GetMetadataResp from 172.17.0.6:3346 within 1000 ms, cause: 
> java.util.concurrent.TimeoutException: Did not observe any item or terminal 
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been 
> configured)
> [12:34:57]W:   [org.apache.ignite:ignite-runner] 2022-02-15 
> 12:34:46:180 +0300 [WARNING][sc-cluster-3345-150][MembershipProtocol] 
> [default:ItSortAggregateTest_null_1:03483828-9532-4700-8fce-538486364fdf@172.17.0.6:3345][updateMembership][SYNC]
>  Skipping to add/update member: {m: 
> default:ItSortAggregateTest_null_2:40801246-c98f-4db1-8acd-bcda982bd343@172.17.0.6:3346,
>  s: ALIVE, inc: 0}, due to failed fetchMetadata call (cause: 
> java.util.concurrent.TimeoutException: Did not observe any item or terminal 
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been 
> configured))
> [12:34:57]W:   [org.apache.ignite:ignite-runner] 2022-02-15 
> 12:34:46:181 +0300 [WARNING][sc-cluster-3345-150][MetadataStore] 
> [default:ItSortAggregateTest_null_1:03483828-9532-4700-8fce-538486364fdf@172.17.0.6:3345][03483828-9532-4700-8fce-538486364fdf-1644917650005]
>  T

[jira] [Updated] (IGNITE-16561) ItMixedQueriesTest.testSequentialInserts is flaky



 [ 
https://issues.apache.org/jira/browse/IGNITE-16561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-16561:
---
Priority: Blocker  (was: Major)

> ItMixedQueriesTest.testSequentialInserts is flaky
> -
>
> Key: IGNITE-16561
> URL: https://issues.apache.org/jira/browse/IGNITE-16561
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Blocker
>  Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_1651.log, 
> _Integration_Tests_Module_Runner_1653.log
>
>
> {{ItMixedQueriesTest#testSequentialInserts}} is flaky. It fails with a 
> different {{Unexpected exception}} on a different runs: 
> {noformat}
> 2022-02-15 12:07:09:954 +0300 
> [WARNING][%ItMixedQueriesTest_null_0%sqlExec-2][QueryTaskExecutorImpl] 
> Uncaught exception
> class org.apache.ignite.lang.IgniteInternalException: Unexpected exception
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:313)
>   at 
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:75)
>   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:834)
> Caused by: java.util.concurrent.CompletionException: class 
> org.apache.ignite.tx.TransactionException: 
> java.util.concurrent.TimeoutException
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)
>   at 
> java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
>   at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
>   at 
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
>   at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
>   at 
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
>   at 
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by: class org.apache.ignite.tx.TransactionException: 
> java.util.concurrent.TimeoutException
>   at 
> org.apache.ignite.internal.tx.impl.TxManagerImpl.lambda$finishRemote$3(TxManagerImpl.java:260)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
>   ... 9 more
> {noformat}
> {noformat}
> 2022-02-15 12:31:28:310 +0300 
> [WARNING][%ItMixedQueriesTest_null_0%sqlExec-0][QueryTaskExecutorImpl] 
> Uncaught exception
>   class org.apache.ignite.lang.IgniteInternalException: Unexpected 
> exception
> at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:313)
> at 
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:75)
> 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:834)
>   Caused by: class org.apache.ignite.lang.IgniteInternalException: Failed 
> to INSERT some keys because they are already in cache. [rows=[Row[32, 32]]]
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.flushTuples(ModifyNode.java:213)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:169)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:142)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ProjectNode.end(ProjectNode.java:81)
> at 
> org.apache.ignite.internal.sql.engine.exec.rel.ScanNode.push(ScanNode.java:132)
> at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:308)
> ... 4 more
>   2022-02-15 12:31:28:311 +0300 [INFO][main][ItMixedQueriesTest] >>> 
> Stopping test: ItMixedQueriesTest#testSequentialInserts, displayName: 
> testSequentialInserts(), cost: 11065ms.
> 12:33:50   org.apache.ig

[jira] [Updated] (IGNITE-16555) ItSqlExtensionTest.test fails



 [ 
https://issues.apache.org/jira/browse/IGNITE-16555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-16555:
---
Priority: Blocker  (was: Major)

> ItSqlExtensionTest.test fails
> -
>
> Key: IGNITE-16555
> URL: https://issues.apache.org/jira/browse/IGNITE-16555
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Mirza Aliev
>Priority: Blocker
>  Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_1651.log
>
>
> {{ItSqlExtensionTest#test}} fails locally and on TC with
> {noformat}
> class org.apache.ignite.lang.IgniteInternalException: Unknown SQL extension 
> "TEST_EXT"
>   at 
> org.apache.ignite.internal.sql.engine.metadata.IgniteMdFragmentMapping.fragmentMapping(IgniteMdFragmentMapping.java:230)
>   at 
> org.apache.calcite.rel.metadata.janino.GeneratedMetadata_FragmentMappingMetadataHandler.fragmentMapping_$(Unknown
>  Source)
>   at 
> org.apache.calcite.rel.metadata.janino.GeneratedMetadata_FragmentMappingMetadataHandler.fragmentMapping(Unknown
>  Source)
>   at 
> org.apache.ignite.internal.sql.engine.metadata.RelMetadataQueryEx.fragmentMapping(RelMetadataQueryEx.java:93)
>   at 
> org.apache.ignite.internal.sql.engine.metadata.IgniteMdFragmentMapping.fragmentMappingForMetadataQuery(IgniteMdFragmentMapping.java:71)
>   at 
> org.apache.ignite.internal.sql.engine.metadata.IgniteMdFragmentMapping.fragmentMapping(IgniteMdFragmentMapping.java:102)
>   at 
> org.apache.calcite.rel.metadata.janino.GeneratedMetadata_FragmentMappingMetadataHandler.fragmentMapping_$(Unknown
>  Source)
>   at 
> org.apache.calcite.rel.metadata.janino.GeneratedMetadata_FragmentMappingMetadataHandler.fragmentMapping(Unknown
>  Source)
>   at 
> org.apache.ignite.internal.sql.engine.metadata.RelMetadataQueryEx.fragmentMapping(RelMetadataQueryEx.java:93)
>   at 
> org.apache.ignite.internal.sql.engine.metadata.IgniteMdFragmentMapping.fragmentMappingForMetadataQuery(IgniteMdFragmentMapping.java:71)
>   at 
> org.apache.ignite.internal.sql.engine.prepare.Fragment.mapping(Fragment.java:111)
>   at 
> org.apache.ignite.internal.sql.engine.prepare.Fragment.map(Fragment.java:159)
>   at 
> org.apache.ignite.internal.sql.engine.prepare.QueryTemplate.map(QueryTemplate.java:107)
>   at 
> org.apache.ignite.internal.sql.engine.prepare.QueryTemplate.map(QueryTemplate.java:81)
>   at 
> org.apache.ignite.internal.sql.engine.prepare.AbstractMultiStepPlan.init(AbstractMultiStepPlan.java:107)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.mapAndExecutePlan(ExecutionServiceImpl.java:175)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.executePlan(ExecutionServiceImpl.java:292)
>   at 
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor.query0(SqlQueryProcessor.java:312)
>   at 
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor.query(SqlQueryProcessor.java:235)
>   at 
> org.apache.ignite.internal.sql.engine.util.QueryChecker.check(QueryChecker.java:359)
>   at 
> org.apache.ignite.internal.sql.engine.ItSqlExtensionTest.test(ItSqlExtensionTest.java:63)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
>   at 
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
>   at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
>   at 
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
>   at 
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
>   at 
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
>   at 
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
>   at 
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
>   at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
>   at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
>   at 
> org.junit.jupiter.eng

[jira] [Updated] (IGNITE-16557) ItJdbcStatementSelfTest.testExecuteUpdateOnDdl fails



 [ 
https://issues.apache.org/jira/browse/IGNITE-16557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-16557:
---
Priority: Blocker  (was: Major)

> ItJdbcStatementSelfTest.testExecuteUpdateOnDdl fails
> 
>
> Key: IGNITE-16557
> URL: https://issues.apache.org/jira/browse/IGNITE-16557
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Mirza Aliev
>Priority: Blocker
>  Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_1651.log
>
>
> org.apache.ignite.internal.runner.app.jdbc.ItJdbcStatementSelfTest#testExecuteUpdateOnDdl
>  fails locally and on TC with
> {noformat}
> java.sql.SQLException: Exception while executing query DROP TABLE 
> "test_742a5d21-fcbe-4a47-b8cb-1218bb35c560". Error message: class 
> org.apache.ignite.lang.TableNotFoundException: Table does not exist 
> [name=PUBLIC.test_742a5d21-fcbe-4a47-b8cb-1218bb35c560]
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.lambda$dropTableAsyncInternal$21(TableManager.java:930)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniAcceptNow(CompletableFuture.java:753)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:731)
>   at 
> java.base/java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:2108)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.dropTableAsyncInternal(TableManager.java:926)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.dropTableAsync(TableManager.java:904)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.dropTable(TableManager.java:894)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ddl.DdlCommandHandler.handleDropTable(DdlCommandHandler.java:167)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ddl.DdlCommandHandler.handle(DdlCommandHandler.java:80)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.executeDdl(ExecutionServiceImpl.java:308)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.executePlan(ExecutionServiceImpl.java:299)
>   at 
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor.query0(SqlQueryProcessor.java:312)
>   at 
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor.query(SqlQueryProcessor.java:235)
>   at 
> org.apache.ignite.client.handler.JdbcQueryEventHandlerImpl.queryAsync(JdbcQueryEventHandlerImpl.java:98)
>   at 
> org.apache.ignite.client.handler.requests.sql.ClientSqlExecuteRequest.execute(ClientSqlExecuteRequest.java:47)
>   at 
> org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:343)
>   at 
> org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:252)
>   at 
> org.apache.ignite.client.handler.ClientInboundMessageHandler.channelRead(ClientInboundMessageHandler.java:129)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
>   at 
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
>   at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
>   at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>   at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
>   at 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
>   at io.netty.chann

[jira] [Updated] (IGNITE-16554) Some tests in ItProjectScanMergeRuleTest do not pass



 [ 
https://issues.apache.org/jira/browse/IGNITE-16554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-16554:
---
Priority: Blocker  (was: Major)

> Some tests in ItProjectScanMergeRuleTest do not pass
> 
>
> Key: IGNITE-16554
> URL: https://issues.apache.org/jira/browse/IGNITE-16554
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Mirza Aliev
>Priority: Blocker
>  Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_1651.log
>
>
> The following tests fail on TC and local runs: 
> {{ItProjectScanMergeRuleTest#testProjects}} and 
> {{ItProjectScanMergeRuleTest#testNestedProjects}}.
> {{ItProjectScanMergeRuleTest#testProjects}}  fails with 
> {noformat}
> java.lang.AssertionError: Invalid plan:
> IgniteExchange(distribution=[single]): rowcount = 1.0, cumulative cost = 
> IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, io=0.0, 
> network=4.0], id = 21
>   IgniteTableScan(tableId=[24bcfc5f-5932-467a-b89f-6faa4eade77e], 
> requiredColumns=[{5}]): rowcount = 1.0, cumulative cost = IgniteCost 
> [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 18
> Expected: a string contains once 
> ".*Ignite(Table|Index)Scan\\(table=\\[\\[PUBLIC, PRODUCTS\\]\\].*"
>  but: was "IgniteExchange(distribution=[single]): rowcount = 1.0, 
> cumulative cost = IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, 
> io=0.0, network=4.0], id = 21
>   IgniteTableScan(tableId=[24bcfc5f-5932-467a-b89f-6faa4eade77e], 
> requiredColumns=[{5}]): rowcount = 1.0, cumulative cost = IgniteCost 
> [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 18
> "
> {noformat}
> {{ItProjectScanMergeRuleTest#testNestedProjects}} fails with
> {noformat}
> java.lang.AssertionError: Invalid plan:
> IgniteProject(NAME=[$2]): rowcount = 375.0, cumulative cost = IgniteCost 
> [rowCount=50375.0, cpu=319313.2429526658, memory=8.0, io=0.0, 
> network=8.0], id = 16044
>   IgniteMergeJoin(condition=[=($1, $3)], joinType=[inner], variablesSet=[[]], 
> leftCollation=[[1]], rightCollation=[[0]]): rowcount = 375.0, cumulative cost 
> = IgniteCost [rowCount=5.0, cpu=318938.2429526658, memory=8.0, 
> io=0.0, network=8.0], id = 16043
> IgniteSort(sort0=[$1], dir0=[ASC]): rowcount = 5000.0, cumulative cost = 
> IgniteCost [rowCount=2.0, cpu=177757.8978712436, memory=6.0, io=0.0, 
> network=6.0], id = 16039
>   IgniteExchange(distribution=[single]): rowcount = 5000.0, cumulative 
> cost = IgniteCost [rowCount=15000.0, cpu=45000.0, memory=0.0, io=0.0, 
> network=6.0], id = 16038
> IgniteTableScan(tableId=[97c7efca-c87c-4bc1-abbd-79a7ba85f723], 
> filters=[>($t0, 2)], requiredColumns=[{0, 2, 5}]): rowcount = 5000.0, 
> cumulative cost = IgniteCost [rowCount=1.0, cpu=4.0, memory=0.0, 
> io=0.0, network=0.0], id = 149
> IgniteSort(sort0=[$0], dir0=[ASC]): rowcount = 2500.0, cumulative cost = 
> IgniteCost [rowCount=22500.0, cpu=80.34508142219, memory=2.0, io=0.0, 
> network=2.0], id = 16042
>   IgniteSingleHashAggregate(group=[{0}]): rowcount = 2500.0, cumulative 
> cost = IgniteCost [rowCount=2.0, cpu=5.0, memory=1.0, io=0.0, 
> network=2.0], id = 16041
> IgniteExchange(distribution=[single]): rowcount = 5000.0, cumulative 
> cost = IgniteCost [rowCount=15000.0, cpu=45000.0, memory=0.0, io=0.0, 
> network=2.0], id = 16040
>   IgniteTableScan(tableId=[97c7efca-c87c-4bc1-abbd-79a7ba85f723], 
> filters=[>($t0, 1)], requiredColumns=[{2}]): rowcount = 5000.0, cumulative 
> cost = IgniteCost [rowCount=1.0, cpu=4.0, memory=0.0, io=0.0, 
> network=0.0], id = 178
> Expected: a string contains once 
> ".*Ignite(Table|Index)Scan\\(table=\\[\\[PUBLIC, 
> PRODUCTS\\]\\],.*requiredColumns=\\[\\{(\\d|\\W|,)+\\}\\].*"
>  but: was "IgniteProject(NAME=[$2]): rowcount = 375.0, cumulative cost = 
> IgniteCost [rowCount=50375.0, cpu=319313.2429526658, memory=8.0, io=0.0, 
> network=8.0], id = 16044
>   IgniteMergeJoin(condition=[=($1, $3)], joinType=[inner], variablesSet=[[]], 
> leftCollation=[[1]], rightCollation=[[0]]): rowcount = 375.0, cumulative cost 
> = IgniteCost [rowCount=5.0, cpu=318938.2429526658, memory=8.0, 
> io=0.0, network=8.0], id = 16043
> IgniteSort(sort0=[$1], dir0=[ASC]): rowcount = 5000.0, cumulative cost = 
> IgniteCost [rowCount=2.0, cpu=177757.8978712436, memory=6.0, io=0.0, 
> network=6.0], id = 16039
>   IgniteExchange(distribution=[single]): rowcount = 5000.0, cumulative 
> cost = IgniteCost [rowCount=15000.0, cpu=45000.0, memory=0.0, io=0.0, 
> network=6.0], id = 16038
> IgniteTableScan(tableId=[97c7efca-c87c-4bc1-abbd-79a7ba85f723], 
> f

[jira] [Updated] (IGNITE-16478) RocksDB returns unexpected cursor.hasNext equals false after leader is changed



 [ 
https://issues.apache.org/jira/browse/IGNITE-16478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-16478:
---
Priority: Blocker  (was: Major)

> RocksDB returns unexpected cursor.hasNext equals false after leader is changed
> --
>
> Key: IGNITE-16478
> URL: https://issues.apache.org/jira/browse/IGNITE-16478
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Blocker
>  Labels: ignite-3
>
> After investigation of https://issues.apache.org/jira/browse/IGNITE-16406 we 
> found a bug in {{PartitionListener#handleScanRetrieveBatchCommand}} when 
> leader is changed. In some case, {{cursorDesc.cursor().hasNext()}} returns 
> false, hence select operation return empty response, but should response 
> several rows. 
> Investigation showed that cursor that is returned from 
> {{RocksDbPartitionStorage#scan}}
> is inconsistent after leader changing because its hasNext returns unexpected 
> false.
> Further investigation is needed.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16558) ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand is flaky



 [ 
https://issues.apache.org/jira/browse/IGNITE-16558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-16558:
---
Priority: Blocker  (was: Major)

> ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand is flaky 
> 
>
> Key: IGNITE-16558
> URL: https://issues.apache.org/jira/browse/IGNITE-16558
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Mirza Aliev
>Priority: Blocker
>  Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_1653.log
>
>
> {{ItMixedQueriesTest#testIgniteSchemaAwaresAlterTableCommand}} is flaky, can 
> be reproduced locally and on TC. It fails with 
> {noformat}
> 2022-02-15 17:45:54:762 +0300 
> [ERROR][%ItMixedQueriesTest_null_1%sqlExec-2][ExecutionServiceImpl] Failed to 
> start query fragment
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
>   at 
> org.apache.ignite.internal.sql.engine.schema.TableDescriptorImpl.rowType(TableDescriptorImpl.java:137)
>   at 
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.getRowType(IgniteTableImpl.java:117)
>   at 
> org.apache.ignite.internal.sql.engine.rel.ProjectableFilterableTableScan.deriveRowType(ProjectableFilterableTableScan.java:174)
>   at 
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
>   at org.apache.calcite.rel.SingleRel.deriveRowType(SingleRel.java:89)
>   at 
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
>   at 
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:157)
>   at 
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:111)
>   at 
> org.apache.ignite.internal.sql.engine.rel.IgniteSender.accept(IgniteSender.java:106)
>   at 
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:716)
>   at 
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.go(LogicalRelImplementor.java:731)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.executeFragment(ExecutionServiceImpl.java:335)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:401)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$1(ExecutionServiceImpl.java:165)
>   at 
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:155)
>   at 
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$3(MessageServiceImpl.java:125)
>   at 
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:75)
>   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:834)
> 2022-02-15 17:45:54:767 +0300 
> [WARNING][%ItMixedQueriesTest_null_1%sqlExec-2][QueryTaskExecutorImpl] 
> Uncaught exception
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
>   at 
> org.apache.ignite.internal.sql.engine.schema.TableDescriptorImpl.rowType(TableDescriptorImpl.java:137)
>   at 
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.getRowType(IgniteTableImpl.java:117)
>   at 
> org.apache.ignite.internal.sql.engine.rel.ProjectableFilterableTableScan.deriveRowType(ProjectableFilterableTableScan.java:174)
>   at 
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
>   at org.apache.calcite.rel.SingleRel.deriveRowType(SingleRel.java:89)
>   at 
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
>   at 
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:157)
>   at 
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:111)
>   at 
> org.apache.ignite.internal.sql.engine.rel.IgniteSender.accept(IgniteSender.java:106)
>   at 
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:716)
>   at 
> org.apache.ignite.internal.sql.engine.exec.LogicalRelImplementor.go(LogicalRelImplementor.java:731)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.executeFragment(ExecutionServiceImpl.java:335)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:401)
>   at 
> org.apache.ignite.inter

[jira] [Updated] (IGNITE-16556) ItJdbcSelectAfterAlterTable.testSelectAfterAlterTableSingleNode fails



 [ 
https://issues.apache.org/jira/browse/IGNITE-16556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-16556:
---
Priority: Blocker  (was: Major)

> ItJdbcSelectAfterAlterTable.testSelectAfterAlterTableSingleNode fails
> -
>
> Key: IGNITE-16556
> URL: https://issues.apache.org/jira/browse/IGNITE-16556
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Mirza Aliev
>Priority: Blocker
>  Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_1651.log
>
>
> {{ItJdbcSelectAfterAlterTable#testSelectAfterAlterTableSingleNode}} fails 
> locally and on TC with 
> {noformat}
> java.sql.SQLException: Failed to fetch results for query select * from 
> PUBLIC.PERSON. Error message: class org.apache.ignite.lang.IgniteException: 
> An error occurred while query executing.
>   at 
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.checkException(RootNode.java:278)
>   at 
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:265)
>   at 
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.hasNext(RootNode.java:189)
>   at 
> org.apache.ignite.internal.sql.engine.exec.ClosableIteratorsHolder$DelegatingIterator.hasNext(ClosableIteratorsHolder.java:132)
>   at 
> org.apache.ignite.internal.sql.engine.util.TransformingIterator.hasNext(TransformingIterator.java:44)
>   at 
> org.apache.ignite.internal.sql.engine.util.Commons$1.hasNext(Commons.java:208)
>   at 
> org.apache.ignite.client.handler.requests.sql.JdbcQueryCursor.hasNext(JdbcQueryCursor.java:62)
>   at 
> org.apache.ignite.client.handler.JdbcQueryEventHandlerImpl.fetchNext(JdbcQueryEventHandlerImpl.java:347)
>   at 
> org.apache.ignite.client.handler.JdbcQueryEventHandlerImpl.createJdbcResult(JdbcQueryEventHandlerImpl.java:292)
>   at 
> org.apache.ignite.client.handler.JdbcQueryEventHandlerImpl.queryAsync(JdbcQueryEventHandlerImpl.java:120)
>   at 
> org.apache.ignite.client.handler.requests.sql.ClientSqlExecuteRequest.execute(ClientSqlExecuteRequest.java:47)
>   at 
> org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:343)
>   at 
> org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:252)
>   at 
> org.apache.ignite.client.handler.ClientInboundMessageHandler.channelRead(ClientInboundMessageHandler.java:129)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
>   at 
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
>   at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
>   at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>   at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>   at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
>   at 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>   at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
>   at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.ignite.internal.sql.engine.metadata.RemoteException: 
> Remote query execution
>

[jira] [Created] (IGNITE-16574) Support schema changes concerning serializability status

Roman Puchkovskiy created IGNITE-16574:
--

 Summary: Support schema changes concerning serializability status
 Key: IGNITE-16574
 URL: https://issues.apache.org/jira/browse/IGNITE-16574
 Project: Ignite
  Issue Type: Improvement
  Components: networking
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
 Fix For: 3.0.0-alpha5


See 
[https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md#handling-class-structure-changes]

The document does not mention it, but we support Serializable-related features 
in our User Object Serialization, and these can change between remote and local 
class versions. Here is what can change:
 # Whether class is Serializable
 # Whether it has writeObject, readObject, readObjectNoData
 # Whether it has writeReplace, readResolve



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16559) Node's log contains "Failed to refresh a leader" messages.



 [ 
https://issues.apache.org/jira/browse/IGNITE-16559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-16559:
---
Priority: Blocker  (was: Major)

> Node's log contains "Failed to refresh a leader" messages. 
> ---
>
> Key: IGNITE-16559
> URL: https://issues.apache.org/jira/browse/IGNITE-16559
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Blocker
>  Labels: ignite-3
>
> We noticed that when we run 
> {{ItMixedQueriesTest.testIgniteSchemaAwaresAlterTableCommand}} on TC it is 
> possible that log contain such messages: 
> {noformat}
> 2022-02-15 12:36:43:568 +0300 
> [ERROR][%ItMixedQueriesTest_null_1%Raft-Group-Client-0][RaftGroupServiceImpl] 
> Failed to refresh a leader 
> [groupId=8e71fc5e-6b24-4b69-ba5a-6eae4c2165cf_part_16]
> java.util.concurrent.CompletionException: 
> java.util.concurrent.TimeoutException
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
>   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.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:502)
>   at 
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.lambda$accept$1(RaftGroupServiceImpl.java:544)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
>   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:834)
> Caused by: java.util.concurrent.TimeoutException
> {noformat}
> Possible root cause: 
> Seems, that we get TimeoutException when we try to get a leader from a client 
> for a group, for which leader has not been elected yet. If you check the 
> logs, you can see, that we get timeout exception and after that leader for 
> the corresponding group has been elected. 
> Note that we have only one node and 10 partitions for a table in the test, 
> but raft leaders are elected sequentially on a node, so electing 10 leaders 
> for raft groups on one node might take a little bit longer.  
> Possible solution:
> Increase timeout for a client to get a leader for the first time.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (IGNITE-16573) Support schema changes concerning externalizability status

Roman Puchkovskiy created IGNITE-16573:
--

 Summary: Support schema changes concerning externalizability status
 Key: IGNITE-16573
 URL: https://issues.apache.org/jira/browse/IGNITE-16573
 Project: Ignite
  Issue Type: Improvement
  Components: networking
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
 Fix For: 3.0.0-alpha5


This relates to the cases when a class becomes or ceased to be an 
Externalizable.

See 
https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md#handling-class-structure-changes



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (IGNITE-16572) Make UosGetField.getObjectStreamClass() support schema changes

Roman Puchkovskiy created IGNITE-16572:
--

 Summary: Make UosGetField.getObjectStreamClass() support schema 
changes
 Key: IGNITE-16572
 URL: https://issues.apache.org/jira/browse/IGNITE-16572
 Project: Ignite
  Issue Type: Improvement
  Components: networking
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
 Fix For: 3.0.0-alpha5


Currently, UosGetField.getObjectStreamClass() assumes that the remote and local 
classes are same.

The correct thing to do would be to reconstruct/modify ObjectStreamClass so 
that it matches the remote one. Another option is to serialize the actual 
remote ObjectStreamClass instance and deserialize it locally.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16571) Implement defaultness semantics for GetField when schema changes



 [ 
https://issues.apache.org/jira/browse/IGNITE-16571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-16571:
---
Summary: Implement defaultness semantics for GetField when schema changes  
(was: Implement 'defaultness' semantics for GetField when schema changes)

> Implement defaultness semantics for GetField when schema changes
> 
>
> Key: IGNITE-16571
> URL: https://issues.apache.org/jira/browse/IGNITE-16571
> Project: Ignite
>  Issue Type: Improvement
>  Components: networking
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> GetField.defaulted() should return true when the remote class version does 
> not have such a field.
> GetField.get(fieldName, defaultValue) should return the default value in such 
> cases.
> Currently, our UosGetField implementation does not work like this and always 
> thinks that every field which is present locally is also present remotely.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (IGNITE-16571) Implement 'defaultness' semantics for GetField when schema changes

Roman Puchkovskiy created IGNITE-16571:
--

 Summary: Implement 'defaultness' semantics for GetField when 
schema changes
 Key: IGNITE-16571
 URL: https://issues.apache.org/jira/browse/IGNITE-16571
 Project: Ignite
  Issue Type: Improvement
  Components: networking
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
 Fix For: 3.0.0-alpha5


GetField.defaulted() should return true when the remote class version does not 
have such a field.

GetField.get(fieldName, defaultValue) should return the default value in such 
cases.

Currently, our UosGetField implementation does not work like this and always 
thinks that every field which is present locally is also present remotely.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (IGNITE-16569) PersistenceUpgradeTest ducktest fails if SSL is enabled



[ 
https://issues.apache.org/jira/browse/IGNITE-16569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493797#comment-17493797
 ] 

Sergey Korotkov edited comment on IGNITE-16569 at 2/17/22, 11:19 AM:
-

Solution is to ignore test if SSL is enabled.


was (Author: JIRAUSER279895):
Solution is to ignore test if SSL is enabled and starting test point is still 
version 2.7.6.  

Once it would be decided to drop the 2.7.6 support (via change the OLDEST 
constant) test would start work both for SSL and non-SSL configurations 
automatically.

> PersistenceUpgradeTest ducktest fails if SSL is enabled
> ---
>
> Key: IGNITE-16569
> URL: https://issues.apache.org/jira/browse/IGNITE-16569
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
>  Labels: ducktests
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The PersistenceUpgradeTest fails if SSL is enabled via the --globals options.
> The immediate reason is that control.sh doesn't support the SSL options (like 
> key_store_path) in the 2.7.6 version which is the starting point for the test 
> incremental migrations of the PDS .



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (IGNITE-16570) NoClassDefFoundError in case of running Ignite inside WildFly

2022-02-17 Thread Amelchev Nikita (Jira)

Amelchev Nikita created IGNITE-16570:


 Summary: NoClassDefFoundError in case of running Ignite inside 
WildFly
 Key: IGNITE-16570
 URL: https://issues.apache.org/jira/browse/IGNITE-16570
 Project: Ignite
  Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
 Fix For: 2.13


The Ignite casts {{java.lang.management.OperatingSystemMXBean}} to the 
{{com.sun.management.OperatingSystemMXBean}} that is not guaranteed to be 
present. 
For example, WildFly/JBoss does not include com.sun.* classes by default.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-16081) Arbitrary Object Serialization Prototype

2022-02-17 Thread Semyon Danilov (Jira)



[ 
https://issues.apache.org/jira/browse/IGNITE-16081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493831#comment-17493831
 ] 

Semyon Danilov commented on IGNITE-16081:
-

The prototype was developed and the concept was proven. The result is this pull 
request https://github.com/apache/ignite-3/pull/534.

> Arbitrary Object Serialization Prototype
> 
>
> Key: IGNITE-16081
> URL: https://issues.apache.org/jira/browse/IGNITE-16081
> Project: Ignite
>  Issue Type: Task
>  Components: networking
>Reporter: Sergey Chugunov
>Assignee: Semyon Danilov
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> *Arbitrary Object Serialization* described in 
> [IEP-67|https://cwiki.apache.org/confluence/display/IGNITE/IEP-67%3A+Networking+module]
>  will be used in several pieces of functionality including serialization of 
> low-level network messages, in Compute Grid and Service Grid scenarios and 
> some others.
> To enable early testing, clarification and integration of serialization API 
> it is proposed to develop a prototype of Compute Grid functionality.
> Prototype will also enable to test code design for Compute Grid functionality 
> as well.
> *Feature to be developed:*
> {code:java}
> public interface IgniteCompute {
>   public  R execute(Class> taskCls, T 
> arg);
> }
> {code}
> It represents just the simplest method taken from existing Compute Grid in 
> ignite 2.x.
> *Assumptions:*
> * No code deployment is required, all classes are available on a classpath of 
> each server node.
> * Subjects of serialization are task arguments (T type) and the result (R 
> type).
> * Serialization mechanism works only between server nodes. All external 
> communications (thin clients etc) use independent serialization mechanisms.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-16480) Remove ignite-shmem from codebase



[ 
https://issues.apache.org/jira/browse/IGNITE-16480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493812#comment-17493812
 ] 

Vyacheslav Koptilin commented on IGNITE-16480:
--

Hi [~ivandasch],

The patch looks good! Thank you for your contribution!

> Remove ignite-shmem from codebase
> -
>
> Key: IGNITE-16480
> URL: https://issues.apache.org/jira/browse/IGNITE-16480
> Project: Ignite
>  Issue Type: Task
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Fix For: 2.13
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Ignite shmem is abandoned, see below
> 1. Currently it is broken in the master and nobody cares about it. 
> 2. It is not checked regularly on TC
> 3. Native module is of questionable code quality and doesn't compile on 
> modern gcc
> 4. Native module is not built regularly and we use strange artefact for 
> release instead (org.gridgain:ignite-shmem:jar:1.0.0)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-16569) PersistenceUpgradeTest ducktest fails if SSL is enabled



[ 
https://issues.apache.org/jira/browse/IGNITE-16569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493797#comment-17493797
 ] 

Sergey Korotkov commented on IGNITE-16569:
--

Solution is to ignore test if SSL is enabled and starting test point is still 
version 2.7.6.  

Once it would be decided to drop the 2.7.6 support (via change the OLDEST 
constant) test would start work both for SSL and non-SSL configurations 
automatically.

> PersistenceUpgradeTest ducktest fails if SSL is enabled
> ---
>
> Key: IGNITE-16569
> URL: https://issues.apache.org/jira/browse/IGNITE-16569
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
>  Labels: ducktests
>
> The PersistenceUpgradeTest fails if SSL is enabled via the --globals options.
> The immediate reason is that control.sh doesn't support the SSL options (like 
> key_store_path) in the 2.7.6 version which is the starting point for the test 
> incremental migrations of the PDS .



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-15818) [Native Persistence 3.0] Checkpoint, lifecycle and file store refactoring and re-implementation

2022-02-17 Thread Ivan Bessonov (Jira)

[
https://issues.apache.org/jira/browse/IGNITE-15818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ivan Bessonov updated IGNITE-15818:
---
Description:
h2. Goal

Port and refactor core classes implementing page-based persistent store in
Ignite 2.x: GridCacheOffheapManager, GridCacheDatabaseSharedManager,
PageMemoryImpl, Checkpointer, FileWriteAheadLogManager.

New checkpoint implementation to avoid excessive logging.

Store lifecycle clarification to avoid complicated and invasive code of custom
lifecycle managed mostly by DatabaseSharedManager.
h2. Items to pay attention to

New checkpoint implementation based on split-file storage, new page index
structure to maintain disk-memory page mapping.

File page store implementation should be extracted from GridCacheOffheapManager
to a separate entity, target implementation should support new version of
checkpoint (split-file store to enable always-consistent store and to eliminate
binary recovery phase).

Support of big pages (256+ kB).

Support of throttling algorithms.
h2. References

New checkpoint design overview is available
[here|https://github.com/apache/ignite-3/blob/ignite-14647/modules/vault/README.md]
h2. Thoughts

Although there is a technical opportunity to have independent checkpoints for
different data regions, managing them could be a nightmare and it's definitely
in the realm of optimizations and out of scope right now.

So, let's assume that there's one good old checkpoint process. There's still a
requirement to have checkpoint markers, but they will not have a reference to
WAL, because there's no WAL. Instead, we will have to store RAFT log revision
per partition. Or not, I'm not that familiar with a recovery procedure that's
currently in development.

Unlike checkpoints in Ignite 2.x, that had DO and REDO operations, new version
will have DO and UNDO. This drastically simplifies both checkpoint itself and
node recovery. But is complicates data access.

There will be two process that will share storage resource: "checkpointer" and
"compactor". Let's examine what compactor should or shouldn't do:
* it should not work in parallel with checkpointer, except for cases when
there are too many layers (more on that later)
* it should merge later checkpoint delta files into main partition files
* it should delete checkpoint markers once all merges are completed for it,
thus markers are decoupled from RAFT log

About "cases when there are too many layers" - too many layers could compromise
reading speed. Number of layers should not increase uncontrollably. So, when a
threshold is exceeded, compactor should start working no mater what. If
anything, writing load can be throttled, reading matters more.

Recovery procedure:
* read the list of checkpoint markers on engines start
* remove all data from unfinished checkpoint, if it's there
* trim main partition files to their proper size (should check it it's
actually beneficial)

Table start procedure:
* read all layer files headers according to the list of checkpoints
* construct a list oh hash tables (pageId -> pageIndex) for all layers, make
it as effective as possible
* everything else is just like before

Partition removal might be tricky, but we'll see. It's tricky in Ignite 2.x
after all. "Restore partition states" procedure could be revisited, I don't
know how this will work yet.

How to store hashmaps:

regular maps might be too much, we should consider roaring map implementation
or something similar that'll occupy less space. This is only a concern for
in-memory structures. Files on disk may have a list of pairs, that's fine.
Generally speaking, checkpoints with a size of 100 thousand pages are close to
the top limit for most users. Splitting that to 500 partitions, for example,
gives us 200 pages per partition. Entire map should fit into a single page.

The only exception to these calculations is index.bin. Amount of pages per
checkpoint can be an orders of magnitudes higher, so we should keep an eye on
it, It'll be the main target for testing/benchmarking. Anyway, 4 kilobytes is
enough to fit 512 integer pairs, scaling to 2048 for regular 16 kilobytes
pages. Map won't be too big IMO.

Another important moment - we should enable direct IO, it's supported by Java
natively since version 9 (I guess). There's a chance that not only regular disk
operations will become somewhat faster, but fsync will become drastically
faster as a result. Which is good, fsync can easily take half a time of the
checkpoint, which is just unacceptable.

was:
h2. Goal

Port and refactor core classes implementing page-based persistent store in
Ignite 2.x: GridCacheOffheapManager, GridCacheDatabaseSharedManager,
PageMemoryImpl, Checkpointer, FileWriteAheadLogManager.

New checkpoint implementation to avoid excessive logging.

Store lifecycle clarification to avoid complicated and invasive code of custom
li

[jira] [Updated] (IGNITE-15818) [Native Persistence 3.0] Checkpoint, lifecycle and file store refactoring and re-implementation

2022-02-17 Thread Ivan Bessonov (Jira)

[
https://issues.apache.org/jira/browse/IGNITE-15818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ivan Bessonov updated IGNITE-15818:
---
Description:
h2. Goal

Port and refactor core classes implementing page-based persistent store in
Ignite 2.x: GridCacheOffheapManager, GridCacheDatabaseSharedManager,
PageMemoryImpl, Checkpointer, FileWriteAheadLogManager.

New checkpoint implementation to avoid excessive logging.

Store lifecycle clarification to avoid complicated and invasive code of custom
lifecycle managed mostly by DatabaseSharedManager.
h2. Items to pay attention to

New checkpoint implementation based on split-file storage, new page index
structure to maintain disk-memory page mapping.

Support of big pages (256+ kB).

Support of throttling algorithms.
h2. References

New checkpoint design overview is available
[here|https://github.com/apache/ignite-3/blob/ignite-14647/modules/vault/README.md]
h2. Thoughts

Partition removal might be tricky, but we'll see. It's tricky in Ignite 2.x
after all. "Restore partition states" procedure could be revisited, I don't
know how this will work yet.

How to store hashmaps:

Another important moment - we should enable direct IO, it's supported by Java
natively since version 9 (I guess). There's a chance that not only disk regular
disk operations will become somewhat faster, but fsync will become drastically
faster as a result. Which is good, fsync can easily take half a time of the
checkpoint, which is just unacceptable.

was:
h2. Goal

Port and refactor core classes implementing page-based persistent store in
Ignite 2.x: GridCacheOffheapManager, GridCacheDatabaseSharedManager,
PageMemoryImpl, Checkpointer, FileWriteAheadLogManager.

New checkpoint implementation to avoid excessive logging.

Store lifecycle clarification to avoid complicated and invasive code of custo

[jira] [Updated] (IGNITE-15818) [Native Persistence 3.0] Checkpoint, lifecycle and file store refactoring and re-implementation

2022-02-17 Thread Ivan Bessonov (Jira)

[
https://issues.apache.org/jira/browse/IGNITE-15818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ivan Bessonov updated IGNITE-15818:
---
Description:
h2. Goal

Port and refactor core classes implementing page-based persistent store in
Ignite 2.x: GridCacheOffheapManager, GridCacheDatabaseSharedManager,
PageMemoryImpl, Checkpointer, FileWriteAheadLogManager.

New checkpoint implementation to avoid excessive logging.

Store lifecycle clarification to avoid complicated and invasive code of custom
lifecycle managed mostly by DatabaseSharedManager.
h2. Items to pay attention to

New checkpoint implementation based on split-file storage, new page index
structure to maintain disk-memory page mapping.

Support of big pages (256+ kB).

Support of throttling algorithms.
h2. References

New checkpoint design overview is available
[here|https://github.com/apache/ignite-3/blob/ignite-14647/modules/vault/README.md]
h2. Thoughts

Partition removal might be tricky, but we'll see. It's tricky in Ignite 2.x
after all. "Restore partition states" procedure could be revisited, I don't
know how this will work yet.

How to store hashmaps:

was:
h2. Goal

Port and refactor core classes implementing page-based persistent store in
Ignite 2.x: GridCacheOffheapManager, GridCacheDatabaseSharedManager,
PageMemoryImpl, Checkpointer, FileWriteAheadLogManager.

New checkpoint implementation to avoid excessive logging.

Store lifecycle clarification to avoid complicated and invasive code of custom
lifecycle managed mostly by DatabaseSharedManager.
h2. Items to pay attention to

New checkpoint implementation based on split-file storage, new page index
structure to maintain disk-memory page mapping.

File page store implementation should be extracted from GridCacheOffheapManager
to a separate entity, target implementation should support new versi

[jira] [Assigned] (IGNITE-16010) setBaseline method must write new baseline to metastore

2022-02-17 Thread Mirza Aliev (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-16010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mirza Aliev reassigned IGNITE-16010:


Assignee: Mirza Aliev

> setBaseline method must write new baseline to metastore
> ---
>
> Key: IGNITE-16010
> URL: https://issues.apache.org/jira/browse/IGNITE-16010
> Project: Ignite
>  Issue Type: Task
>Reporter: Kirill Gusakov
>Assignee: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
>
> Current org.apache.ignite.Ignite#setBaseline method updates assignments 
> directly and does not save baseline as a separate source of truth anywhere.
> Instead, it should store new baseline configuration to metastore (in future 
> it can be baseline per table). This metastore key update will be a trigger 
> for listeners to update appropriate assignments.
> This approach provides the generalized way of baseline changing and further 
> processing of this event by rebalancing the algorithm, for example.
>  
> (Phase1)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-16569) PersistenceUpgradeTest ducktest fails if SSL is enabled