[jira] [Updated] (IGNITE-20974) It seems a row has been skipped by the removal operation
[
https://issues.apache.org/jira/browse/IGNITE-20974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20974:
---
Description:
h3. Motivation
This issue has happened in TC, but it is very rare, and it is related to a
multi-node cluster only (TC log was attached). Look at the exception for
ItTxDistributedTestThreeNodesThreeReplicas.testComplexImplicit:
{noformat}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertNull.failNotNull(AssertNull.java:50)
at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:35)
at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:30)
at app//org.junit.jupiter.api.Assertions.assertNull(Assertions.java:276)
at
app//org.apache.ignite.internal.table.TxAbstractTest.doTestComplex(TxAbstractTest.java:1450)
at
app//org.apache.ignite.internal.table.TxAbstractTest.testComplexImplicit(TxAbstractTest.java:1354)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
{noformat}
The assertion failed exception is here (in line 6):
{code:title=TxAbstractTest.java}
view.deleteAll(tx, keys);
for (Tuple key : keys) {
Tuple entry = view.get(tx, key);
assertNull(entry);
}
{code}
h3. Implementation notes
Check that the result of the _deleteAll_ operation is an empty collection.
was:
This issue has happened in TC, but it is very rare, and it is related to a
multi-node cluster only (TC log was attached). Look at the exception for
ItTxDistributedTestThreeNodesThreeReplicas.testComplexImplicit:
{noformat}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertNull.failNotNull(AssertNull.java:50)
at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:35)
at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:30)
at app//org.junit.jupiter.api.Assertions.assertNull(Assertions.java:276)
at
app//org.apache.ignite.internal.table.TxAbstractTest.doTestComplex(TxAbstractTest.java:1450)
at
app//org.apache.ignite.internal.table.TxAbstractTest.testComplexImplicit(TxAbstractTest.java:1354)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
{noformat}
> It seems a row has been skipped by the removal operation
>
>
> Key: IGNITE-20974
> URL: https://issues.apache.org/jira/browse/IGNITE-20974
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Table_17003.log.zip
>
>
> h3. Motivation
> This issue has happened in TC, but it is very rare, and it is related to a
> multi-node cluster only (TC log was attached). Look at the exception for
> ItTxDistributedTestThreeNodesThreeReplicas.testComplexImplicit:
> {noformat}
> org.opentest4j.AssertionFailedError: expected: but was:
>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertNull.failNotNull(AssertNull.java:50)
> at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:35)
> at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:30)
> at app//org.junit.jupiter.api.Assertions.assertNull(Assertions.java:276)
> at
> app//org.apache.ignite.internal.table.TxAbstractTest.doTestComplex(TxAbstractTest.java:1450)
> at
> app//org.apache.ignite.internal.table.TxAbstractTest.testComplexImplicit(TxAbstractTest.java:1354)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
>
[jira] [Created] (IGNITE-20974) It seems a row has been skipped by the removal operation
Vladislav Pyatkov created IGNITE-20974:
--
Summary: It seems a row has been skipped by the removal operation
Key: IGNITE-20974
URL: https://issues.apache.org/jira/browse/IGNITE-20974
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
Attachments: _Integration_Tests_Module_Table_17003.log.zip
This issue has happened in TC, but it is very rare, and it is related to a
multi-node cluster only (TC log was attached). Look at the exception for
ItTxDistributedTestThreeNodesThreeReplicas.testComplexImplicit:
{noformat}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertNull.failNotNull(AssertNull.java:50)
at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:35)
at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:30)
at app//org.junit.jupiter.api.Assertions.assertNull(Assertions.java:276)
at
app//org.apache.ignite.internal.table.TxAbstractTest.doTestComplex(TxAbstractTest.java:1450)
at
app//org.apache.ignite.internal.table.TxAbstractTest.testComplexImplicit(TxAbstractTest.java:1354)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20973) Unusable thin client timeout
Egor Fomin created IGNITE-20973: --- Summary: Unusable thin client timeout Key: IGNITE-20973 URL: https://issues.apache.org/jira/browse/IGNITE-20973 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 2.16, 2.17 Reporter: Egor Fomin Ignite thin client currently uses the same timeout value for request timeout and connection timeout. Connection timeout should be small enough(several seconds) while request timeout should be able to handle long running requests. This makes Ignite timeout unusable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20972) Move handlers of zone-related commands from CatalogManager
Konstantin Orlov created IGNITE-20972: - Summary: Move handlers of zone-related commands from CatalogManager Key: IGNITE-20972 URL: https://issues.apache.org/jira/browse/IGNITE-20972 Project: Ignite Issue Type: Improvement Reporter: Konstantin Orlov As described in IGNITE-20284, we need to restructure code to improve code locality and avoid conflict when introducing new commands in future. Under this ticket let's address zone-related commands. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20878) Basic criteria queries for record view
[
https://issues.apache.org/jira/browse/IGNITE-20878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov updated IGNITE-20878:
Summary: Basic criteria queries for record view (was: Basic criteria
queries)
> Basic criteria queries for record view
> --
>
> Key: IGNITE-20878
> URL: https://issues.apache.org/jira/browse/IGNITE-20878
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement basic criteria query for record view.
> The only field in {{CreteriaQueryOptions}} should be {{{}pageSize{}}}.
> Criteria to implement: equals
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20878) Basic criteria queries
[
https://issues.apache.org/jira/browse/IGNITE-20878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov updated IGNITE-20878:
Description:
Implement basic criteria query for record view.
The only field in {{CreteriaQueryOptions}} should be {{{}pageSize{}}}.
Criteria to implement: equals
was:
Implement basic criteria query. The only field in {{CreteriaQueryOptions}}
should be {{{}pageSize{}}}.
Criteria to implement: equals
> Basic criteria queries
> --
>
> Key: IGNITE-20878
> URL: https://issues.apache.org/jira/browse/IGNITE-20878
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement basic criteria query for record view.
> The only field in {{CreteriaQueryOptions}} should be {{{}pageSize{}}}.
> Criteria to implement: equals
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20958) PersistentPageMemoryMvPartitionStorageTest#groupConfigShorteningWorksCorrectly threw an AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-20958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-20958:
-
Fix Version/s: 3.0.0-beta2
> PersistentPageMemoryMvPartitionStorageTest#groupConfigShorteningWorksCorrectly
> threw an AssertionError
> --
>
> Key: IGNITE-20958
> URL: https://issues.apache.org/jira/browse/IGNITE-20958
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Kirill Tkalenko
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Failed build:
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunUnitTests/7650826
> {noformat}
> [2023-11-23T19:08:47,351][WARN ][%test%compaction-thread-425][Compactor]
> Runtime error caught during ignite runnable execution [worker=IgniteWorker
> [name=compaction-thread, igniteInstanceName=test, listener=null,
> finished=false, heartbeatTimestamp=1700766527341, hashCode=1964034487,
> interrupted=false, runner=%test%compaction-thread-425]]
> org.apache.ignite.internal.lang.IgniteInternalException:
> java.lang.AssertionError: pageIdx=1, pageCount=0
> at
> org.apache.ignite.internal.pagememory.persistence.compaction.Compactor.body(Compactor.java:140)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.worker.IgniteWorker.run(IgniteWorker.java:108)
> [ignite-core-3.0.0-SNAPSHOT.jar:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.util.concurrent.CompletionException:
> java.lang.AssertionError: pageIdx=1, pageCount=0
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$BiRelay.tryFire(CompletableFuture.java:1423)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> ~[?:?]
> at
> org.apache.ignite.internal.pagememory.persistence.compaction.Compactor.lambda$doCompaction$1(Compactor.java:241)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> ... 1 more
> Caused by: java.lang.AssertionError: pageIdx=1, pageCount=0
> at
> org.apache.ignite.internal.pagememory.persistence.store.FilePageStore.write(FilePageStore.java:194)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.persistence.compaction.Compactor.mergeDeltaFileToMainFile(Compactor.java:373)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.persistence.compaction.Compactor.lambda$doCompaction$1(Compactor.java:235)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> ... 1 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20926) Update Apache Ignite 2.16 release notes
[ https://issues.apache.org/jira/browse/IGNITE-20926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-20926: - Ignite Flags: (was: Docs Required,Release Notes Required) > Update Apache Ignite 2.16 release notes > --- > > Key: IGNITE-20926 > URL: https://issues.apache.org/jira/browse/IGNITE-20926 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Update Apache Ignite 2.16 release notes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19722) ODBC 3.0: Implement basic authentication
[ https://issues.apache.org/jira/browse/IGNITE-19722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790236#comment-17790236 ] Igor Sapego commented on IGNITE-19722: -- Left few comments in PR. > ODBC 3.0: Implement basic authentication > > > Key: IGNITE-19722 > URL: https://issues.apache.org/jira/browse/IGNITE-19722 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Igor Sapego >Assignee: Dmitrii Zabotlin >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > Implement basic authentication for ODBC driver, supporting basic USER and > PASSWORD (SECRET?) parameters in connection string. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19722) ODBC 3.0: Implement basic authentication
[ https://issues.apache.org/jira/browse/IGNITE-19722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790222#comment-17790222 ] Dmitrii Zabotlin commented on IGNITE-19722: --- [~isapego] Ca you please review? > ODBC 3.0: Implement basic authentication > > > Key: IGNITE-19722 > URL: https://issues.apache.org/jira/browse/IGNITE-19722 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Igor Sapego >Assignee: Dmitrii Zabotlin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Implement basic authentication for ODBC driver, supporting basic USER and > PASSWORD (SECRET?) parameters in connection string. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-19722) ODBC 3.0: Implement basic authentication
[ https://issues.apache.org/jira/browse/IGNITE-19722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790222#comment-17790222 ] Dmitrii Zabotlin edited comment on IGNITE-19722 at 11/27/23 6:56 PM: - [~isapego] Can you please review? was (Author: JIRAUSER298949): [~isapego] Ca you please review? > ODBC 3.0: Implement basic authentication > > > Key: IGNITE-19722 > URL: https://issues.apache.org/jira/browse/IGNITE-19722 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Igor Sapego >Assignee: Dmitrii Zabotlin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Implement basic authentication for ODBC driver, supporting basic USER and > PASSWORD (SECRET?) parameters in connection string. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19722) ODBC 3.0: Implement basic authentication
[ https://issues.apache.org/jira/browse/IGNITE-19722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitrii Zabotlin reassigned IGNITE-19722: - Assignee: Dmitrii Zabotlin (was: Igor Sapego) > ODBC 3.0: Implement basic authentication > > > Key: IGNITE-19722 > URL: https://issues.apache.org/jira/browse/IGNITE-19722 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Igor Sapego >Assignee: Dmitrii Zabotlin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Implement basic authentication for ODBC driver, supporting basic USER and > PASSWORD (SECRET?) parameters in connection string. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20971) The Ignite process quietly tear down while creating a lot of tables
[ https://issues.apache.org/jira/browse/IGNITE-20971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor updated IGNITE-20971: -- Description: Creating 1000 tables with 5 column each. *Expected:* 1000 tables are created. *Actual:* After some tables (in my case after 75 tables) the Ignite runner process is silently teared down, no any errors in output. GC log doesn't show any problem. *Additional information:* On more performant (in CPU) servers it can create up to 855 tables on 4GB HEAP and then tearing down with `java.lang.OutOfMemoryError: Java heap space` was: Creating 1000 tables with 5 column each. Expected: 1000 tables are created. Actual: After some tables (in my case after 75 tables) the Ignite runner process is silently teared down, no any errors in output. GC log doesn't show any problem. Additional information: On more performant (in CPU) servers it can create up to 855 tables on 4GB HEAP and then tearing down with `java.lang.OutOfMemoryError: Java heap space` > The Ignite process quietly tear down while creating a lot of tables > --- > > Key: IGNITE-20971 > URL: https://issues.apache.org/jira/browse/IGNITE-20971 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 3.0.0-beta2 >Reporter: Igor >Priority: Major > Labels: ignite-3 > > Creating 1000 tables with 5 column each. > *Expected:* > 1000 tables are created. > > *Actual:* > After some tables (in my case after 75 tables) the Ignite runner process is > silently teared down, no any errors in output. GC log doesn't show any > problem. > > *Additional information:* > On more performant (in CPU) servers it can create up to 855 tables on 4GB > HEAP and then tearing down with > `java.lang.OutOfMemoryError: Java heap space` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20971) The Ignite process quietly tear down while creating a lot of tables
[ https://issues.apache.org/jira/browse/IGNITE-20971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor updated IGNITE-20971: -- Description: Creating 1000 tables with 5 column each. Expected: 1000 tables are created. Actual: After some tables (in my case after 75 tables) the Ignite runner process is silently teared down, no any errors in output. GC log doesn't show any problem. Additional information: On more performant (in CPU) servers it can create up to 855 tables on 4GB HEAP and then tearing down with `java.lang.OutOfMemoryError: Java heap space` was: Creating 1000 tables with 5 column each. Expected: 1000 tables are created. Actual: After some tables (in my case after 75 tables) the Ignite runner process is silently teared down, no any errors in output. GC log doesn't show any problem. > The Ignite process quietly tear down while creating a lot of tables > --- > > Key: IGNITE-20971 > URL: https://issues.apache.org/jira/browse/IGNITE-20971 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 3.0.0-beta2 >Reporter: Igor >Priority: Major > Labels: ignite-3 > > Creating 1000 tables with 5 column each. > Expected: > 1000 tables are created. > > Actual: > After some tables (in my case after 75 tables) the Ignite runner process is > silently teared down, no any errors in output. GC log doesn't show any > problem. > > Additional information: > On more performant (in CPU) servers it can create up to 855 tables on 4GB > HEAP and then tearing down with > `java.lang.OutOfMemoryError: Java heap space` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20971) The Ignite process quietly tear down while creating a lot of tables
Igor created IGNITE-20971: - Summary: The Ignite process quietly tear down while creating a lot of tables Key: IGNITE-20971 URL: https://issues.apache.org/jira/browse/IGNITE-20971 Project: Ignite Issue Type: Bug Components: general Affects Versions: 3.0.0-beta2 Reporter: Igor Creating 1000 tables with 5 column each. Expected: 1000 tables are created. Actual: After some tables (in my case after 75 tables) the Ignite runner process is silently teared down, no any errors in output. GC log doesn't show any problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20904) MQ API caused the systemview to be unavailable.
[
https://issues.apache.org/jira/browse/IGNITE-20904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-20904:
-
Fix Version/s: (was: 2.16)
> MQ API caused the systemview to be unavailable.
> ---
>
> Key: IGNITE-20904
> URL: https://issues.apache.org/jira/browse/IGNITE-20904
> Project: Ignite
> Issue Type: Bug
> Components: messaging
>Affects Versions: 2.15
>Reporter: yafengshi
>Assignee: yafengshi
>Priority: Critical
> Labels: newbie
> Fix For: 3.0, 2.17
>
> Original Estimate: 1h
> Time Spent: 10m
> Remaining Estimate: 50m
>
>
> After I execute the following code, I want to query system views.
> {code:java}
> ignite.message(ignite.cluster().forServers()).remoteListen("A1", (nodeId,
> msg) -> {
> System.out.println(msg);
> return true;
> });
>
> for (int i = 0; i < 10; i++)
> ignite.message().sendOrdered("A1", Integer.toString(i),0); {code}
>
> then it threw an IllegalStateException.
> {code:java}
> jdbc:ignite:thin://127.0.0.1/sys> select count(1) from CONTINUOUS_QUERIES;
> Error: General error: "java.lang.IllegalStateException"; {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20917) Add entry version in the DumpEntry
[
https://issues.apache.org/jira/browse/IGNITE-20917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790052#comment-17790052
]
Nikolay Izhikov commented on IGNITE-20917:
--
cherry-picked to 2.16
> Add entry version in the DumpEntry
> --
>
> Key: IGNITE-20917
> URL: https://issues.apache.org/jira/browse/IGNITE-20917
> Project: Ignite
> Issue Type: Task
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-109, ise
> Fix For: 2.16
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{DumpEntry}} must contains entry version.
> * Entry version is the same for every copy of the enty.
> * Entry version can be used to recover CDC state after CDC based replication
> implemented in cdc-ext fails for some reason.
> Use-case:
> * cdc replication fails.
> * backup cluster cleared.
> * starts cdc -> changes replicated to the backup cluster.
> * create dump on the primary cluster.
> * restore dump on the backup cluster with the {{putConflict}} calls.
> Goal of this ticket is to add version to the {{DumpEntry}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20836) Support zipping of dump files
[ https://issues.apache.org/jira/browse/IGNITE-20836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790051#comment-17790051 ] Nikolay Izhikov commented on IGNITE-20836: -- cherry-picked to 2.16 > Support zipping of dump files > - > > Key: IGNITE-20836 > URL: https://issues.apache.org/jira/browse/IGNITE-20836 > Project: Ignite > Issue Type: Task >Reporter: Yuri Naryshkin >Assignee: Yuri Naryshkin >Priority: Major > Labels: IEP-109, ise > Fix For: 2.16 > > Time Spent: 8h 50m > Remaining Estimate: 0h > > For additional space saving, need to introduce a mode in which dump files are > compressed during the creation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20875) Add enlistment consistency token to PrimaryReplicaRequest interface
[ https://issues.apache.org/jira/browse/IGNITE-20875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-20875: --- Reviewer: Alexander Lapin > Add enlistment consistency token to PrimaryReplicaRequest interface > --- > > Key: IGNITE-20875 > URL: https://issues.apache.org/jira/browse/IGNITE-20875 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > The procedure in the method PartitionReplicaListener#ensureReplicaIsPrimary > looks not simple because we have no interface that provides the enlistment > consistency id. But PrimaryReplicaRequest well-suited for the role because it > is used to determine messages targeted at the primary replica. > h3. Definition of done > All messages that are certain to the primary replica should include the > PrimaryReplicaTestRequest interface. The interface should have the enlistment > consistency token internally. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20967) .NET: Thin 3.0: TestMicrosoftConsoleLogger is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-20967:
Ignite Flags: (was: Docs Required,Release Notes Required)
> .NET: Thin 3.0: TestMicrosoftConsoleLogger is flaky
> ---
>
> Key: IGNITE-20967
> URL: https://issues.apache.org/jira/browse/IGNITE-20967
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Thread safety issues lead to occasional exceptions:
> {code}
> System.ArgumentOutOfRangeException : Index was out of range. Must be
> non-negative and less than the size of the collection. (Parameter
> 'chunkLength')
>at System.Text.StringBuilder.ToString()
>at Apache.Ignite.Tests.LoggingTests.TestMicrosoftConsoleLogger() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/LoggingTests.cs:line
> 87
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TimeoutCommand.<>c__DisplayClass5_0.b__0()
>at System.Threading.Tasks.Task`1.InnerInvoke()
>at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread
> threadPoolThread, ExecutionContext executionContext, ContextCallback
> callback, Object state)
> --- End of stack trace from previous location ---
>at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task&
> currentTaskSlot, Thread threadPoolThread)
> --- End of stack trace from previous location ---
>at
> NUnit.Framework.Internal.Commands.TimeoutCommand.Execute(TestExecutionContext
> context)
> {code}
> We should synchronize the access to the underlying StringBuilder.
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7656452?hideProblemsFromDependencies=false=false=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20962) .NET: Thin 3.0: TestAuthnOnClientNoAuthnOnServer is flaky
[ https://issues.apache.org/jira/browse/IGNITE-20962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20962: Ignite Flags: (was: Docs Required,Release Notes Required) > .NET: Thin 3.0: TestAuthnOnClientNoAuthnOnServer is flaky > - > > Key: IGNITE-20962 > URL: https://issues.apache.org/jira/browse/IGNITE-20962 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > *TestAuthnOnClientNoAuthnOnServer* is flaky. Reproduces locally when entire > *BasicAuthenticatorTests* is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20967) .NET: Thin 3.0: TestMicrosoftConsoleLogger is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790037#comment-17790037
]
Pavel Tupitsyn commented on IGNITE-20967:
-
Merged to main: 4d32d57470aaaccc8857717a99a0ac3620f00c7a
> .NET: Thin 3.0: TestMicrosoftConsoleLogger is flaky
> ---
>
> Key: IGNITE-20967
> URL: https://issues.apache.org/jira/browse/IGNITE-20967
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Thread safety issues lead to occasional exceptions:
> {code}
> System.ArgumentOutOfRangeException : Index was out of range. Must be
> non-negative and less than the size of the collection. (Parameter
> 'chunkLength')
>at System.Text.StringBuilder.ToString()
>at Apache.Ignite.Tests.LoggingTests.TestMicrosoftConsoleLogger() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/LoggingTests.cs:line
> 87
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TimeoutCommand.<>c__DisplayClass5_0.b__0()
>at System.Threading.Tasks.Task`1.InnerInvoke()
>at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread
> threadPoolThread, ExecutionContext executionContext, ContextCallback
> callback, Object state)
> --- End of stack trace from previous location ---
>at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task&
> currentTaskSlot, Thread threadPoolThread)
> --- End of stack trace from previous location ---
>at
> NUnit.Framework.Internal.Commands.TimeoutCommand.Execute(TestExecutionContext
> context)
> {code}
> We should synchronize the access to the underlying StringBuilder.
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7656452?hideProblemsFromDependencies=false=false=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20836) Support zipping of dump files
[ https://issues.apache.org/jira/browse/IGNITE-20836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20836: - Fix Version/s: 2.16 (was: 2.17) > Support zipping of dump files > - > > Key: IGNITE-20836 > URL: https://issues.apache.org/jira/browse/IGNITE-20836 > Project: Ignite > Issue Type: Task >Reporter: Yuri Naryshkin >Assignee: Yuri Naryshkin >Priority: Major > Labels: IEP-109, ise > Fix For: 2.16 > > Time Spent: 8h 50m > Remaining Estimate: 0h > > For additional space saving, need to introduce a mode in which dump files are > compressed during the creation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20962) .NET: Thin 3.0: TestAuthnOnClientNoAuthnOnServer is flaky
[ https://issues.apache.org/jira/browse/IGNITE-20962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790036#comment-17790036 ] Pavel Tupitsyn commented on IGNITE-20962: - Merged to main: 7a38a221abb39418ed9925d1c6f8185dfbe4300c > .NET: Thin 3.0: TestAuthnOnClientNoAuthnOnServer is flaky > - > > Key: IGNITE-20962 > URL: https://issues.apache.org/jira/browse/IGNITE-20962 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > *TestAuthnOnClientNoAuthnOnServer* is flaky. Reproduces locally when entire > *BasicAuthenticatorTests* is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20920) .NET: TestPutRoutesRequestToPrimaryNode is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790035#comment-17790035
]
Pavel Tupitsyn commented on IGNITE-20920:
-
Merged to main: f8ebf08333424aeb813b043457490e54f61656c0
> .NET: TestPutRoutesRequestToPrimaryNode is flaky
>
>
> Key: IGNITE-20920
> URL: https://issues.apache.org/jira/browse/IGNITE-20920
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *PartitionAwarenessRealClusterTests.TestPutRoutesRequestToPrimaryNode* is
> flaky.
> Test history:
> https://ci.ignite.apache.org/test/6220606330906984960?currentProjectId=ApacheIgnite3xGradle_Test=true
> Error:
> {code}
> Apache.Ignite.IgniteClientConnectionException : Exception while reading from
> socket, connection closed: Connection lost (failed to read data from socket)
> > Apache.Ignite.IgniteClientConnectionException : Connection lost
> (failed to read data from socket)
> > System.Net.Sockets.SocketException : Software caused connection abort
>at
> Apache.Ignite.Internal.ClientFailoverSocket.DoOutInOpAndGetSocketAsync(ClientOp
> clientOp, Transaction tx, PooledArrayBuffer request, PreferredNode
> preferredNode, IRetryPolicy retryPolicyOverride) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientFailoverSocket.cs:line
> 195
>at Apache.Ignite.Internal.Table.RecordView`1.DoOutInOpAsync(ClientOp
> clientOp, Transaction tx, PooledArrayBuffer request, PreferredNode
> preferredNode, IRetryPolicy retryPolicyOverride) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/RecordView.cs:line
> 400
>at Apache.Ignite.Internal.Table.RecordView`1.DoRecordOutOpAsync(ClientOp
> op, ITransaction transaction, T record, Boolean keyOnly, Nullable`1
> schemaVersionOverride) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/RecordView.cs:line
> 425
>at Apache.Ignite.Internal.Table.RecordView`1.UpsertAsync(ITransaction
> transaction, T record) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/RecordView.cs:line
> 172
>at
> Apache.Ignite.Tests.PartitionAwarenessRealClusterTests.TestPutRoutesRequestToPrimaryNode()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/PartitionAwarenessRealClusterTests.cs:line
> 65
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.BeforeAndAfterTestCommand.<>c__DisplayClass1_0.b__0()
>at
> NUnit.Framework.Internal.Commands.DelegatingTestCommand.RunTestMethodInThreadAbortSafeZone(TestExecutionContext
> context, Action action)
> --IgniteClientConnectionException
>at Apache.Ignite.Internal.ClientSocket.ReceiveBytesAsync(Stream stream,
> Byte[] buffer, Int32 size, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientSocket.cs:line
> 498
>at Apache.Ignite.Internal.ClientSocket.ReadMessageSizeAsync(Stream stream,
> Byte[] buffer, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientSocket.cs:line
> 478
>at Apache.Ignite.Internal.ClientSocket.ReadResponseAsync(Stream stream,
> Byte[] messageSizeBytes, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientSocket.cs:line
> 452
>at Apache.Ignite.Internal.ClientSocket.RunReceiveLoop(CancellationToken
> cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientSocket.cs:line
> 700
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20542) Broken link ignite.apache.org..RestAPI → github.com...openapi.yaml
[ https://issues.apache.org/jira/browse/IGNITE-20542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev resolved IGNITE-20542. - Resolution: Fixed Fixed with a different doc update. > Broken link ignite.apache.org..RestAPI → github.com...openapi.yaml > -- > > Key: IGNITE-20542 > URL: https://issues.apache.org/jira/browse/IGNITE-20542 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Minor > Labels: ignite-3 > > [Rest API|https://ignite.apache.org/docs/3.0.0-beta/rest/rest-api] page > contains broken link to the > [openapi.yaml|https://github.com/apache/ignite-3/tree/main/modules/rest/openapi/openapi.yaml] > Correct one seems to be > [openapi.yaml|https://github.com/apache/ignite-3/blob/main/modules/rest-api/openapi/openapi.yaml] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20962) .NET: Thin 3.0: TestAuthnOnClientNoAuthnOnServer is flaky
[ https://issues.apache.org/jira/browse/IGNITE-20962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790029#comment-17790029 ] Igor Sapego commented on IGNITE-20962: -- Looks good to me. > .NET: Thin 3.0: TestAuthnOnClientNoAuthnOnServer is flaky > - > > Key: IGNITE-20962 > URL: https://issues.apache.org/jira/browse/IGNITE-20962 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > *TestAuthnOnClientNoAuthnOnServer* is flaky. Reproduces locally when entire > *BasicAuthenticatorTests* is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20967) .NET: Thin 3.0: TestMicrosoftConsoleLogger is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790030#comment-17790030
]
Igor Sapego commented on IGNITE-20967:
--
Looks good to me.
> .NET: Thin 3.0: TestMicrosoftConsoleLogger is flaky
> ---
>
> Key: IGNITE-20967
> URL: https://issues.apache.org/jira/browse/IGNITE-20967
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Thread safety issues lead to occasional exceptions:
> {code}
> System.ArgumentOutOfRangeException : Index was out of range. Must be
> non-negative and less than the size of the collection. (Parameter
> 'chunkLength')
>at System.Text.StringBuilder.ToString()
>at Apache.Ignite.Tests.LoggingTests.TestMicrosoftConsoleLogger() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/LoggingTests.cs:line
> 87
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TimeoutCommand.<>c__DisplayClass5_0.b__0()
>at System.Threading.Tasks.Task`1.InnerInvoke()
>at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread
> threadPoolThread, ExecutionContext executionContext, ContextCallback
> callback, Object state)
> --- End of stack trace from previous location ---
>at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task&
> currentTaskSlot, Thread threadPoolThread)
> --- End of stack trace from previous location ---
>at
> NUnit.Framework.Internal.Commands.TimeoutCommand.Execute(TestExecutionContext
> context)
> {code}
> We should synchronize the access to the underlying StringBuilder.
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7656452?hideProblemsFromDependencies=false=false=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20920) .NET: TestPutRoutesRequestToPrimaryNode is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790028#comment-17790028
]
Igor Sapego commented on IGNITE-20920:
--
Looks good to me.
> .NET: TestPutRoutesRequestToPrimaryNode is flaky
>
>
> Key: IGNITE-20920
> URL: https://issues.apache.org/jira/browse/IGNITE-20920
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *PartitionAwarenessRealClusterTests.TestPutRoutesRequestToPrimaryNode* is
> flaky.
> Test history:
> https://ci.ignite.apache.org/test/6220606330906984960?currentProjectId=ApacheIgnite3xGradle_Test=true
> Error:
> {code}
> Apache.Ignite.IgniteClientConnectionException : Exception while reading from
> socket, connection closed: Connection lost (failed to read data from socket)
> > Apache.Ignite.IgniteClientConnectionException : Connection lost
> (failed to read data from socket)
> > System.Net.Sockets.SocketException : Software caused connection abort
>at
> Apache.Ignite.Internal.ClientFailoverSocket.DoOutInOpAndGetSocketAsync(ClientOp
> clientOp, Transaction tx, PooledArrayBuffer request, PreferredNode
> preferredNode, IRetryPolicy retryPolicyOverride) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientFailoverSocket.cs:line
> 195
>at Apache.Ignite.Internal.Table.RecordView`1.DoOutInOpAsync(ClientOp
> clientOp, Transaction tx, PooledArrayBuffer request, PreferredNode
> preferredNode, IRetryPolicy retryPolicyOverride) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/RecordView.cs:line
> 400
>at Apache.Ignite.Internal.Table.RecordView`1.DoRecordOutOpAsync(ClientOp
> op, ITransaction transaction, T record, Boolean keyOnly, Nullable`1
> schemaVersionOverride) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/RecordView.cs:line
> 425
>at Apache.Ignite.Internal.Table.RecordView`1.UpsertAsync(ITransaction
> transaction, T record) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/RecordView.cs:line
> 172
>at
> Apache.Ignite.Tests.PartitionAwarenessRealClusterTests.TestPutRoutesRequestToPrimaryNode()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/PartitionAwarenessRealClusterTests.cs:line
> 65
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.BeforeAndAfterTestCommand.<>c__DisplayClass1_0.b__0()
>at
> NUnit.Framework.Internal.Commands.DelegatingTestCommand.RunTestMethodInThreadAbortSafeZone(TestExecutionContext
> context, Action action)
> --IgniteClientConnectionException
>at Apache.Ignite.Internal.ClientSocket.ReceiveBytesAsync(Stream stream,
> Byte[] buffer, Int32 size, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientSocket.cs:line
> 498
>at Apache.Ignite.Internal.ClientSocket.ReadMessageSizeAsync(Stream stream,
> Byte[] buffer, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientSocket.cs:line
> 478
>at Apache.Ignite.Internal.ClientSocket.ReadResponseAsync(Stream stream,
> Byte[] messageSizeBytes, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientSocket.cs:line
> 452
>at Apache.Ignite.Internal.ClientSocket.RunReceiveLoop(CancellationToken
> cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientSocket.cs:line
> 700
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20762) Unable to create table in a specific zone
[
https://issues.apache.org/jira/browse/IGNITE-20762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-20762.
Resolution: Not A Problem
It looks not a problem due to we uppercase (to have case-insensitive) all
identifiers in SQ.
so after create zone fz you have name FZ, but when you try to use the zone you
use quoted identifier, which not uppercases. So you should use or uppercased
quote identifier or don't use quotes.
> Unable to create table in a specific zone
> -
>
> Key: IGNITE-20762
> URL: https://issues.apache.org/jira/browse/IGNITE-20762
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Major
> Labels: ignite-3
>
> Got exception
> [Code: 0, SQL State: 5] Failed to validate query. Distribution zone with
> name 'fz' not found
> on creation a new table in any specific zone:
> {noformat}
> create zone fz engine aipersist;
> >> success
> create table testt3 (id integer not null, val varchar not null, id2 integer
> not null, primary key(id,id2) ) with primary_zone = 'fz';
> >> [Code: 0, SQL State: 5] Failed to validate query. Distribution zone
> >> with name 'fz' not found
> create zone fz engine aipersist;
> >> [Code: 0, SQL State: 5] Distribution zone already exists [zoneName=FZ]
> drop zone fz;
> >> success{noformat}
> Code from the example:
> [https://github.com/apache/ignite-3/blob/main/examples/src/main/java/org/apache/ignite/example/storage/StorageEngineExample.java]
> no matter if the first statement will use any region:
> {noformat}
> create zone fz2 engine aipersist with dataregion = 'asd';
> >> success
> create table testt3 (id integer not null, val varchar not null, id2 integer
> not null, primary key(id,id2) ) with primary_zone = 'fz2';
> >> [Code: 0, SQL State: 5] Failed to validate query. Distribution zone
> >> with name 'fz2' not found{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20737) Idle Verify fails with "Cluster not idle" error when log level is set to DEBUG
[
https://issues.apache.org/jira/browse/IGNITE-20737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-20737:
-
Fix Version/s: 2.17
> Idle Verify fails with "Cluster not idle" error when log level is set to DEBUG
> --
>
> Key: IGNITE-20737
> URL: https://issues.apache.org/jira/browse/IGNITE-20737
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Valery Shorin
>Assignee: Egor Fomin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In case if idle verify executed with DEBUG log level it fails with error:
>
> {code:java}
> Exception: org.apache.ignite.IgniteException Cluster not idle. Modifications
> found in caches or groups: [grpName=default, grpId=1544803905, partId=30]
> changed during size calculation [updCntrBefore=Counter [init=0, val=1],
> updCntrAfter=Counter [init=0, val=1]]
> {code}
>
> This issue can be reproduced by the following test (shoud be added to
> \{{GridCommandHandlerTest}}:
>
> {code:java}
> @Test
> public void testCacheIdleVerifyLogLevelDebug() throws Exception {
> IgniteEx ignite = startGrids(3);
> ignite.cluster().state(ACTIVE);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setAffinity(new RendezvousAffinityFunction(false, 32))
> .setBackups(1));
> cache.put("key", "value");
> injectTestSystemOut();
> setLoggerDebugLevel();
> assertEquals(EXIT_CODE_OK, execute("--cache", "idle_verify"));
> assertContains(log, testOut.toString(), "no conflicts have been found");
> } {code}
>
>
> The reason of this failure - {{equals(}} method is not defined for
> {{PartitionUpdateCounterDebugWrapper}} class
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18758) Clients 3.0: Design server-side metrics
[ https://issues.apache.org/jira/browse/IGNITE-18758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-18758: - Epic Link: IGNITE-18914 > Clients 3.0: Design server-side metrics > --- > > Key: IGNITE-18758 > URL: https://issues.apache.org/jira/browse/IGNITE-18758 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > We need to decide on the list of metrics for the clients in Ignite 3. Result > of this tickets should be a list of metrics and a ticket for their > implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18759) Clients 3.0: Design client-side metrics
[ https://issues.apache.org/jira/browse/IGNITE-18759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-18759: - Epic Link: IGNITE-18914 > Clients 3.0: Design client-side metrics > --- > > Key: IGNITE-18759 > URL: https://issues.apache.org/jira/browse/IGNITE-18759 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Let's consider possibility to add metrics on client side as well. We need to > decide on the list of metrics for the clients in Ignite 3. Result of this > tickets should be a list of metrics and a ticket for their implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-16960) Sql. Script execution using java public API
[ https://issues.apache.org/jira/browse/IGNITE-16960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-16960: - Assignee: Maksim Zhuravkov > Sql. Script execution using java public API > --- > > Key: IGNITE-16960 > URL: https://issues.apache.org/jira/browse/IGNITE-16960 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Andrey Mashenkov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Support script execution using native public Java API. > See Session.executeScript method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20737) Idle Verify fails with "Cluster not idle" error when log level is set to DEBUG
[
https://issues.apache.org/jira/browse/IGNITE-20737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790017#comment-17790017
]
Ignite TC Bot commented on IGNITE-20737:
{panel:title=Branch: [pull/11052/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11052/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility 1{color} [[tests
4|https://ci2.ignite.apache.org/viewLog.html?buildId=7626865]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerWithSslFactoryTest.testCacheIdleVerifyLogLevelDebug[cmdHnd=cli]
- PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerTest.testCacheIdleVerifyLogLevelDebug[cmdHnd=cli] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerTest.testCacheIdleVerifyLogLevelDebug[cmdHnd=jmx] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerWithSslTest.testCacheIdleVerifyLogLevelDebug[cmdHnd=cli] -
PASSED{color}
{color:#8b}Control Utility (Zookeeper){color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7626866]]
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerTest.testCacheIdleVerifyLogLevelDebug[cmdHnd=cli] -
PASSED{color}
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerTest.testCacheIdleVerifyLogLevelDebug[cmdHnd=jmx] -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7627042buildTypeId=IgniteTests24Java8_RunAll]
> Idle Verify fails with "Cluster not idle" error when log level is set to DEBUG
> --
>
> Key: IGNITE-20737
> URL: https://issues.apache.org/jira/browse/IGNITE-20737
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Valery Shorin
>Assignee: Egor Fomin
>Priority: Major
> Labels: ise
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In case if idle verify executed with DEBUG log level it fails with error:
>
> {code:java}
> Exception: org.apache.ignite.IgniteException Cluster not idle. Modifications
> found in caches or groups: [grpName=default, grpId=1544803905, partId=30]
> changed during size calculation [updCntrBefore=Counter [init=0, val=1],
> updCntrAfter=Counter [init=0, val=1]]
> {code}
>
> This issue can be reproduced by the following test (shoud be added to
> \{{GridCommandHandlerTest}}:
>
> {code:java}
> @Test
> public void testCacheIdleVerifyLogLevelDebug() throws Exception {
> IgniteEx ignite = startGrids(3);
> ignite.cluster().state(ACTIVE);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setAffinity(new RendezvousAffinityFunction(false, 32))
> .setBackups(1));
> cache.put("key", "value");
> injectTestSystemOut();
> setLoggerDebugLevel();
> assertEquals(EXIT_CODE_OK, execute("--cache", "idle_verify"));
> assertContains(log, testOut.toString(), "no conflicts have been found");
> } {code}
>
>
> The reason of this failure - {{equals(}} method is not defined for
> {{PartitionUpdateCounterDebugWrapper}} class
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20107) Make table created after tx started visible to the tx
[ https://issues.apache.org/jira/browse/IGNITE-20107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-20107: -- Assignee: Roman Puchkovskiy > Make table created after tx started visible to the tx > - > > Key: IGNITE-20107 > URL: https://issues.apache.org/jira/browse/IGNITE-20107 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: iep-110, ignite-3 > Fix For: 3.0.0-beta2 > > > baseTs is used when validating a schema (schema at commitTs or at operationTs > is validated to match/be compatible to the schema at baseTs). > The easiest way to calculate baseTs is to do baseTs=beginTs(tx). But to make > a created table immediately available for already running transactions (as > per > https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes#IEP110:Schemasynchronization:basicschemachanges-Basicrequirements > ), we can take baseTs=Max(beginTs(tx), creationTs(table)). > This is a temporal solution that will be superseded by IGNITE-20108, but it > seems to make sense to implement it as it is easy to implement (and makes > created tables visible to already running transactions), while IGNITE-20108 > requires substantial work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20917) Add entry version in the DumpEntry
[
https://issues.apache.org/jira/browse/IGNITE-20917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790012#comment-17790012
]
Ignite TC Bot commented on IGNITE-20917:
{panel:title=Branch: [pull/11069/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11069/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Snapshots 3{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7628794]]
* {color:#013220}IgniteSnapshotTestSuite3:
IgniteCacheDumpSelf2Test.testDumpEntryConflictVersion - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7628795buildTypeId=IgniteTests24Java8_RunAll]
> Add entry version in the DumpEntry
> --
>
> Key: IGNITE-20917
> URL: https://issues.apache.org/jira/browse/IGNITE-20917
> Project: Ignite
> Issue Type: Task
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-109, ise
> Fix For: 2.16
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DumpEntry}} must contains entry version.
> * Entry version is the same for every copy of the enty.
> * Entry version can be used to recover CDC state after CDC based replication
> implemented in cdc-ext fails for some reason.
> Use-case:
> * cdc replication fails.
> * backup cluster cleared.
> * starts cdc -> changes replicated to the backup cluster.
> * create dump on the primary cluster.
> * restore dump on the backup cluster with the {{putConflict}} calls.
> Goal of this ticket is to add version to the {{DumpEntry}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20855) Sql. Rework QueryTransactionWrapper to clean up the code.
[
https://issues.apache.org/jira/browse/IGNITE-20855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin resolved IGNITE-20855.
---
Resolution: Duplicate
Must be done in IGNITE-20463
> Sql. Rework QueryTransactionWrapper to clean up the code.
> -
>
> Key: IGNITE-20855
> URL: https://issues.apache.org/jira/browse/IGNITE-20855
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ignite-3
>
> It seems we can clean up the code if we move the code from
> {{wrapTxOrStartImplicit}} to {{QueryTransactionWrapper}}.
> Basically the proposal is:
> * add {{startTxIfNeeded(QueryType)}} non static *void* method to
> {{QueryTransactionWrapper}}, that will be responsible for starting implicit
> transaction and other checks that is now reside in static
> {{wrapTxOrStartImplicit}}.
> * rework QueryTransactionWrapper related tests
> (QueryTransactionWrapperSelfTest, JdbcQueryCursorSelfTest,
> AsyncSqlCursorImplTest)
> This will reduce the amount and complexity of code in SqlQueryProcessor (In
> particular when processing a multi-statements query).
> The task was created based on a comment
> https://github.com/apache/ignite-3/pull/2789#discussion_r1392475145
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20970) Sql. Disallow null dynamic parameters in LIMIT/OFFSET clauses.
[
https://issues.apache.org/jira/browse/IGNITE-20970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20970:
--
Description:
Let's disallow null dynamic parameters in LIMIT/OFFSET clauses. The following
statements should be rejected by SQL validator, because null is not valid value
for limit / offset clause:
{code:java}
sql("SELECT * FROM t LIMIT ?", new Object[]{null});
sql("SELECT * FROM t OFFSET ?", new Object[]{null});
sql("SELECT * FROM t LIMIT ? OFFSET ?", new Object[]{null});
{code}
was:
Let's disallow null dynamic parameters in LIMIT/OFFSET clauses. The following
statements should be rejected by SQL validator, because null is not valid value
for limit / offset clause:
{code:java}
sql("SELECT * FROM t LIMIT ?", new Object{}[null]);
sql("SELECT * FROM t OFFSET ?", new Object{}[null]);
sql("SELECT * FROM t LIMIT ? OFFSET ?", new Object{}[null]);
{code}
> Sql. Disallow null dynamic parameters in LIMIT/OFFSET clauses.
> --
>
> Key: IGNITE-20970
> URL: https://issues.apache.org/jira/browse/IGNITE-20970
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Let's disallow null dynamic parameters in LIMIT/OFFSET clauses. The
> following statements should be rejected by SQL validator, because null is not
> valid value for limit / offset clause:
> {code:java}
> sql("SELECT * FROM t LIMIT ?", new Object[]{null});
> sql("SELECT * FROM t OFFSET ?", new Object[]{null});
> sql("SELECT * FROM t LIMIT ? OFFSET ?", new Object[]{null});
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20970) Sql. Disallow null dynamic parameters in LIMIT/OFFSET clauses.
[
https://issues.apache.org/jira/browse/IGNITE-20970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20970:
--
Description:
Let's disallow null dynamic parameters in LIMIT/OFFSET clauses. The following
statements should be rejected by SQL validator, because null is not valid value
for limit / offset clause:
{code:java}
sql("SELECT * FROM t LIMIT ?", new Object{}[null]);
sql("SELECT * FROM t OFFSET ?", new Object{}[null]);
sql("SELECT * FROM t LIMIT ? OFFSET ?", new Object{}[null]);
{code}
was:
Let's disallow null dynamic parameters in LIMIT/OFFSET clauses.
> Sql. Disallow null dynamic parameters in LIMIT/OFFSET clauses.
> --
>
> Key: IGNITE-20970
> URL: https://issues.apache.org/jira/browse/IGNITE-20970
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Let's disallow null dynamic parameters in LIMIT/OFFSET clauses. The
> following statements should be rejected by SQL validator, because null is not
> valid value for limit / offset clause:
> {code:java}
> sql("SELECT * FROM t LIMIT ?", new Object{}[null]);
> sql("SELECT * FROM t OFFSET ?", new Object{}[null]);
> sql("SELECT * FROM t LIMIT ? OFFSET ?", new Object{}[null]);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20603) Restore logical topology change event on a node restart
[
https://issues.apache.org/jira/browse/IGNITE-20603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789996#comment-17789996
]
Vladislav Pyatkov commented on IGNITE-20603:
[~maliev] Thank you for your contribution.
Merged 95107c31be013298108deeeb1322874a9952a40a
> Restore logical topology change event on a node restart
> ---
>
> Key: IGNITE-20603
> URL: https://issues.apache.org/jira/browse/IGNITE-20603
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h3. *Motivation*
> It is possible that some events were propagated to {{ms.logicalTopology}},
> but restart happened when we were updating topologyAugmentationMap and other
> states in {{DistributionZoneManager#createMetastorageTopologyListener}}. That
> means that augmentation that must be added to
> {{zone.topologyAugmentationMap}} wasn't added and we need to recover this
> information, or nodesAttributes wasn't propogated to MS.
> h3. *Definition of done*
> On a node restart, all states, that were going to be updated during watch
> event in {{DistributionZoneManager#createMetastorageTopologyListener}} must
> be recovered
> h3. *Implementation notes*
> (outdated, see UPD)
> For every zone, compare {{MS.local.logicalTopology.revision}} with
> max(maxScUpFromMap, maxScDownFromMap). If {{logicalTopology.revision}} is
> greater than max(maxScUpFromMap, maxScDownFromMap), that means that some
> topology changes haven't been propagated to topologyAugmentationMap before
> restart and appropriate timers haven't been scheduled. To fill the gap in
> topologyAugmentationMap, compare {{MS.local.logicalTopology}} with
> {{lastSeenLogicalTopology}} and enhance topologyAugmentationMap with the
> nodes that did not have time to be propagated to topologyAugmentationMap
> before restart. {{lastSeenTopology}} is calculated in the following way: we
> read {{MS.local.dataNodes}}, also we take max(scaleUpTriggerKey,
> scaleDownTriggerKey) and retrieve all additions and removals of nodes from
> the topologyAugmentationMap using max(scaleUpTriggerKey, scaleDownTriggerKey)
> as the left bound. After that apply these changes to the map with nodes
> counters from {{MS.local.dataNodes}} and take nodes only with the positive
> counters. This is the lastSeenTopology. Comparing it with
> {{MS.local.logicalTopology}} will tell us which nodes were not added or
> removed and weren't propagated to topologyAugmentationMap before restart. We
> take these differences and add them to the topologyAugmentationMap. As a
> revision (key for topologyAugmentationMap) take
> {{MS.local.logicalTopology.revision}}. It is safe to take this revision,
> because if some node was added to the {{ms.topology}} after immediate data
> nodes recalculation, this added node must restore this immediate data nodes'
> recalculation intent.
> UPD: Implementation notes are outdated, we've implemented a bit different
> approach: now we save the last handled topology to MS, and on restart we
> restore global states according to states from local metastorage and check if
> the current ms.logicalTopology differs from the one that was handled in
> DistributionZoneManager#createMetastorageTopologyListener (we check revision
> of this events), then we just repeat the logic from
> DistributionZoneManager#createMetastorageTopologyListener with the new
> logical topology from the ms.logicalTopology.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20899) Sql. Align duplicate classes usage : o.a.i.internal.utils.PrimaryReplica and o.a.i.internal.sql.engine.exec.NodeWithTerm
[ https://issues.apache.org/jira/browse/IGNITE-20899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky resolved IGNITE-20899. - Resolution: Won't Fix > Sql. Align duplicate classes usage : o.a.i.internal.utils.PrimaryReplica and > o.a.i.internal.sql.engine.exec.NodeWithTerm > > > Key: IGNITE-20899 > URL: https://issues.apache.org/jira/browse/IGNITE-20899 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Seems: > org.apache.ignite.internal.utils.PrimaryReplica and > org.apache.ignite.internal.sql.engine.exec.NodeWithTerm > have the same semantic and we need to get rid one of them -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20970) Sql. Disallow null dynamic parameters in LIMIT/OFFSET clauses.
[ https://issues.apache.org/jira/browse/IGNITE-20970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20970: -- Summary: Sql. Disallow null dynamic parameters in LIMIT/OFFSET clauses. (was: Sql. Disallow NULLs in LIMIT/OFFSET clauses.) > Sql. Disallow null dynamic parameters in LIMIT/OFFSET clauses. > -- > > Key: IGNITE-20970 > URL: https://issues.apache.org/jira/browse/IGNITE-20970 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Let's disallow null dynamic parameters in LIMIT/OFFSET clauses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20970) Sql. Disallow NULLs in LIMIT/OFFSET clauses.
[ https://issues.apache.org/jira/browse/IGNITE-20970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20970: -- Description: Let's disallow null dynamic parameters in LIMIT/OFFSET clauses. was: Let's disallow NULLs in LIMIT/OFFSET clauses. > Sql. Disallow NULLs in LIMIT/OFFSET clauses. > > > Key: IGNITE-20970 > URL: https://issues.apache.org/jira/browse/IGNITE-20970 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Let's disallow null dynamic parameters in LIMIT/OFFSET clauses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20970) Sql. Disallow NULLs in LIMIT/OFFSET clauses.
[ https://issues.apache.org/jira/browse/IGNITE-20970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20970: -- Labels: ignite-3 (was: ) > Sql. Disallow NULLs in LIMIT/OFFSET clauses. > > > Key: IGNITE-20970 > URL: https://issues.apache.org/jira/browse/IGNITE-20970 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Let's disallow NULLs in LIMIT/OFFSET clauses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20970) Sql. Disallow NULLs in LIMIT/OFFSET clauses.
Maksim Zhuravkov created IGNITE-20970: - Summary: Sql. Disallow NULLs in LIMIT/OFFSET clauses. Key: IGNITE-20970 URL: https://issues.apache.org/jira/browse/IGNITE-20970 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Fix For: 3.0.0-beta2 Let's disallow NULLs in LIMIT/OFFSET clauses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-3) Need to add separate configuration bean to all the SPIs
[ https://issues.apache.org/jira/browse/IGNITE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-3: -- Labels: IGNITE-20970 (was: ) > Need to add separate configuration bean to all the SPIs > --- > > Key: IGNITE-3 > URL: https://issues.apache.org/jira/browse/IGNITE-3 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Setrakyan >Assignee: Dmitriy Setrakyan >Priority: Major > Labels: IGNITE-20970 > Fix For: sprint-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20875) Add enlistment consistency token to PrimaryReplicaRequest interface
[ https://issues.apache.org/jira/browse/IGNITE-20875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-20875: -- Assignee: Vladislav Pyatkov > Add enlistment consistency token to PrimaryReplicaRequest interface > --- > > Key: IGNITE-20875 > URL: https://issues.apache.org/jira/browse/IGNITE-20875 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > The procedure in the method PartitionReplicaListener#ensureReplicaIsPrimary > looks not simple because we have no interface that provides the enlistment > consistency id. But PrimaryReplicaRequest well-suited for the role because it > is used to determine messages targeted at the primary replica. > h3. Definition of done > All messages that are certain to the primary replica should include the > PrimaryReplicaTestRequest interface. The interface should have the enlistment > consistency token internally. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20773) Adjust lock resolution procedure in order to have an ability to do tx coordinator liveness check
[ https://issues.apache.org/jira/browse/IGNITE-20773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20773: - Description: h3. Motivation In order to implemented liveness check and thus initiate transaction recovery if the corresponding coordinator is dead, it's required to adjust lock resolution procedure. h3. Definition of done Liveness check described in IGNITE-20771 is triggered, meaning that txId of first lock is available. h3. Implementation Notes Given ticket finishes the chain of lock triggered tx recovery (coordinator aspect) besides tests that will be covered separately. was: h3. Motivation In order to implemented liveness check and thus initiate transaction recovery if the corresponding coordinator is dead, it's required to adjust lock resolution procedure. h3. Definition of done Liveness check described in IGNITE-20771 is triggered, meaning that txId of first lock is available. h3. Implementation Notes Given ticket finishes the chain of lock triggered tx recovery (coordinator aspect) thus it's required also to add some integration tests here for the whole chain. > Adjust lock resolution procedure in order to have an ability to do tx > coordinator liveness check > > > Key: IGNITE-20773 > URL: https://issues.apache.org/jira/browse/IGNITE-20773 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > h3. Motivation > In order to implemented liveness check and thus initiate transaction recovery > if the corresponding coordinator is dead, it's required to adjust lock > resolution procedure. > h3. Definition of done > Liveness check described in IGNITE-20771 is triggered, meaning that txId of > first lock is available. > h3. Implementation Notes > Given ticket finishes the chain of lock triggered tx recovery (coordinator > aspect) besides tests that will be covered separately. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20766) Deal with the primary replica provider in integration tests
[ https://issues.apache.org/jira/browse/IGNITE-20766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789952#comment-17789952 ] Vladislav Pyatkov commented on IGNITE-20766: Merged da2a4f374af4503e158a91828f0a800d5af93b73 > Deal with the primary replica provider in integration tests > --- > > Key: IGNITE-20766 > URL: https://issues.apache.org/jira/browse/IGNITE-20766 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Tkalenko >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 50m > Remaining Estimate: 0h > > In the process of implementing IGNITE-20678, it turned out that using > *TestPlacementDriver* in tests *ItRebalanceDistributedTest* and > *ItIgniteNodeRestartTest* does not look correct, since for each node the > primary replica will be defined as the node (primary replica) itself, which > can lead to unpredictable behavior, we need to figure this out. > Definition of done > Both thests have an integration nature; the cluster contains more than one > node, and the nodes use the network. In these circumstances, the primary > replica can be changed during an integration test and is not predetermined. > # I believe the test implementation of the placement drive is not applicable > here; this is a better way to instance the production implementation. Look at > the PR attached. > # Or it would be better to rewrite the test to use the original Ignite node > instead of the particular instantiated nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20953) Extract TX futures awaiting
[ https://issues.apache.org/jira/browse/IGNITE-20953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20953: - Reviewer: Alexander Lapin > Extract TX futures awaiting > --- > > Key: IGNITE-20953 > URL: https://issues.apache.org/jira/browse/IGNITE-20953 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This is a refactoring task to simplify the TX read and update futures > handling during the cleanup. We want to move future handling out to a > separate method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20953) Extract TX futures awaiting
[ https://issues.apache.org/jira/browse/IGNITE-20953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov updated IGNITE-20953: --- Description: This is a refactoring task to simplify the TX read and update futures handling during the cleanup. We want to move future handling out to a separate method. (was: At the moment the synchronous part of TX cleanup executes storage cleanup stage before releasing TX locks. It is believed that we can split the current cleanup into two parts - the unlock and the storage cleanup. This change is required for the implementation of the node-wide unlock functionality (IGNITE-20874).) > Extract TX futures awaiting > --- > > Key: IGNITE-20953 > URL: https://issues.apache.org/jira/browse/IGNITE-20953 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > This is a refactoring task to simplify the TX read and update futures > handling during the cleanup. We want to move future handling out to a > separate method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
