[jira] [Commented] (IGNITE-19688) NPE in ItNodeTest#testChangePeersStepsDownInJointConsensus
[
https://issues.apache.org/jira/browse/IGNITE-19688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737843#comment-17737843
]
Mirza Aliev commented on IGNITE-19688:
--
[~vpyatkov] Could you please take a look?
> NPE in ItNodeTest#testChangePeersStepsDownInJointConsensus
> --
>
> Key: IGNITE-19688
> URL: https://issues.apache.org/jira/browse/IGNITE-19688
> Project: Ignite
> Issue Type: Bug
>Reporter: Yury Gerzhedovich
>Assignee: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> org.apache.ignite.raft.jraft.core.ItNodeTest#testChangePeersStepsDownInJointConsensus
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.raft.jraft.core.ItNodeTest.testChangePeersStepsDownInJointConsensus(ItNodeTest.java:3385)
>
> 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)
> {noformat}
> *Motivation*
> The root cause of the issue is the method of getting leader
> (_TestCluster#getLeader_) might return _null_ even if the test waits a leader
> before (_TestCluster#waitLeader_).
> *Implementation Notes*
> Create a new method that returns a leader just after it has waited it
> (_TestCluster#waitAndGetLeader_).
> *Definition of Done*
> Verify all places where method of waiting leader is used and replace it to
> new one in that case where getting leader is not expected to receive _null_.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19724) Remove redundant joins
[ https://issues.apache.org/jira/browse/IGNITE-19724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19724: - Ignite Flags: (was: Docs Required,Release Notes Required) > Remove redundant joins > -- > > Key: IGNITE-19724 > URL: https://issues.apache.org/jira/browse/IGNITE-19724 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > We have some redundant joins: > - > [this|https://github.com/apache/ignite-3/blob/7bcea31c9eb6350120584c1ca060131504927d04/modules/table/src/integrationTest/java/org/apache/ignite/distributed/ReplicaUnavailableTest.java#L199] > must be replaced by assertThat(replicaManager.stopReplica(testGrpId), > willSuccseesFast()); > - > [this|https://github.com/apache/ignite-3/blob/7bcea31c9eb6350120584c1ca060131504927d04/modules/replicator/src/main/java/org/apache/ignite/internal/replicator/ReplicaManager.java#L409] > can be replaced by chaining maybe, need to check > - Also need to review tests from > https://github.com/apache/ignite-3/commit/7bcea31c9eb6350120584c1ca060131504927d04 > for join -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19847) IgniteTxAdapter.TxShadow removal
[
https://issues.apache.org/jira/browse/IGNITE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737807#comment-17737807
]
Ignite TC Bot commented on IGNITE-19847:
{panel:title=Branch: [pull/10807/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10807/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7232332buildTypeId=IgniteTests24Java8_RunAll]
> IgniteTxAdapter.TxShadow removal
>
>
> Key: IGNITE-19847
> URL: https://issues.apache.org/jira/browse/IGNITE-19847
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Seems, it never used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19843) Unify code that triggers rebalance
[ https://issues.apache.org/jira/browse/IGNITE-19843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-19843: --- Reviewer: Alexander Lapin [~sanpwc] could you please take a look at the attached PR? > Unify code that triggers rebalance > -- > > Key: IGNITE-19843 > URL: https://issues.apache.org/jira/browse/IGNITE-19843 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Both 'on data nodes changed' and 'on replicas on a zone changed' trigger > rebalance; their code is very similar. We should extract the duplicated code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19753) Move task and command class to the same packages
[
https://issues.apache.org/jira/browse/IGNITE-19753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737723#comment-17737723
]
Valery Shorin commented on IGNITE-19753:
Test failure {{IgniteControlUtilityTestSuite2:
GridCommandHandlerDefragmentationTest.testDefragmentationStatus[cmdHnd=cli]}}
is not related to this change, this test fails on master branch as well:
https://ci2.ignite.apache.org/test/-8869604011192050851?currentProjectId=IgniteTests24Java8=true=%3Cdefault%3E
> Move task and command class to the same packages
>
>
> Key: IGNITE-19753
> URL: https://issues.apache.org/jira/browse/IGNITE-19753
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.16
>Reporter: Nikolay Izhikov
>Assignee: Valery Shorin
>Priority: Major
> Labels: IEP-81
> Fix For: 2.16
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Right now command of Management API in
> {{org.apache.ignite.internal.management}} package and tasks that implements
> command logic in {{org.apache.ignite.internal.visor}} package.
> Visor not existing anymore in Ignite so it's seems logical to move tasks and
> their dependencies to commands.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19753) Move task and command class to the same packages
[
https://issues.apache.org/jira/browse/IGNITE-19753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737721#comment-17737721
]
Ignite TC Bot commented on IGNITE-19753:
{panel:title=Branch: [pull/10797/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Control Utility 2{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7233987]]
* IgniteControlUtilityTestSuite2:
GridCommandHandlerDefragmentationTest.testDefragmentationStatus[cmdHnd=cli] -
History for base branch is absent.
{panel}
{panel:title=Branch: [pull/10797/head] Base: [master] : New Tests
(372)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility 2{color} [[tests
276|https://ci2.ignite.apache.org/viewLog.html?buildId=7233987]]
* {color:#013220}IgniteControlUtilityTestSuite2:
GridCommandHandlerConsistencyTest.testAtomicAndTxValueAndVersion[cmdHnd=cli,
strategy=LWW, explicitGrp=false, callByGrp=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite2:
GridCommandHandlerConsistencyTest.testRepairNonExistentCache[cmdHnd=cli,
strategy=LWW, explicitGrp=false, callByGrp=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite2:
GridCommandHandlerConsistencyTest.testCacheFilter[cmdHnd=jmx, strategy=LWW,
explicitGrp=true, callByGrp=true] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite2:
GridCommandHandlerConsistencyTest.testAtomicAndTxVersionOnly[cmdHnd=jmx,
strategy=LWW, explicitGrp=true, callByGrp=true] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite2:
GridCommandHandlerConsistencyTest.testAtomicAndTxValueAndVersion[cmdHnd=cli,
strategy=LWW, explicitGrp=true, callByGrp=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite2:
GridCommandHandlerConsistencyTest.testRepairNonExistentCache[cmdHnd=cli,
strategy=LWW, explicitGrp=true, callByGrp=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite2:
GridCommandHandlerConsistencyTest.testCacheFilter[cmdHnd=cli, strategy=LWW,
explicitGrp=false, callByGrp=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite2:
GridCommandHandlerConsistencyTest.testAtomicAndTxVersionOnly[cmdHnd=cli,
strategy=LWW, explicitGrp=false, callByGrp=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite2:
GridCommandHandlerConsistencyTest.testAtomicAndTxValueAndVersion[cmdHnd=jmx,
strategy=LWW, explicitGrp=true, callByGrp=true] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite2:
GridCommandHandlerConsistencyTest.testRepairNonExistentCache[cmdHnd=jmx,
strategy=LWW, explicitGrp=true, callByGrp=true] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite2:
GridCommandHandlerConsistencyTest.testCacheFilter[cmdHnd=jmx, strategy=PRIMARY,
explicitGrp=false, callByGrp=false] - PASSED{color}
... and 265 new tests
{color:#8b}Control Utility 1{color} [[tests
96|https://ci2.ignite.apache.org/viewLog.html?buildId=7233901]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.testCachesRepair[cmdHnd=cli,
misses=false, nulls=false, strategy=LWW, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.testGroupRepairBySingleCacheName[cmdHnd=cli,
misses=false, nulls=false, strategy=LWW, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.testGroupRepairByCacheNames[cmdHnd=jmx,
misses=false, nulls=false, strategy=PRIMARY, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.testGroupRepairByItsName[cmdHnd=jmx,
misses=false, nulls=false, strategy=PRIMARY, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.testCachesRepair[cmdHnd=cli,
misses=false, nulls=false, strategy=RELATIVE_MAJORITY, parallel=false] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.testGroupRepairBySingleCacheName[cmdHnd=cli,
misses=false, nulls=false, strategy=RELATIVE_MAJORITY, parallel=false] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.testGroupRepairByCacheNames[cmdHnd=cli,
misses=false, nulls=false, strategy=LWW, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.testGroupRepairByItsName[cmdHnd=cli,
misses=false, nulls=false, strategy=LWW, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
[jira] [Updated] (IGNITE-19859) Java thin 3.0: testAutoFlushByTimer is flaky
[
https://issues.apache.org/jira/browse/IGNITE-19859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-19859:
Description:
https://ci.ignite.apache.org/test/-2896687331391880214?currentProjectId=ApacheIgnite3xGradle_Test_IntegrationTests=true=
{code}
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.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.internal.streamer.ItAbstractDataStreamerTest.testAutoFlushByTimer(ItAbstractDataStreamerTest.java:144)
{code}
> Java thin 3.0: testAutoFlushByTimer is flaky
>
>
> Key: IGNITE-19859
> URL: https://issues.apache.org/jira/browse/IGNITE-19859
> Project: Ignite
> Issue Type: Bug
> Components: 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
>
>
> https://ci.ignite.apache.org/test/-2896687331391880214?currentProjectId=ApacheIgnite3xGradle_Test_IntegrationTests=true=
> {code}
> 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.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.internal.streamer.ItAbstractDataStreamerTest.testAutoFlushByTimer(ItAbstractDataStreamerTest.java:144)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19858) Sql. RelJson serialization/deserialization mismatch for statements that include very large numbers.
[
https://issues.apache.org/jira/browse/IGNITE-19858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19858:
--
Description:
{code:java}
SELECT C2 > 3402823466385288601::REAL FROM test2
{code}
Type of C2 is REAL.
Tests that use AbstractPlannerTest::checkSplitAndSerialization will produce the
following error:
{code:java}
org.opentest4j.AssertionFailedError: Invalid serialization / deserialization.
Expected:
IgniteTableScan(table=[[PUBLIC, TEST2]], projects=[[>($t0,
3402823466385288601)]], requiredColumns=[{1}], sourceId=[1])
Deserialized:
IgniteTableScan(table=[[PUBLIC, TEST2]], projects=[[>($t0,
3.402823466385289E38)]], requiredColumns=[{1}], sourceId=[1])
==>
{code}
was:
{code:java}
SELECT * FROM test2 WHERE C2 > 3402823466385288601::REAL
{code}
Tests that use AbstractPlannerTest::checkSplitAndSerialization will produce the
following error:
{code:java}
org.opentest4j.AssertionFailedError: Invalid serialization / deserialization.
Expected:
IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
filters=[>($t1,
179769313486231570001)],
requiredColumns=[{0, 1}], sourceId=[114], collation=[[1]])
Deserialized:
IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
filters=[>($t1, 1.797693134862316E308)], requiredColumns=[{0, 1}],
sourceId=[114], collation=[[1]])
{code}
> Sql. RelJson serialization/deserialization mismatch for statements that
> include very large numbers.
> ---
>
> Key: IGNITE-19858
> URL: https://issues.apache.org/jira/browse/IGNITE-19858
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> {code:java}
> SELECT C2 > 3402823466385288601::REAL FROM test2
> {code}
> Type of C2 is REAL.
> Tests that use AbstractPlannerTest::checkSplitAndSerialization will produce
> the following error:
> {code:java}
> org.opentest4j.AssertionFailedError: Invalid serialization / deserialization.
> Expected:
> IgniteTableScan(table=[[PUBLIC, TEST2]], projects=[[>($t0,
> 3402823466385288601)]], requiredColumns=[{1}],
> sourceId=[1])
> Deserialized:
> IgniteTableScan(table=[[PUBLIC, TEST2]], projects=[[>($t0,
> 3.402823466385289E38)]], requiredColumns=[{1}], sourceId=[1])
> ==>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19859) Java thin 3.0: testAutoFlushByTimer is flaky
Pavel Tupitsyn created IGNITE-19859: --- Summary: Java thin 3.0: testAutoFlushByTimer is flaky Key: IGNITE-19859 URL: https://issues.apache.org/jira/browse/IGNITE-19859 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19858) Sql. RelJson serialization/deserialization mismatch for statements that include large numbers.
[
https://issues.apache.org/jira/browse/IGNITE-19858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19858:
--
Summary: Sql. RelJson serialization/deserialization mismatch for statements
that include large numbers. (was: Sql. RelJson serialization/deserialization
mismatch for statements that include large numbers)
> Sql. RelJson serialization/deserialization mismatch for statements that
> include large numbers.
> --
>
> Key: IGNITE-19858
> URL: https://issues.apache.org/jira/browse/IGNITE-19858
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> {code:java}
> SELECT * FROM test2 WHERE C2 > 3402823466385288601::REAL
> {code}
> Tests that use AbstractPlannerTest::checkSplitAndSerialization will produce
> the following error:
> {code:java}
> org.opentest4j.AssertionFailedError: Invalid serialization / deserialization.
> Expected:
> IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
> searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
> upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
> filters=[>($t1,
> 179769313486231570001)],
> requiredColumns=[{0, 1}], sourceId=[114], collation=[[1]])
> Deserialized:
> IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
> searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
> upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
> filters=[>($t1, 1.797693134862316E308)], requiredColumns=[{0, 1}],
> sourceId=[114], collation=[[1]])
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19213) ODBC 3.0: Data fetching
[ https://issues.apache.org/jira/browse/IGNITE-19213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-19213: Assignee: Igor Sapego > ODBC 3.0: Data fetching > --- > > Key: IGNITE-19213 > URL: https://issues.apache.org/jira/browse/IGNITE-19213 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Scope: > - Implement data fetch request handling on server side; > - Implement data fetching and data handling on client side; > - Port applicable tests; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19858) Sql. RelJson serialization/deserialization mismatch for statements that include large numbers
Maksim Zhuravkov created IGNITE-19858:
-
Summary: Sql. RelJson serialization/deserialization mismatch for
statements that include large numbers
Key: IGNITE-19858
URL: https://issues.apache.org/jira/browse/IGNITE-19858
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta2
Reporter: Maksim Zhuravkov
{code:java}
SELECT * FROM test2 WHERE C2 > 3402823466385288601::REAL
{code}
Tests that use AbstractPlannerTest::checkSplitAndSerialization will produce the
following error:
{code:java}
Expected:
IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
filters=[>($t1,
179769313486231570001)],
requiredColumns=[{0, 1}], sourceId=[114], collation=[[1]])
Deserialized:
IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
filters=[>($t1, 1.797693134862316E308)], requiredColumns=[{0, 1}],
sourceId=[114], collation=[[1]])
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19858) Sql. RelJson serialization/deserialization mismatch for statements that include very large numbers.
[
https://issues.apache.org/jira/browse/IGNITE-19858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19858:
--
Summary: Sql. RelJson serialization/deserialization mismatch for statements
that include very large numbers. (was: Sql. RelJson
serialization/deserialization mismatch for statements that include large
numbers.)
> Sql. RelJson serialization/deserialization mismatch for statements that
> include very large numbers.
> ---
>
> Key: IGNITE-19858
> URL: https://issues.apache.org/jira/browse/IGNITE-19858
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> {code:java}
> SELECT * FROM test2 WHERE C2 > 3402823466385288601::REAL
> {code}
> Tests that use AbstractPlannerTest::checkSplitAndSerialization will produce
> the following error:
> {code:java}
> org.opentest4j.AssertionFailedError: Invalid serialization / deserialization.
> Expected:
> IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
> searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
> upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
> filters=[>($t1,
> 179769313486231570001)],
> requiredColumns=[{0, 1}], sourceId=[114], collation=[[1]])
> Deserialized:
> IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
> searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
> upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
> filters=[>($t1, 1.797693134862316E308)], requiredColumns=[{0, 1}],
> sourceId=[114], collation=[[1]])
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19858) Sql. RelJson serialization/deserialization mismatch for statements that include large numbers
[
https://issues.apache.org/jira/browse/IGNITE-19858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19858:
--
Description:
{code:java}
SELECT * FROM test2 WHERE C2 > 3402823466385288601::REAL
{code}
Tests that use AbstractPlannerTest::checkSplitAndSerialization will produce the
following error:
{code:java}
org.opentest4j.AssertionFailedError: Invalid serialization / deserialization.
Expected:
IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
filters=[>($t1,
179769313486231570001)],
requiredColumns=[{0, 1}], sourceId=[114], collation=[[1]])
Deserialized:
IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
filters=[>($t1, 1.797693134862316E308)], requiredColumns=[{0, 1}],
sourceId=[114], collation=[[1]])
{code}
was:
{code:java}
SELECT * FROM test2 WHERE C2 > 3402823466385288601::REAL
{code}
Tests that use AbstractPlannerTest::checkSplitAndSerialization will produce the
following error:
{code:java}
Expected:
IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
filters=[>($t1,
179769313486231570001)],
requiredColumns=[{0, 1}], sourceId=[114], collation=[[1]])
Deserialized:
IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
filters=[>($t1, 1.797693134862316E308)], requiredColumns=[{0, 1}],
sourceId=[114], collation=[[1]])
{code}
> Sql. RelJson serialization/deserialization mismatch for statements that
> include large numbers
> -
>
> Key: IGNITE-19858
> URL: https://issues.apache.org/jira/browse/IGNITE-19858
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> {code:java}
> SELECT * FROM test2 WHERE C2 > 3402823466385288601::REAL
> {code}
> Tests that use AbstractPlannerTest::checkSplitAndSerialization will produce
> the following error:
> {code:java}
> org.opentest4j.AssertionFailedError: Invalid serialization / deserialization.
> Expected:
> IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
> searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
> upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
> filters=[>($t1,
> 179769313486231570001)],
> requiredColumns=[{0, 1}], sourceId=[114], collation=[[1]])
> Deserialized:
> IgniteIndexScan(table=[[PUBLIC, TEST2]], index=[TEST2_C2_IDX], type=[SORTED],
> searchBounds=[[RangeBounds [lowerBound=1.7976931348623157E308:DOUBLE,
> upperBound=$NULL_BOUND(), lowerInclude=false, upperInclude=false]]],
> filters=[>($t1, 1.797693134862316E308)], requiredColumns=[{0, 1}],
> sourceId=[114], collation=[[1]])
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19857) Default zone replica count is not listened by rebalance trigger
Roman Puchkovskiy created IGNITE-19857: -- Summary: Default zone replica count is not listened by rebalance trigger Key: IGNITE-19857 URL: https://issues.apache.org/jira/browse/IGNITE-19857 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 As a result, when 'replicas' is changed on a default zone, rebalance is not triggered -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19610) .NET: Thin 3.0: Data streamer metrics
[ https://issues.apache.org/jira/browse/IGNITE-19610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737698#comment-17737698 ] Pavel Tupitsyn commented on IGNITE-19610: - Merged to main: 81fe252ee7847da92ff770035af00cbb930764c3 > .NET: Thin 3.0: Data streamer metrics > - > > Key: IGNITE-19610 > URL: https://issues.apache.org/jira/browse/IGNITE-19610 > Project: Ignite > Issue Type: Improvement > Components: 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 > > Add metrics for data streamer (batches sent, batches in flight, retries, etc) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19610) .NET: Thin 3.0: Data streamer metrics
[ https://issues.apache.org/jira/browse/IGNITE-19610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737693#comment-17737693 ] Igor Sapego commented on IGNITE-19610: -- Looks good to me. > .NET: Thin 3.0: Data streamer metrics > - > > Key: IGNITE-19610 > URL: https://issues.apache.org/jira/browse/IGNITE-19610 > Project: Ignite > Issue Type: Improvement > Components: 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 > > Add metrics for data streamer (batches sent, batches in flight, retries, etc) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19851) Add MetaStorage update update listeners and use instead of configuration revision update listeners
[ https://issues.apache.org/jira/browse/IGNITE-19851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-19851: -- Assignee: Ivan Bessonov (was: Kirill Tkalenko) > Add MetaStorage update update listeners and use instead of configuration > revision update listeners > -- > > Key: IGNITE-19851 > URL: https://issues.apache.org/jira/browse/IGNITE-19851 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h > Remaining Estimate: 0h > > The main problem is described in IGNITE-19801, but due to the fact that we > now have code closely related to updating the configuration revision, it is > difficult to do everything at once in IGNITE-19801, so it will be divided > into parts. > In this task, I will add listeners for updating the revision of the > *MetaStorage* and replace it with its use in the production code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19843) Unify code that triggers rebalance
[ https://issues.apache.org/jira/browse/IGNITE-19843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-19843: --- Summary: Unify code that triggers rebalance (was: Make code triggering rebalance more reusable) > Unify code that triggers rebalance > -- > > Key: IGNITE-19843 > URL: https://issues.apache.org/jira/browse/IGNITE-19843 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > Both 'on data nodes changed' and 'on replicas on a zone changed' trigger > rebalance; their code is very similar. We should extract the duplicated code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19850) Fix metastorage unable to recover with multiple ms nodes
[ https://issues.apache.org/jira/browse/IGNITE-19850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-19850: Description: On recovery, metastorage refreshes raft leader to access latest metastorage revision. If there is no leader yet, or not all metastorage nodes are online, recovery won't proceed. If 3 nodes are being started synchronously and all 3 nodes are metastorage nodes, then they will fail to start. The easiest solution would be to not start nodes synchronously. > Fix metastorage unable to recover with multiple ms nodes > > > Key: IGNITE-19850 > URL: https://issues.apache.org/jira/browse/IGNITE-19850 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Priority: Major > Labels: ignite-3 > > On recovery, metastorage refreshes raft leader to access latest metastorage > revision. If there is no leader yet, or not all metastorage nodes are online, > recovery won't proceed. If 3 nodes are being started synchronously and all 3 > nodes are metastorage nodes, then they will fail to start. > The easiest solution would be to not start nodes synchronously. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-15927) Implement one phase commit
[ https://issues.apache.org/jira/browse/IGNITE-15927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov reassigned IGNITE-15927: -- Assignee: Alexey Scherbakov > Implement one phase commit > -- > > Key: IGNITE-15927 > URL: https://issues.apache.org/jira/browse/IGNITE-15927 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > > If all keys in the implicit transaction belong to a same partition in can be > committed in one round-trip. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19158) Improve message about received partition file during snapshot restore
[
https://issues.apache.org/jira/browse/IGNITE-19158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737631#comment-17737631
]
Ignite TC Bot commented on IGNITE-19158:
{panel:title=Branch: [pull/10762/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10762/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7199897buildTypeId=IgniteTests24Java8_RunAll]
> Improve message about received partition file during snapshot restore
> -
>
> Key: IGNITE-19158
> URL: https://issues.apache.org/jira/browse/IGNITE-19158
> Project: Ignite
> Issue Type: Task
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: iep-43, ise
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, GridIoManager prints only name of a file and node id:
> {quote}
> [2023-03-24T18:07:00,747][INFO ]pub-#871%node1%[GridIoManager] File has been
> received [name={color:red}part-233.bin{color}, transferred=53248, time=0.0
> sec, {color:red}rmtId=76e22ef5-3c76-4987-bebd-9a6222a0{color}]
> {quote}
> This meager information does not allow to determine in a simple way which
> file is received and from which node.
> For example, such message would be more informative:
> {quote}
> [2023-03-29T17:09:42,230][INFO ][pub-#869%node0%][GridIoManager] File has
> been received
> [{color:red}path=/ignite/db/node0/_tmp_snp_restore_cache-default/part-647.bin{color},
> transferred=45056, time=0.0 sec, rmtId=de43d2e8-a1ab-4d7c-9cea-72615371,
> {color:red}rmdAddr=/127.0.0.1:51773{color}]
> {quote}
> _Other ways might be investigated_ in order to improve logging of receiving
> partition files during snapshot restore.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19500) IndexManager should listen CatalogService events instead of configuration
[ https://issues.apache.org/jira/browse/IGNITE-19500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-19500: - Description: As of now, IndexManager listens configuration events to create internal structures. Let's make IndexManager listens CatalogService events instead. Note: Some tests may fails due to changed guarantees and related ticked incompletion. So, let's do this in a separate feature branch. *Some thoughts:* For some simplification of the transition to the catalog, I thought that adding a table ID from the configuration and this ID when executing an catalog event to delete a table can help us. was: As of now, IndexManager listens configuration events to create internal structures. Let's make IndexManager listens CatalogService events instead. Note: Some tests may fails due to changed guarantees and related ticked incompletion. So, let's do this in a separate feature branch. > IndexManager should listen CatalogService events instead of configuration > - > > Key: IGNITE-19500 > URL: https://issues.apache.org/jira/browse/IGNITE-19500 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > As of now, IndexManager listens configuration events to create internal > structures. > Let's make IndexManager listens CatalogService events instead. > Note: Some tests may fails due to changed guarantees and related ticked > incompletion. So, let's do this in a separate feature branch. > *Some thoughts:* > For some simplification of the transition to the catalog, I thought that > adding a table ID from the configuration and this ID when executing an > catalog event to delete a table can help us. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19828) Optimize RAFT log encoder/decoder
[ https://issues.apache.org/jira/browse/IGNITE-19828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737622#comment-17737622 ] Semyon Danilov commented on IGNITE-19828: - Looks good to me! > Optimize RAFT log encoder/decoder > - > > Key: IGNITE-19828 > URL: https://issues.apache.org/jira/browse/IGNITE-19828 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 50m > Remaining Estimate: 0h > > We need to introduce varints (list in jraft encoders V2) and omit serializing > configuration for DATA entries (just like omitting data in CONFIGURATION > entries). > Current size of log entries is too big -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17824) Use named executor instead of default one in order to process replica Response
[
https://issues.apache.org/jira/browse/IGNITE-17824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737593#comment-17737593
]
Alexey Scherbakov commented on IGNITE-17824:
Note that org.apache.ignite.internal.tx.impl.HeapLockManager#delayedExecutor
indirectly uses Common Pool.
> Use named executor instead of default one in order to process replica Response
> --
>
> Key: IGNITE-17824
> URL: https://issues.apache.org/jira/browse/IGNITE-17824
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> Within ReplicaService.sendToReplica
> {code:java}
> private CompletableFuture sendToReplica(ClusterNode node,
> ReplicaRequest req) {
> CompletableFuture res = new CompletableFuture<>();
> messagingService.invoke(node.address(), req,
> RPC_TIMEOUT).whenCompleteAsync((response, throwable) -> { {code}
> named executor should be used instead of default one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-19746) control.sh --performance-statistics status doesn't not print actual status
[
https://issues.apache.org/jira/browse/IGNITE-19746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov resolved IGNITE-19746.
--
Resolution: Fixed
> control.sh --performance-statistics status doesn't not print actual status
> --
>
> Key: IGNITE-19746
> URL: https://issues.apache.org/jira/browse/IGNITE-19746
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-81
>
> The status sub-command of the control.sh --performance-statistics doesn't not
> print the actual status to console.
> Previously it was like (note the *Disabled.* word):
> {noformat}
> Control utility [ver. 15.0.0-SNAPSHOT#20230422-sha1:7f80003d]
> 2023 Copyright(C) Apache Software Foundation
> User: ducker
> Time: 2023-04-23T22:17:12.489
> Command [PERFORMANCE-STATISTICS] started
> Arguments: --host x.x.x.x --performance-statistics status --user admin
> --password *
>
> Disabled.
> Command [PERFORMANCE-STATISTICS] finished with code: 0
> Control utility has completed execution at: 2023-04-23T22:17:13.271
> Execution time: 782 ms
> {noformat}
>
> Now it's like (note the absence of the *Disabled.* word):
> {noformat}
> Control utility [ver. 15.0.0-SNAPSHOT#20230613-sha1:cacee58d]
> 2023 Copyright(C) Apache Software Foundation
> User: ducker
> Time: 2023-06-15T15:46:41.586
> Command [PERFORMANCE-STATISTICS] started
> Arguments: --host x.x.x.x --performance-statistics status --user admin
> --password *
>
> Command [PERFORMANCE-STATISTICS] finished with code: 0
> Control utility has completed execution at: 2023-06-15T15:46:42.523
> Execution time: 937 ms
> {noformat}
>
> Outputs of other sub-commands are also need to be checked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Deleted] (IGNITE-19856) Netty buffer leak in HandshakeHandler
[ https://issues.apache.org/jira/browse/IGNITE-19856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn deleted IGNITE-19856: > Netty buffer leak in HandshakeHandler > - > > Key: IGNITE-19856 > URL: https://issues.apache.org/jira/browse/IGNITE-19856 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Priority: Blocker > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19856) Netty buffer leak in HandshakeHandler
Pavel Tupitsyn created IGNITE-19856: --- Summary: Netty buffer leak in HandshakeHandler Key: IGNITE-19856 URL: https://issues.apache.org/jira/browse/IGNITE-19856 Project: Ignite Issue Type: Improvement Components: networking Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19823) DeploymentUnitNotFoundException is internal, does not propagate to client
[ https://issues.apache.org/jira/browse/IGNITE-19823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin updated IGNITE-19823: --- Epic Link: IGNITE-18728 > DeploymentUnitNotFoundException is internal, does not propagate to client > - > > Key: IGNITE-19823 > URL: https://issues.apache.org/jira/browse/IGNITE-19823 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > * *DeploymentUnitNotFoundException* is in internal package, but it is a > "public" exception which is thrown when the user specifies an unknown unit > name/version. > * It is remapped to *ClassNotFoundException* in > https://github.com/apache/ignite-3/blob/f90f949b342bd1fa864d342c4078b393f4ed23c0/modules/compute/src/main/java/org/apache/ignite/internal/compute/ClassLoaderExceptionsMapper.java#L50 > As a result, traceId and error code are not propagated to the client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19855) ODBC 3.0: Implement multiple queries execution
Igor Sapego created IGNITE-19855: Summary: ODBC 3.0: Implement multiple queries execution Key: IGNITE-19855 URL: https://issues.apache.org/jira/browse/IGNITE-19855 Project: Ignite Issue Type: New Feature Components: odbc Reporter: Igor Sapego Assignee: Igor Sapego Currently, we do not support execution of multiple queries and fetching of multiple result sets. Let's implement it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19676) JMX Commands invoker
[ https://issues.apache.org/jira/browse/IGNITE-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-19676: - Fix Version/s: 2.16 > JMX Commands invoker > > > Key: IGNITE-19676 > URL: https://issues.apache.org/jira/browse/IGNITE-19676 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-81, important, ise > Fix For: 2.16 > > Time Spent: 3.5h > Remaining Estimate: 0h > > After creation of Management API Ignite must provide JMX command invoker. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19854) ODBC 3.0: Implement metadata fetching for the non-executed query
Igor Sapego created IGNITE-19854: Summary: ODBC 3.0: Implement metadata fetching for the non-executed query Key: IGNITE-19854 URL: https://issues.apache.org/jira/browse/IGNITE-19854 Project: Ignite Issue Type: New Feature Components: odbc Reporter: Igor Sapego Assignee: Igor Sapego We currently do not have a prepare feature, but sometimes user application wants to get a result set meta information without execution of the query. We need to implement this feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19845) IgniteTxLocalAdapter.sndTransformedVals field removal
[
https://issues.apache.org/jira/browse/IGNITE-19845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737564#comment-17737564
]
Ignite TC Bot commented on IGNITE-19845:
{panel:title=Branch: [pull/10805/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10805/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7232098buildTypeId=IgniteTests24Java8_RunAll]
> IgniteTxLocalAdapter.sndTransformedVals field removal
> -
>
> Key: IGNITE-19845
> URL: https://issues.apache.org/jira/browse/IGNITE-19845
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19789) Sql. Introduce RowSchema for RowFactory
[
https://issues.apache.org/jira/browse/IGNITE-19789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-19789:
---
Description:
There are three way to create
{{{}org.apache.ignite.internal.sql.engine.exec.RowHandler.RowFactory{}}}:
{code:java}
RowFactory factory(IgniteTypeFactory typeFactory, RelDataType rowType);
RowFactory factory(IgniteTypeFactory typeFactory, List
fieldTypes);
RowFactory factory(Type... types);
{code}
The first two create unnecessary dependency on {{calcite}} library, the last
one doesn't provide required type's parameters, like decimal scale, for
instance.
Let's replace all three methods with a single {{{}RowFactory
factory(RowSchema schema){}}}, where {{RowSchema}} is a class that should be
introduced.
h4. Implementation Notes
Although {{org.apache.ignite.internal.schema.BinaryTupleSchemas}} might seem
like a good candidate on the role of RowSchema, it doesn't have exhaustive
type's support. Besides, introducing new type to binary tuple is much complex
procedure since it will affect every module. Thus, it's better to implement
distinct schema optimised for RowHandler|RowFactory use case.
RowSchema should support complex/nested objects
was:
There are three way to create
{{org.apache.ignite.internal.sql.engine.exec.RowHandler.RowFactory}}:
{code:java}
RowFactory factory(IgniteTypeFactory typeFactory, RelDataType rowType);
RowFactory factory(IgniteTypeFactory typeFactory, List
fieldTypes);
RowFactory factory(Type... types);
{code}
The first two create unnecessary dependency on {{calcite}} library, the last
one doesn't provide required type's parameters, like decimal scale, for
instance.
Let's replace all three methods with a single {{RowFactory
factory(RowSchema schema)}}, where {{RowSchema}} is a class that should be
introduced.
h4. Implementation Notes
Although {{org.apache.ignite.internal.schema.BinaryTupleSchemas}} might seem
like a good candidate on the role of RowSchema, it doesn't have exhaustive
type's support. Besides, introducing new type to binary tuple is much complex
procedure since it will affect every module. Thus, it's better to implement
distinct schema optimised for RowHandler|RowFactory use case.
> Sql. Introduce RowSchema for RowFactory
> ---
>
> Key: IGNITE-19789
> URL: https://issues.apache.org/jira/browse/IGNITE-19789
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> There are three way to create
> {{{}org.apache.ignite.internal.sql.engine.exec.RowHandler.RowFactory{}}}:
> {code:java}
> RowFactory factory(IgniteTypeFactory typeFactory, RelDataType rowType);
> RowFactory factory(IgniteTypeFactory typeFactory, List
> fieldTypes);
> RowFactory factory(Type... types);
> {code}
> The first two create unnecessary dependency on {{calcite}} library, the last
> one doesn't provide required type's parameters, like decimal scale, for
> instance.
> Let's replace all three methods with a single {{{}RowFactory
> factory(RowSchema schema){}}}, where {{RowSchema}} is a class that should be
> introduced.
> h4. Implementation Notes
> Although {{org.apache.ignite.internal.schema.BinaryTupleSchemas}} might seem
> like a good candidate on the role of RowSchema, it doesn't have exhaustive
> type's support. Besides, introducing new type to binary tuple is much complex
> procedure since it will affect every module. Thus, it's better to implement
> distinct schema optimised for RowHandler|RowFactory use case.
> RowSchema should support complex/nested objects
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19830) Add a description check if the command argument is enum type.
[
https://issues.apache.org/jira/browse/IGNITE-19830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev reassigned IGNITE-19830:
Assignee: Nikita Amelchev
> Add a description check if the command argument is enum type.
> -
>
> Key: IGNITE-19830
> URL: https://issues.apache.org/jira/browse/IGNITE-19830
> Project: Ignite
> Issue Type: Task
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Major
> Labels: IEP-81, ise
>
> Add a check for the presence of a enum description ({{@EnumDescription}}) if
> the parameter ({{@Argument}}) is an enum type.
> Example of an uncovered argument: {{ShutdownPolicyCommandArg#shutdownPolicy}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19783) StripedScheduledExecutorService for DistributionZoneManager#executor
[ https://issues.apache.org/jira/browse/IGNITE-19783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-19783: --- Description: h3. *Motivation* In https://issues.apache.org/jira/browse/IGNITE-19736 we set corePoolSize=1 for DistributionZoneManager#executor to ensure that all data nodes calculation tasks per a zone are executed in order of creation. But we need more threads to process this tasks. So we need to create StripedScheduledExecutorService and all tasks for the same zone must be executed in one stripe. The pool to execute the task is defined by a zone id. h3. *Definition of Done* # StripedScheduledExecutorService is created and used instead of single thread executor in DistributionZoneManager. # All tasks for the same zone must be executed in one stripe. h3. *Implementation Notes* I've created a draft StripedScheduledExecutorService in a branch [https://github.com/gridgain/apache-ignite-3/tree/ignite-19783] was: h3. *Motivation* In https://issues.apache.org/jira/browse/IGNITE-19736 we set corePoolSize=1 for DistributionZoneManager#executor to ensure that all data nodes calculation tasks per a zone are executed in order of creation. But we need more threads to process this tasks. So we need to create StripedScheduledExecutorService and all tasks for the same zone must be executed in one stripe. The pool to execute the task is defined by a zone id. h3. *Definition of Done* # StripedScheduledExecutorService is created and used instead of single thread executor in DistributionZoneManager. # All tasks for the same zone must be executed in one stripe. h3. *Implementation Notes* I've created [https://github.com/gridgain/apache-ignite-3/tree/ignite-19783] > StripedScheduledExecutorService for DistributionZoneManager#executor > > > Key: IGNITE-19783 > URL: https://issues.apache.org/jira/browse/IGNITE-19783 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > h3. *Motivation* > In https://issues.apache.org/jira/browse/IGNITE-19736 we set corePoolSize=1 > for DistributionZoneManager#executor to ensure that all data nodes > calculation tasks per a zone are executed in order of creation. But we need > more threads to process this tasks. So we need to create > StripedScheduledExecutorService and all tasks for the same zone must be > executed in one stripe. The pool to execute the task is defined by a zone id. > h3. *Definition of Done* > # StripedScheduledExecutorService is created and used instead of single > thread executor in DistributionZoneManager. > # All tasks for the same zone must be executed in one stripe. > h3. *Implementation Notes* > I've created a draft StripedScheduledExecutorService in a branch > [https://github.com/gridgain/apache-ignite-3/tree/ignite-19783] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19783) StripedScheduledExecutorService for DistributionZoneManager#executor
[ https://issues.apache.org/jira/browse/IGNITE-19783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-19783: --- Description: h3. *Motivation* In https://issues.apache.org/jira/browse/IGNITE-19736 we set corePoolSize=1 for DistributionZoneManager#executor to ensure that all data nodes calculation tasks per a zone are executed in order of creation. But we need more threads to process this tasks. So we need to create StripedScheduledExecutorService and all tasks for the same zone must be executed in one stripe. The pool to execute the task is defined by a zone id. h3. *Definition of Done* # StripedScheduledExecutorService is created and used instead of single thread executor in DistributionZoneManager. # All tasks for the same zone must be executed in one stripe. h3. *Implementation Notes* I've created [https://github.com/gridgain/apache-ignite-3/tree/ignite-19783] was: h3. *Motivation* In https://issues.apache.org/jira/browse/IGNITE-19736 we set corePoolSize=1 for DistributionZoneManager#executor to ensure that all data nodes calculation tasks per a zone are executed in order of creation. But we need more threads to process this tasks. So we need to create StripedScheduledExecutorService and all tasks for the same zone must be executed in one stripe. The pool to execute the task is defined by a zone id. h3. *Definition of Done* # StripedScheduledExecutorService is created and used instead of single thread executor in DistributionZoneManager. # All tasks for the same zone must be executed in one stripe. > StripedScheduledExecutorService for DistributionZoneManager#executor > > > Key: IGNITE-19783 > URL: https://issues.apache.org/jira/browse/IGNITE-19783 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > h3. *Motivation* > In https://issues.apache.org/jira/browse/IGNITE-19736 we set corePoolSize=1 > for DistributionZoneManager#executor to ensure that all data nodes > calculation tasks per a zone are executed in order of creation. But we need > more threads to process this tasks. So we need to create > StripedScheduledExecutorService and all tasks for the same zone must be > executed in one stripe. The pool to execute the task is defined by a zone id. > h3. *Definition of Done* > # StripedScheduledExecutorService is created and used instead of single > thread executor in DistributionZoneManager. > # All tasks for the same zone must be executed in one stripe. > h3. *Implementation Notes* > I've created [https://github.com/gridgain/apache-ignite-3/tree/ignite-19783] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19583) Benchmark & optimize writing into RAFT log
[ https://issues.apache.org/jira/browse/IGNITE-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov resolved IGNITE-19583. Resolution: Duplicate https://issues.apache.org/jira/browse/IGNITE-19806 Duplicate. PR link is wrong here BTW > Benchmark & optimize writing into RAFT log > -- > > Key: IGNITE-19583 > URL: https://issues.apache.org/jira/browse/IGNITE-19583 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > We should investigate the log storage performance and consider switching > current rocksdb-based implementation with the newer one from jraft - > [https://github.com/sofastack/sofa-jraft/issues/453.] > Given that we use shared log storage for multiple groups, we shouldn't > compare our storage with the one from jraft blindly, investigation is > required. Maybe we should port and update another storage before measuring > anything. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19851) Add MetaStorage update update listeners and use instead of configuration revision update listeners
[ https://issues.apache.org/jira/browse/IGNITE-19851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-19851: Assignee: Kirill Tkalenko > Add MetaStorage update update listeners and use instead of configuration > revision update listeners > -- > > Key: IGNITE-19851 > URL: https://issues.apache.org/jira/browse/IGNITE-19851 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > The main problem is described in IGNITE-19801, but due to the fact that we > now have code closely related to updating the configuration revision, it is > difficult to do everything at once in IGNITE-19801, so it will be divided > into parts. > In this task, I will add listeners for updating the revision of the > *MetaStorage* and replace it with its use in the production code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18548) Fix CdcIgniteToIgniteReplicationTest#testActivePassiveReplication flakiness
[
https://issues.apache.org/jira/browse/IGNITE-18548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18548:
---
Description:
A {{CdcIgniteToIgniteReplicationTest#testActivePassiveReplication}} test is
flaky. Sometimes it fails with reason as below (actual for 27/Jun/2023):
{code}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:35)
at
org.apache.ignite.cdc.AbstractReplicationTest.checkMetrics(AbstractReplicationTest.java:627)
at
org.apache.ignite.cdc.AbstractReplicationTest.checkMetrics(AbstractReplicationTest.java:595)
at
org.apache.ignite.cdc.AbstractReplicationTest.testActivePassiveReplication(AbstractReplicationTest.java:283)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2504)
{code}
Reason should be investigated and fixed.
Fails of the {{CdcIgniteToIgniteReplicationTest#testActivePassiveReplication}}
can occur with different test parameters:
# [clientType=CLIENT_NODE, atomicity=ATOMIC, mode=REPLICATED, backupCnt=0]:
[TC2 Build #342 at 12 Jan
11:09|https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6995624?hideProblemsFromDependencies=false=false=true=true],
build log: [^_TESTS_CDC_342.log.zip]
# [clientType=THIN_CLIENT, atomicity=TRANSACTIONAL, mode=REPLICATED,
backupCnt=0]:
[TC1 Build #410 at 11 Jan
08:00|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/7000973?hideProblemsFromDependencies=false=false=true=true],
build log: [^_TESTS_CDC_410.log.zip]
# [clientType=THIN_CLIENT, atomicity=ATOMIC, mode=REPLICATED, backupCnt=0],
[clientType=THIN_CLIENT, atomicity=TRANSACTIONAL, mode=PARTITIONED,
backupCnt=1]:
[TC1 Build #405 at 9 Jan
11:55|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6996965?hideProblemsFromDependencies=false=false=true=true],
build log: [^_TESTS_CDC_405.log.zip]
# [clientType=THIN_CLIENT, atomicity=ATOMIC, mode=PARTITIONED, backupCnt=1]:
[TC1 Build #402 at 31 Dec 22
08:02|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6986312?hideProblemsFromDependencies=false=false=true=true],
build log: [^_TESTS_CDC_402.log.zip]
was:
A {{CdcIgniteToIgniteReplicationTest#testActivePassiveReplication}} test is
flaky. Sometimes it fails with reason as below (actual for 2023/27/06):
{code}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:35)
at
org.apache.ignite.cdc.AbstractReplicationTest.checkMetrics(AbstractReplicationTest.java:627)
at
org.apache.ignite.cdc.AbstractReplicationTest.checkMetrics(AbstractReplicationTest.java:595)
at
org.apache.ignite.cdc.AbstractReplicationTest.testActivePassiveReplication(AbstractReplicationTest.java:283)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2504)
{code}
Reason should be investigated and fixed.
Fails of the {{CdcIgniteToIgniteReplicationTest#testActivePassiveReplication}}
can occur with different test parameters:
# [clientType=CLIENT_NODE, atomicity=ATOMIC, mode=REPLICATED, backupCnt=0]:
[TC2 Build #342 at 12 Jan
[jira] [Updated] (IGNITE-18548) Fix CdcIgniteToIgniteReplicationTest#testActivePassiveReplication flakiness
[
https://issues.apache.org/jira/browse/IGNITE-18548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18548:
---
Description:
A {{CdcIgniteToIgniteReplicationTest#testActivePassiveReplication}} test is
flaky. Sometimes it fails with reason as below (actual for 2023/27/06):
{code}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:35)
at
org.apache.ignite.cdc.AbstractReplicationTest.checkMetrics(AbstractReplicationTest.java:627)
at
org.apache.ignite.cdc.AbstractReplicationTest.checkMetrics(AbstractReplicationTest.java:595)
at
org.apache.ignite.cdc.AbstractReplicationTest.testActivePassiveReplication(AbstractReplicationTest.java:283)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2504)
{code}
Reason should be investigated and fixed.
Fails of the {{CdcIgniteToIgniteReplicationTest#testActivePassiveReplication}}
can occur with different test parameters:
# [clientType=CLIENT_NODE, atomicity=ATOMIC, mode=REPLICATED, backupCnt=0]:
[TC2 Build #342 at 12 Jan
11:09|https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6995624?hideProblemsFromDependencies=false=false=true=true],
build log: [^_TESTS_CDC_342.log.zip]
# [clientType=THIN_CLIENT, atomicity=TRANSACTIONAL, mode=REPLICATED,
backupCnt=0]:
[TC1 Build #410 at 11 Jan
08:00|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/7000973?hideProblemsFromDependencies=false=false=true=true],
build log: [^_TESTS_CDC_410.log.zip]
# [clientType=THIN_CLIENT, atomicity=ATOMIC, mode=REPLICATED, backupCnt=0],
[clientType=THIN_CLIENT, atomicity=TRANSACTIONAL, mode=PARTITIONED,
backupCnt=1]:
[TC1 Build #405 at 9 Jan
11:55|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6996965?hideProblemsFromDependencies=false=false=true=true],
build log: [^_TESTS_CDC_405.log.zip]
# [clientType=THIN_CLIENT, atomicity=ATOMIC, mode=PARTITIONED, backupCnt=1]:
[TC1 Build #402 at 31 Dec 22
08:02|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6986312?hideProblemsFromDependencies=false=false=true=true],
build log: [^_TESTS_CDC_402.log.zip]
was:
A {{CdcIgniteToIgniteReplicationTest#testActivePassiveReplication}} test is
flaky. Sometimes it fails with reason as below:
{code}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:35)
at
org.apache.ignite.cdc.AbstractReplicationTest.checkMetrics(AbstractReplicationTest.java:621)
at
org.apache.ignite.cdc.AbstractReplicationTest.checkMetrics(AbstractReplicationTest.java:589)
at
org.apache.ignite.cdc.AbstractReplicationTest.testActivePassiveReplication(AbstractReplicationTest.java:283)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2504)
at java.lang.Thread.run(Thread.java:750)
{code}
Reason should be investigated and fixed.
Fails of the {{CdcIgniteToIgniteReplicationTest#testActivePassiveReplication}}
can occur with different test parameters:
# [clientType=CLIENT_NODE, atomicity=ATOMIC, mode=REPLICATED, backupCnt=0]:
[TC2 Build #342 at 12 Jan
[jira] [Created] (IGNITE-19853) Get rid of InjectRevisionListenerHolder
Kirill Tkalenko created IGNITE-19853: Summary: Get rid of InjectRevisionListenerHolder Key: IGNITE-19853 URL: https://issues.apache.org/jira/browse/IGNITE-19853 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Fix For: 3.0.0-beta2 The main problem is described in IGNITE-19801, but due to the fact that we now have code closely related to updating the configuration revision, it is difficult to do everything at once in IGNITE-19801, so it will be divided into parts. In this ticket, we need to get rid of *InjectRevisionListenerHolder*, but this is not so easy to do because we need to somehow redo the tests that use this annotation for this. How to do this, I do not know exactly, but there are the following ideas: * Delete tests. * Convert them to integration. * Move interface implementation *ConfigurationStorage* into a separate module, honestly raise the meta storage and configuration registry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19120) Raft client should get leader metadata along while getting leader itself
[ https://issues.apache.org/jira/browse/IGNITE-19120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737513#comment-17737513 ] Vladislav Pyatkov commented on IGNITE-19120: [~maliev] [~Denis Chudov] Guys, please look at my PR. > Raft client should get leader metadata along while getting leader itself > > > Key: IGNITE-19120 > URL: https://issues.apache.org/jira/browse/IGNITE-19120 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > *Motivation* > This ticket is about TopologyAwareRaftGroupService which can subscribe on > leader change. Necessary metadata is last log index and last applied index in > leader's storage. > This will allow to remove readIndex requests on acceptance of a lease on > leaseholder candidate. As we know that no write commands in replication group > can happen in absence of leaseholder, this means that leaseholder should just > catch up leader's last log index received with leader metadata to make sure > that its local storage is up-to-date. Applied index can be not reliable as > leader may be being recovered and applied index maybe in progress of catch-up > with log index, but it might be useful to know applied index on leaseholder > candidate to justify time of waiting for actual storage state. > *Definition of done* > readIndex call is removed from Replica#waitForActualState. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19724) Remove redundant joins
[ https://issues.apache.org/jira/browse/IGNITE-19724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737512#comment-17737512 ] Kirill Gusakov commented on IGNITE-19724: - Also, under the separate issue we need to fix the joing for stopRelica in TableManager#cleanUpTablesResources > Remove redundant joins > -- > > Key: IGNITE-19724 > URL: https://issues.apache.org/jira/browse/IGNITE-19724 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > We have some redundant joins: > - > [this|https://github.com/apache/ignite-3/blob/7bcea31c9eb6350120584c1ca060131504927d04/modules/table/src/integrationTest/java/org/apache/ignite/distributed/ReplicaUnavailableTest.java#L199] > must be replaced by assertThat(replicaManager.stopReplica(testGrpId), > willSuccseesFast()); > - > [this|https://github.com/apache/ignite-3/blob/7bcea31c9eb6350120584c1ca060131504927d04/modules/replicator/src/main/java/org/apache/ignite/internal/replicator/ReplicaManager.java#L409] > can be replaced by chaining maybe, need to check > - Also need to review tests from > https://github.com/apache/ignite-3/commit/7bcea31c9eb6350120584c1ca060131504927d04 > for join -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19724) Remove redundant joins
[ https://issues.apache.org/jira/browse/IGNITE-19724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-19724: Description: We have some redundant joins: - [this|https://github.com/apache/ignite-3/blob/7bcea31c9eb6350120584c1ca060131504927d04/modules/table/src/integrationTest/java/org/apache/ignite/distributed/ReplicaUnavailableTest.java#L199] must be replaced by assertThat(replicaManager.stopReplica(testGrpId), willSuccseesFast()); - [this|https://github.com/apache/ignite-3/blob/7bcea31c9eb6350120584c1ca060131504927d04/modules/replicator/src/main/java/org/apache/ignite/internal/replicator/ReplicaManager.java#L409] can be replaced by chaining maybe, need to check - Also need to review tests from https://github.com/apache/ignite-3/commit/7bcea31c9eb6350120584c1ca060131504927d04 for join was: We have some redundant joins: - [this|https://github.com/apache/ignite-3/blob/7bcea31c9eb6350120584c1ca060131504927d04/modules/table/src/integrationTest/java/org/apache/ignite/distributed/ReplicaUnavailableTest.java#L199] must be replaced by assertThat(replicaManager.stopReplica(testGrpId), willSuccseesFast()); - [this|https://github.com/apache/ignite-3/blob/7bcea31c9eb6350120584c1ca060131504927d04/modules/replicator/src/main/java/org/apache/ignite/internal/replicator/ReplicaManager.java#L409] can be replaced by chaining maybe, need to check - In the TableManager#cleanUpTablesResources replace the join with get+timeout - Also need to review tests from https://github.com/apache/ignite-3/commit/7bcea31c9eb6350120584c1ca060131504927d04 for join > Remove redundant joins > -- > > Key: IGNITE-19724 > URL: https://issues.apache.org/jira/browse/IGNITE-19724 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > We have some redundant joins: > - > [this|https://github.com/apache/ignite-3/blob/7bcea31c9eb6350120584c1ca060131504927d04/modules/table/src/integrationTest/java/org/apache/ignite/distributed/ReplicaUnavailableTest.java#L199] > must be replaced by assertThat(replicaManager.stopReplica(testGrpId), > willSuccseesFast()); > - > [this|https://github.com/apache/ignite-3/blob/7bcea31c9eb6350120584c1ca060131504927d04/modules/replicator/src/main/java/org/apache/ignite/internal/replicator/ReplicaManager.java#L409] > can be replaced by chaining maybe, need to check > - Also need to review tests from > https://github.com/apache/ignite-3/commit/7bcea31c9eb6350120584c1ca060131504927d04 > for join -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19852) Deal with RecoveryCompletionFutureFactory
Kirill Tkalenko created IGNITE-19852: Summary: Deal with RecoveryCompletionFutureFactory Key: IGNITE-19852 URL: https://issues.apache.org/jira/browse/IGNITE-19852 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Fix For: 3.0.0-beta2 The main problem is described in IGNITE-19801, but due to the fact that we now have code closely related to updating the configuration revision, it is difficult to do everything at once in IGNITE-19801, so it will be divided into parts. As part of ticket IGNITE-19777, we will have a new meta storage recovery mechanism, so we need to do something with *RecoveryCompletionFutureFactory*, I think that in general we can get rid of it, but this needs to be checked more carefully. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19851) Add MetaStorage update update listeners and use instead of configuration revision update listeners
[ https://issues.apache.org/jira/browse/IGNITE-19851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-19851: - Environment: (was: The main problem is described in IGNITE-19801, but due to the fact that we now have code closely related to updating the configuration revision, it is difficult to do everything at once in IGNITE-19801, so it will be divided into parts. In this task, I will add listeners for updating the revision of the *MetaStorage* and replace it with its use in the production code.) > Add MetaStorage update update listeners and use instead of configuration > revision update listeners > -- > > Key: IGNITE-19851 > URL: https://issues.apache.org/jira/browse/IGNITE-19851 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19851) Add MetaStorage update update listeners and use instead of configuration revision update listeners
Kirill Tkalenko created IGNITE-19851: Summary: Add MetaStorage update update listeners and use instead of configuration revision update listeners Key: IGNITE-19851 URL: https://issues.apache.org/jira/browse/IGNITE-19851 Project: Ignite Issue Type: Improvement Environment: The main problem is described in IGNITE-19801, but due to the fact that we now have code closely related to updating the configuration revision, it is difficult to do everything at once in IGNITE-19801, so it will be divided into parts. In this task, I will add listeners for updating the revision of the *MetaStorage* and replace it with its use in the production code. Reporter: Kirill Tkalenko Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19851) Add MetaStorage update update listeners and use instead of configuration revision update listeners
[ https://issues.apache.org/jira/browse/IGNITE-19851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-19851: - Description: The main problem is described in IGNITE-19801, but due to the fact that we now have code closely related to updating the configuration revision, it is difficult to do everything at once in IGNITE-19801, so it will be divided into parts. In this task, I will add listeners for updating the revision of the *MetaStorage* and replace it with its use in the production code. > Add MetaStorage update update listeners and use instead of configuration > revision update listeners > -- > > Key: IGNITE-19851 > URL: https://issues.apache.org/jira/browse/IGNITE-19851 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > The main problem is described in IGNITE-19801, but due to the fact that we > now have code closely related to updating the configuration revision, it is > difficult to do everything at once in IGNITE-19801, so it will be divided > into parts. > In this task, I will add listeners for updating the revision of the > *MetaStorage* and replace it with its use in the production code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19850) Fix metastorage unable to recover with multiple ms nodes
Semyon Danilov created IGNITE-19850: --- Summary: Fix metastorage unable to recover with multiple ms nodes Key: IGNITE-19850 URL: https://issues.apache.org/jira/browse/IGNITE-19850 Project: Ignite Issue Type: Bug Reporter: Semyon Danilov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19849) Generate transaction id in client side
[
https://issues.apache.org/jira/browse/IGNITE-19849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-19849:
---
Description:
*Motivation*
Currently, transaction id is generated on a server node (the node is also
called a transaction coordinator):
{code}
HybridTimestamp beginTimestamp = clock.now();
UUID txId = transactionIdGenerator.transactionIdFor(beginTimestamp);
{code}
The transaction id has start time internally. In other word, when we call
{{transactions().begin()}} we define a time when the transaction is started.
The time is used in deadlock resolution mechanism.
In case when the clock on different nodes slightly skewed we may receive
different order unlike that we have in client side. Because the transactions
have various coordinators with their clocks. Of course, unexpected behavior of
deadlock resolution is taken a place here.
*Definition of done*
Transaction id is generated on client side, then passes to server. The server
starts the transaction with a predefined id.
The transaction's order is defined in client side regardless of clock on
servers.
was:
*Motivation*
Currently, transaction id is generated on a server node (the node is also
called a transaction coordinator):
{code}
HybridTimestamp beginTimestamp = clock.now();
UUID txId = transactionIdGenerator.transactionIdFor(beginTimestamp);
{code}
Transaction id has start time internally. In other word, when we call
{{transactions().begin()}} we define a time when the transaction is started.
The time is used in deadlock resolution mechanism.
In case when the clock on different nodes slightly skewed we may receive
different order unlike that we have in client side. Because the transactions
have various coordinators with their clocks. Of course, unexpected behavior of
deadlock resolution is taken a place here.
*Definition of done*
Transaction id is generated on client side, then passes to server. The server
starts the transaction with a predefined id.
The transaction's order is defined in client side regardless of clock on
servers.
> Generate transaction id in client side
> --
>
> Key: IGNITE-19849
> URL: https://issues.apache.org/jira/browse/IGNITE-19849
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Currently, transaction id is generated on a server node (the node is also
> called a transaction coordinator):
> {code}
> HybridTimestamp beginTimestamp = clock.now();
> UUID txId = transactionIdGenerator.transactionIdFor(beginTimestamp);
> {code}
> The transaction id has start time internally. In other word, when we call
> {{transactions().begin()}} we define a time when the transaction is started.
> The time is used in deadlock resolution mechanism.
> In case when the clock on different nodes slightly skewed we may receive
> different order unlike that we have in client side. Because the transactions
> have various coordinators with their clocks. Of course, unexpected behavior
> of deadlock resolution is taken a place here.
> *Definition of done*
> Transaction id is generated on client side, then passes to server. The server
> starts the transaction with a predefined id.
> The transaction's order is defined in client side regardless of clock on
> servers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19849) Generate transaction id in client side
Vladislav Pyatkov created IGNITE-19849:
--
Summary: Generate transaction id in client side
Key: IGNITE-19849
URL: https://issues.apache.org/jira/browse/IGNITE-19849
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
*Motivation*
Currently, transaction id is generated on a server node (the node is also
called a transaction coordinator):
{code}
HybridTimestamp beginTimestamp = clock.now();
UUID txId = transactionIdGenerator.transactionIdFor(beginTimestamp);
{code}
Transaction id has start time internally. In other word, when we call
{{transactions().begin()}} we define a time when the transaction is started.
The time is used in deadlock resolution mechanism.
In case when the clock on different nodes slightly skewed we may receive
different order unlike that we have in client side. Because the transactions
have various coordinators with their clocks. Of course, unexpected behavior of
deadlock resolution is taken a place here.
*Definition of done*
Transaction id is generated on client side, then passes to server. The server
starts the transaction with a predefined id.
The transaction's order is defined in client side regardless of clock on
servers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19368) Fix ignite-cdc-ext assembly
[ https://issues.apache.org/jira/browse/IGNITE-19368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-19368: --- Description: Currently, _kafka-clients_ and _slf4j-api_ libraries are missing in the assembled zip file. It have been happened after IGNITE-19237. Assembly can be fixed in the same way as it was done in performance statistics module [1]. # https://github.com/apache/ignite-extensions/blob/b7dd81fb7d9c41f35afb7dc10d060f685dfeac6f/modules/performance-statistics-ext/pom.xml#L152 was: Currently, _kafka-clients_ and _slf4j-api_ libraries are missing in the assembled zip file. It have been happened after IGNITE-19237. Assembly can be fixed like it was done in performance statistics module [1]. # https://github.com/apache/ignite-extensions/blob/b7dd81fb7d9c41f35afb7dc10d060f685dfeac6f/modules/performance-statistics-ext/pom.xml#L152 > Fix ignite-cdc-ext assembly > --- > > Key: IGNITE-19368 > URL: https://issues.apache.org/jira/browse/IGNITE-19368 > Project: Ignite > Issue Type: Bug > Components: extensions >Reporter: Ilya Shishkov >Assignee: Ilya Shishkov >Priority: Major > Labels: IEP-59, ise > > Currently, _kafka-clients_ and _slf4j-api_ libraries are missing in the > assembled zip file. It have been happened after IGNITE-19237. Assembly can be > fixed in the same way as it was done in performance statistics module [1]. > # > https://github.com/apache/ignite-extensions/blob/b7dd81fb7d9c41f35afb7dc10d060f685dfeac6f/modules/performance-statistics-ext/pom.xml#L152 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19848) User object serialization
Mikhail Pochatkin created IGNITE-19848: -- Summary: User object serialization Key: IGNITE-19848 URL: https://issues.apache.org/jira/browse/IGNITE-19848 Project: Ignite Issue Type: Epic Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
