[jira] [Created] (IGNITE-21521) Wrong update order in DataStreamer for a new key
Pavel Tupitsyn created IGNITE-21521: --- Summary: Wrong update order in DataStreamer for a new key Key: IGNITE-21521 URL: https://issues.apache.org/jira/browse/IGNITE-21521 Project: Ignite Issue Type: Bug Components: streaming 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] [Assigned] (IGNITE-20593) Sql. Add implicit cast coercion rules to DdlSqlToCommandConverter.
[
https://issues.apache.org/jira/browse/IGNITE-20593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-20593:
---
Assignee: Evgeny Stanilovsky
> Sql. Add implicit cast coercion rules to DdlSqlToCommandConverter.
> --
>
> Key: IGNITE-20593
> URL: https://issues.apache.org/jira/browse/IGNITE-20593
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Evgeny Stanilovsky
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> In order to make behaviour of types in DDL commands consistent with other SQL
> statements, we need to update `DdlSqlToCommandConverter` to make it in sync
> with implicit type coercion rules
> - if type T1 can be converted from T2, then DEFAULT for type T1 can accept
> values of type T2.
> Example:
> {code:java}
> @Test
> public void testDdl() {
> sql("CREATE TABLE date_dim (id INTEGER PRIMARY KEY, dim DATE DEFAULT
> '2000-01-01')");
> }
> //ERROR:
> Caused by: java.lang.ClassCastException: class
> org.apache.calcite.sql.SqlCharStringLiteral cannot be cast to class
> org.apache.calcite.sql.SqlUnknownLiteral
> (org.apache.calcite.sql.SqlCharStringLiteral and
> org.apache.calcite.sql.SqlUnknownLiteral are in unnamed module of loader
> 'app')
> at
> org.apache.ignite.internal.sql.engine.prepare.ddl.DdlSqlToCommandConverter.fromLiteral(DdlSqlToCommandConverter.java:837)
> ... 18 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21102) Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
[
https://issues.apache.org/jira/browse/IGNITE-21102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816866#comment-17816866
]
Ignite TC Bot commented on IGNITE-21102:
{panel:title=Branch: [pull/11138/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11138/head] Base: [master] : New Tests
(16)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin Client: Java{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7745245]]
* {color:#013220}ClientTestSuite:
ServiceAwarenessTest.testServiceAwarenessEnabled - PASSED{color}
{color:#8b}Calcite SQL{color} [[tests
5|https://ci2.ignite.apache.org/viewLog.html?buildId=7745183]]
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexIntegrationTest.testNulls - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexIntegrationTest.testNot - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexIntegrationTest.testOrdering - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexIntegrationTest.testIn - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexIntegrationTest.testRange - PASSED{color}
{color:#8b}Control Utility 1{color} [[tests
4|https://ci2.ignite.apache.org/viewLog.html?buildId=7745193]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerTest.testClusterStateInBaselineCommand[cmdHnd=jmx] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerTest.testClusterStateInBaselineCommand[cmdHnd=cli] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerWithSslTest.testClusterStateInBaselineCommand[cmdHnd=cli] -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerWithSslFactoryTest.testClusterStateInBaselineCommand[cmdHnd=cli]
- PASSED{color}
{color:#8b}Security{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7745236]]
* {color:#013220}SecurityTestSuite:
NodeJoinPermissionsTest.testNodeJoinPermissions[isLegacyAuthorizationApproach=false]
- PASSED{color}
* {color:#013220}SecurityTestSuite:
NodeJoinPermissionsTest.testNodeJoinPermissions[isLegacyAuthorizationApproach=true]
- PASSED{color}
{color:#8b}ZooKeeper (Discovery) 4{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7745253]]
* {color:#013220}ZookeeperDiscoverySpiTestSuite4:
NodeJoinPermissionsTest.testNodeJoinPermissions[isLegacyAuthorizationApproach=false]
- PASSED{color}
* {color:#013220}ZookeeperDiscoverySpiTestSuite4:
NodeJoinPermissionsTest.testNodeJoinPermissions[isLegacyAuthorizationApproach=true]
- PASSED{color}
{color:#8b}Control Utility (Zookeeper){color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7745194]]
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerTest.testClusterStateInBaselineCommand[cmdHnd=jmx] -
PASSED{color}
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerTest.testClusterStateInBaselineCommand[cmdHnd=cli] -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7745260buildTypeId=IgniteTests24Java8_RunAll]
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
> -
>
> Key: IGNITE-21102
> URL: https://issues.apache.org/jira/browse/IGNITE-21102
> Project: Ignite
> Issue Type: Bug
>Reporter: Julia Bakulina
>Assignee: Oleg Valuyskiy
>Priority: Major
> Labels: ise
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline.
> org.apache.ignite.internal.commandline.BaselineCommand#baselinePrint0
> {code:java}
> logger.info("Cluster state: " + (res.isActive() ? "active" :
> "inactive"));
> {code}
> org.apache.ignite.cluster.ClusterState#ACTIVE_READ_ONLY
>
> An example of changing the cluster state:
> {code:java}
> Command [SET-STATE] started
> Arguments: ... --set-state ACTIVE_READ_ONLY
>
> Cluster state changed to ACTIVE_READ_ONLY
> Command [SET-STATE] finished with code: 0 {code}
> Cluster state in control.sh --baseline
> {code:java}
> Command [BASELINE] started
> Arguments: ... --baseline
>
> Cluster state: active
> Current topology version: 1
> Baseline auto adjustment disabled:...
> Current topology version: 1 (...)
> Baseline nodes:
> ...
>
> Number of baseline nodes: 1
> Other nodes not found.
> Command
[jira] (IGNITE-21520) Update Ignite version in TeamCity bot
[ https://issues.apache.org/jira/browse/IGNITE-21520 ] Oleg Valuyskiy deleted comment on IGNITE-21520: - was (Author: JIRAUSER303481): PR: https://github.com/apache/ignite-teamcity-bot/pull/195 > Update Ignite version in TeamCity bot > - > > Key: IGNITE-21520 > URL: https://issues.apache.org/jira/browse/IGNITE-21520 > Project: Ignite > Issue Type: Task >Reporter: Oleg Valuyskiy >Assignee: Oleg Valuyskiy >Priority: Minor > Labels: ise > > With the availability of the 2.16 Ignite version, it is advisable to update > the version of Ignite from 2.14 to 2.16 in TeamCity bot. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21520) Update Ignite version in TeamCity bot
[ https://issues.apache.org/jira/browse/IGNITE-21520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816829#comment-17816829 ] Oleg Valuyskiy commented on IGNITE-21520: - PR: https://github.com/apache/ignite-teamcity-bot/pull/195 > Update Ignite version in TeamCity bot > - > > Key: IGNITE-21520 > URL: https://issues.apache.org/jira/browse/IGNITE-21520 > Project: Ignite > Issue Type: Task >Reporter: Oleg Valuyskiy >Assignee: Oleg Valuyskiy >Priority: Minor > Labels: ise > > With the availability of the 2.16 Ignite version, it is advisable to update > the version of Ignite from 2.14 to 2.16 in TeamCity bot. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21520) Update Ignite version in TeamCity bot
Oleg Valuyskiy created IGNITE-21520: --- Summary: Update Ignite version in TeamCity bot Key: IGNITE-21520 URL: https://issues.apache.org/jira/browse/IGNITE-21520 Project: Ignite Issue Type: Task Reporter: Oleg Valuyskiy Assignee: Oleg Valuyskiy With the availability of the 2.16 Ignite version, it is advisable to update the version of Ignite from 2.14 to 2.16 in TeamCity bot. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21504) Sql. PlanningCacheMetricsTest.plannerCacheStatisticsTest is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-21504: -- Priority: Minor (was: Major) > Sql. PlanningCacheMetricsTest.plannerCacheStatisticsTest is flaky. > --- > > Key: IGNITE-21504 > URL: https://issues.apache.org/jira/browse/IGNITE-21504 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Cache implementation used for SQL plan uses common ForkJoin pool for clean up > task, so cache eviction events can be delayed, thus producing hit events, > when no such events expected by test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21504) Sql. PlanningCacheMetricsTest.plannerCacheStatisticsTest is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-21504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-21504: -- Affects Version/s: 3.0.0-beta2 > Sql. PlanningCacheMetricsTest.plannerCacheStatisticsTest is flaky. > --- > > Key: IGNITE-21504 > URL: https://issues.apache.org/jira/browse/IGNITE-21504 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Cache implementation used for SQL plan uses common ForkJoin pool for clean up > task, so cache eviction events can be delayed, thus producing hit events, > when no such events expected by test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21510) Doc: how to start multiple nodes in the same machine
[ https://issues.apache.org/jira/browse/IGNITE-21510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-21510: -- Assignee: Aleksandr > Doc: how to start multiple nodes in the same machine > > > Key: IGNITE-21510 > URL: https://issues.apache.org/jira/browse/IGNITE-21510 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > Add documentation about how to start more then one node in the same machine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21519) Improve test coverage for Java API for SQL
Iurii Gerzhedovich created IGNITE-21519: --- Summary: Improve test coverage for Java API for SQL Key: IGNITE-21519 URL: https://issues.apache.org/jira/browse/IGNITE-21519 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich During implementation of Java API for SQL were added set of tests. However added set of tests is insufficient. Let's add the following test scenarios: * Ability to recover an SQL session by session identifier during client reconnection to the server. * Statement properties could reload the session properties. * The statement is immutable and can be used in different threads and different sessions. * Check the system's reaction to any actions with a closed session. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21381) ActiveActorTest#testChangeLeaderForce has problems with resource cleanup
[
https://issues.apache.org/jira/browse/IGNITE-21381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816547#comment-17816547
]
Denis Chudov edited comment on IGNITE-21381 at 2/12/24 3:12 PM:
As we have a PR already that is intended to fix resource leak (
[https://github.com/apache/ignite-3/pull/3150] ), I created a new ticket to fix
the flaky test and make a refactoring IGNITE-21513
TC logs appeared to be misleading because of reordered messages (see time). The
actual problem of the test was the race due to the lack of joins on a futures
from #subscribeLeader().
was (Author: denis chudov):
As we have a PR already that is intended to fix resource leak (
https://github.com/apache/ignite-3/pull/3150 ), I created a new ticket to fix
the flaky test and make a refactoring IGNITE-21513
> ActiveActorTest#testChangeLeaderForce has problems with resource cleanup
>
>
> Key: IGNITE-21381
> URL: https://issues.apache.org/jira/browse/IGNITE-21381
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{ActiveActorTest#testChangeLeaderForce}} is started to be flaky on TC with
> {noformat}
> [05:19:12]F:
> [org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
> 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.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370)
> {noformat}
> From the log we can see that transfer leadership, which was supposed to be
> successful, do not happen. Behaviour is the following:
> 1) Current leader is {{Leader: ClusterNodeImpl
> [id=e99210fb-f872-4e08-a99c-53f9512da20e, name=aat_tclf_1235}}
> 2) We want to transfer leadership to {{Peer to transfer leader: Peer
> [consistentId=aat_tclf_1234, idx=0]}}
> 3) Process of transfer is started
> 4) We receive warn about error during {{GetLeaderRequestImpl}}:
> {noformat}
> [2024-01-29T05:19:08,855][WARN
> ][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable error
> during the request occurred (will be retried on the randomly selected node)
> [request=GetLeaderRequestImpl [groupId=TestReplicationGroup,
> peerId=aat_tclf_1235], peer=Peer [consistentId=aat_tclf_1235, idx=0],
> newPeer=Peer [consistentId=aat_tclf_1234, idx=0]].
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> [?:?]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
> [?:?]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.util.concurrent.TimeoutException
> ... 7 more
> {noformat}
> 5) After that we see that node {{aat_tclf_1236}} sends invalid
> {{RequestVoteResponse}} because it thinks that it is the leader:
> {noformat}
> [2024-01-29T05:19:11,370][WARN
> ][%aat_tclf_1234%JRaft-Response-Processor-15][NodeImpl] Node
> received invalid RequestVoteResponse
> from aat_tclf_1236, state not in STATE_CANDIDATE but STATE_LEADER.
> {noformat}
>
> Tests
[jira] [Updated] (IGNITE-21513) ActiveActorTest#testChangeLeaderForce is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21513:
--
Description:
{code:java}
[05:19:12]F:
[org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
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.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370){code}
See IGNITE-21381 for more details. This ticket is about fixing flaky test and
removing the code duplication between ActiveActorTest and
TopologyAwareRaftGroupServiceTest.
was:
{code:java}
[05:19:12]F:
[org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
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.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370){code}
> ActiveActorTest#testChangeLeaderForce is flaky
> --
>
> Key: IGNITE-21513
> URL: https://issues.apache.org/jira/browse/IGNITE-21513
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [05:19:12]F:
> [org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
> 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.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370){code}
> See IGNITE-21381 for more details. This ticket is about fixing flaky test and
> removing the code duplication between ActiveActorTest and
> TopologyAwareRaftGroupServiceTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21518) Sql. Improve test coverage for DDL
[ https://issues.apache.org/jira/browse/IGNITE-21518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-21518: Epic Link: IGNITE-20729 > Sql. Improve test coverage for DDL > -- > > Key: IGNITE-21518 > URL: https://issues.apache.org/jira/browse/IGNITE-21518 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > During implementation of DDL were added set of tests. However added set of > tests is insufficient. > Let's add the following test scenarios: > h4. Unit Testing: > * Tests for SQL parser required additional test to for each DDL command, > every option, every data type. Partial already covered, but not for all data > types > * Tests for components that handle DDL commands: test case each DDL command, > every option, every data type. Partialy already covered, but not for all data > types. > h4. Functional and E2E tests: > TABLE: > * Effects of DDL operations should be observable via all access API. Partialy > already covered, but not for all combinations of data type and API access > type. > * check that it is possible to perform operations against a newly created > table via all available APIs. > * check that primary key columns are not modifiable (no SQL tests). > DEFAULTS: > * check that a column is set to a value equal to DEFAULT, if the DEFAULT > keyword is used in insert operation instead of a value (not all types are > covered right now). > * check that it is not allowed to set a value of another type as DEFAULT > value (some types are not covered). > * check that a value specified as DEFAULT lies in the domain of values for > that data type. > * check that DEFAULT does not support expressions - only literals and > function names. > * check that null constraint makes columns nullable. > * check that DROP DEFAULT is supported. > INDEX: > * check that if an index type is not specified (via USING clause), a tree > (sorted) index is created. > * Sorted/Tree index should support NULLS FIRST, NULLS LAST options for both > ASC and DESC orderings. > * check that after an index is dropped plans that previously used an index no > longer use such index. > TRANSACTIONS: > * execution of a DDL operation via JDBC Connection with auto-commit flag set > to false return an error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21518) Sql. Improve test coverage for DDL
Iurii Gerzhedovich created IGNITE-21518: --- Summary: Sql. Improve test coverage for DDL Key: IGNITE-21518 URL: https://issues.apache.org/jira/browse/IGNITE-21518 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich During implementation of DDL were added set of tests. However added set of tests is insufficient. Let's add the following test scenarios: h4. Unit Testing: * Tests for SQL parser required additional test to for each DDL command, every option, every data type. Partial already covered, but not for all data types * Tests for components that handle DDL commands: test case each DDL command, every option, every data type. Partialy already covered, but not for all data types. h4. Functional and E2E tests: TABLE: * Effects of DDL operations should be observable via all access API. Partialy already covered, but not for all combinations of data type and API access type. * check that it is possible to perform operations against a newly created table via all available APIs. * check that primary key columns are not modifiable (no SQL tests). DEFAULTS: * check that a column is set to a value equal to DEFAULT, if the DEFAULT keyword is used in insert operation instead of a value (not all types are covered right now). * check that it is not allowed to set a value of another type as DEFAULT value (some types are not covered). * check that a value specified as DEFAULT lies in the domain of values for that data type. * check that DEFAULT does not support expressions - only literals and function names. * check that null constraint makes columns nullable. * check that DROP DEFAULT is supported. INDEX: * check that if an index type is not specified (via USING clause), a tree (sorted) index is created. * Sorted/Tree index should support NULLS FIRST, NULLS LAST options for both ASC and DESC orderings. * check that after an index is dropped plans that previously used an index no longer use such index. TRANSACTIONS: * execution of a DDL operation via JDBC Connection with auto-commit flag set to false return an error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19608) Startup errors are ignored in ignite3db script
[
https://issues.apache.org/jira/browse/IGNITE-19608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin reassigned IGNITE-19608:
--
Assignee: Mikhail Pochatkin
> Startup errors are ignored in ignite3db script
> --
>
> Key: IGNITE-19608
> URL: https://issues.apache.org/jira/browse/IGNITE-19608
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1, 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Mikhail Pochatkin
>Priority: Blocker
> Labels: cli, ignite-3
>
> Ignite3 node is started by `bin/ignite3db` shell script. Unfortunately, this
> script follows some shell scripting bad practices that makes troubleshooting
> harder when something goes wrong.
> Particullary, there are following issues:
> 1. No guarding bash options (like `nounset`, `errexit`, or `pipefile`) is set.
> 2. When starting Java application, its stderr and stdout are redirected into
> `/dev/null`.
> {code:bash}
> CMD="${JAVA_CMD_WITH_ARGS} ${APPLICATION_ARGS}"
> $CMD >>/dev/null 2>&1 ${IGNITE_HOME}/pid
> {code}
> Just for comparison: [control.sh in
> AI2|https://github.com/apache/ignite/blob/master/bin/control.sh] do not
> suffer from such behavior. This should be fixed in AI3 too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21517) Add thread assertions to TxStateStorage
[ https://issues.apache.org/jira/browse/IGNITE-21517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21517: --- Description: Everywhere we invoke TxStateStorage methods, we must assert that the corresponding storage operations are allowed to be executed in the current thread. > Add thread assertions to TxStateStorage > --- > > Key: IGNITE-21517 > URL: https://issues.apache.org/jira/browse/IGNITE-21517 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Everywhere we invoke TxStateStorage methods, we must assert that the > corresponding storage operations are allowed to be executed in the current > thread. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21517) Add thread assertions to TxStateStorage
Roman Puchkovskiy created IGNITE-21517: -- Summary: Add thread assertions to TxStateStorage Key: IGNITE-21517 URL: https://issues.apache.org/jira/browse/IGNITE-21517 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21508) Move storage operations from critical threads
[ https://issues.apache.org/jira/browse/IGNITE-21508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21508: --- Description: Sometimes storages are accessed from threads that are not designed to be blocked/perform I/O. Such accesses need to be moved to suitable threads. > Move storage operations from critical threads > - > > Key: IGNITE-21508 > URL: https://issues.apache.org/jira/browse/IGNITE-21508 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Sometimes storages are accessed from threads that are not designed to be > blocked/perform I/O. Such accesses need to be moved to suitable threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21507) Improve test coverege for colocation functionality
[ https://issues.apache.org/jira/browse/IGNITE-21507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich reassigned IGNITE-21507: --- Assignee: (was: Iurii Gerzhedovich) > Improve test coverege for colocation functionality > -- > > Key: IGNITE-21507 > URL: https://issues.apache.org/jira/browse/IGNITE-21507 > Project: Ignite > Issue Type: Improvement >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > During implementation of IGNITE-16603 were added set of tests. However added > set of tests is insufficient. Let's increase testc coverage for the following > test cases: > Integration tests: > * Ensure colocation columns order leads to different distributions. > * Ensure SQL JOIN on all the colocation columns leads to a plan with > non-distributive join operation. > * Ensure compute affinityCall always runs on the affinity node. > * > Failover Testing: > * Ensures colocation column information survives grid restart. > # Start a cluster. > # Create a table with colocated columns specified. > # Restart the cluster. > # Check a Catalog table descriptor still contains colocation columns. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21516) Add JobStatus.queuePosition
[ https://issues.apache.org/jira/browse/IGNITE-21516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21516: Labels: ignite-3 (was: ) > Add JobStatus.queuePosition > --- > > Key: IGNITE-21516 > URL: https://issues.apache.org/jira/browse/IGNITE-21516 > Project: Ignite > Issue Type: Improvement > Components: compute >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Add *JobStatus.queuePosition* property: as a user, I'd like to know the > position of my job in the queue and observe the effect of > *JobExecution.changePriority*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21516) Add JobStatus.queuePosition
[ https://issues.apache.org/jira/browse/IGNITE-21516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21516: Ignite Flags: (was: Docs Required,Release Notes Required) > Add JobStatus.queuePosition > --- > > Key: IGNITE-21516 > URL: https://issues.apache.org/jira/browse/IGNITE-21516 > Project: Ignite > Issue Type: Improvement > Components: compute >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Add *JobStatus.queuePosition* property: as a user, I'd like to know the > position of my job in the queue and observe the effect of > *JobExecution.changePriority*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21516) Add JobStatus.queuePosition
Pavel Tupitsyn created IGNITE-21516: --- Summary: Add JobStatus.queuePosition Key: IGNITE-21516 URL: https://issues.apache.org/jira/browse/IGNITE-21516 Project: Ignite Issue Type: Improvement Components: compute Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Mikhail Pochatkin Fix For: 3.0.0-beta2 Add *JobStatus.queuePosition* property: as a user, I'd like to know the position of my job in the queue and observe the effect of *JobExecution.changePriority*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16620) Flacky test LocalSnapshotCopierTest#testInterrupt
[
https://issues.apache.org/jira/browse/IGNITE-16620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-16620:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Flacky test LocalSnapshotCopierTest#testInterrupt
> -
>
> Key: IGNITE-16620
> URL: https://issues.apache.org/jira/browse/IGNITE-16620
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Ermakov
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
>
> org.apache.ignite.raft.jraft.storage.snapshot.local.LocalSnapshotCopierTest#testInterrupt
> test seems flacky.
> To reproduce: run the test cyclically until it failure.
> Reason:
> Code in LocalSnashotCopier#loadMetaTable
> {code:java}
> if (!session.status().isOk() && isOk()) {code}
> doesn't expect that the LocalSnashotCopier object's internal state (which is
> checked in isOk() method) could be changed by another thread, and is set to
> interrupted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-16620) Flacky test LocalSnapshotCopierTest#testInterrupt
[
https://issues.apache.org/jira/browse/IGNITE-16620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin reassigned IGNITE-16620:
Assignee: Alexander Lapin
> Flacky test LocalSnapshotCopierTest#testInterrupt
> -
>
> Key: IGNITE-16620
> URL: https://issues.apache.org/jira/browse/IGNITE-16620
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Ermakov
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
>
> org.apache.ignite.raft.jraft.storage.snapshot.local.LocalSnapshotCopierTest#testInterrupt
> test seems flacky.
> To reproduce: run the test cyclically until it failure.
> Reason:
> Code in LocalSnashotCopier#loadMetaTable
> {code:java}
> if (!session.status().isOk() && isOk()) {code}
> doesn't expect that the LocalSnashotCopier object's internal state (which is
> checked in isOk() method) could be changed by another thread, and is set to
> interrupted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-16620) Flacky test LocalSnapshotCopierTest#testInterrupt
[
https://issues.apache.org/jira/browse/IGNITE-16620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin resolved IGNITE-16620.
--
Resolution: Cannot Reproduce
> Flacky test LocalSnapshotCopierTest#testInterrupt
> -
>
> Key: IGNITE-16620
> URL: https://issues.apache.org/jira/browse/IGNITE-16620
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Ermakov
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
>
> org.apache.ignite.raft.jraft.storage.snapshot.local.LocalSnapshotCopierTest#testInterrupt
> test seems flacky.
> To reproduce: run the test cyclically until it failure.
> Reason:
> Code in LocalSnashotCopier#loadMetaTable
> {code:java}
> if (!session.status().isOk() && isOk()) {code}
> doesn't expect that the LocalSnashotCopier object's internal state (which is
> checked in isOk() method) could be changed by another thread, and is set to
> interrupted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20415) Internal IncompatibleSchemaException is thrown from public API
[
https://issues.apache.org/jira/browse/IGNITE-20415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Pligin updated IGNITE-20415:
-
Priority: Critical (was: Blocker)
> Internal IncompatibleSchemaException is thrown from public API
> --
>
> Key: IGNITE-20415
> URL: https://issues.apache.org/jira/browse/IGNITE-20415
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Roman Puchkovskiy
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following code throws internal exception from public API (add to
> *ItSqlSynchronousApiTest* and run):
> {code:java}
> @Test
> public void schemaMigration() {
> IgniteSql sql = igniteSql();
> Session ses = sql.createSession();
> checkDdl(true, ses, "CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0
> INT)");
> var view = CLUSTER_NODES.get(0).tables().table("TEST").recordView();
> var upsertFut = CompletableFuture.runAsync(() -> {
> for (int i = 0; i < 1000; i++) {
> view.upsert(null, Tuple.create().set("ID", i).set("VAL0", i));
> }
> });
> checkDdl(true, ses, "ALTER TABLE TEST ADD COLUMN VAL1 INT DEFAULT
> -1");
> upsertFut.join();
> }
> {code}
> *Result:*
> {code}
> java.util.concurrent.CompletionException:
> org.apache.ignite.internal.table.distributed.replicator.IncompatibleSchemaException:
> IGN-TX-12 TraceId:52bbae8c-4706-4394-8bd3-30bac5747da5 Table schema was
> updated after the transaction was started [table=1, startSchema=1,
> operationSchema=2]
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:683)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
> ~[?:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.validateAtTimestampAndBuildUpdateCommand(PartitionReplicaListener.java:2643)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.validateAtTimestampAndBuildUpdateCommand(PartitionReplicaListener.java:2586)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processSingleEntryAction$109(PartitionReplicaListener.java:2058)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> ~[?:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processSingleEntryAction$112(PartitionReplicaListener.java:2058)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.continueResolvingByPk(PartitionReplicaListener.java:1448)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$resolveRowByPk$68(PartitionReplicaListener.java:1428)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> ~[?:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.resolveRowByPk(PartitionReplicaListener.java:1419)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processSingleEntryAction(PartitionReplicaListener.java:2048)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$2(PartitionReplicaListener.java:363)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1494)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processRequest(PartitionReplicaListener.java:363)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
>
[jira] [Assigned] (IGNITE-21515) Enable assertions for Idea test runner
[ https://issues.apache.org/jira/browse/IGNITE-21515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-21515: Reviewer: Ivan Bessonov Assignee: Mirza Aliev > Enable assertions for Idea test runner > --- > > Key: IGNITE-21515 > URL: https://issues.apache.org/jira/browse/IGNITE-21515 > Project: Ignite > Issue Type: Bug >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21515) Enable assertions for Idea test runner
[ https://issues.apache.org/jira/browse/IGNITE-21515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-21515: - Summary: Enable assertions for Idea test runner (was: Enable assertions in Idea test runner ) > Enable assertions for Idea test runner > --- > > Key: IGNITE-21515 > URL: https://issues.apache.org/jira/browse/IGNITE-21515 > Project: Ignite > Issue Type: Bug >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21515) Enable assertions in Idea test runner
[ https://issues.apache.org/jira/browse/IGNITE-21515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-21515: - Summary: Enable assertions in Idea test runner (was: Fix assertion in Idea test runner ) > Enable assertions in Idea test runner > -- > > Key: IGNITE-21515 > URL: https://issues.apache.org/jira/browse/IGNITE-21515 > Project: Ignite > Issue Type: Bug >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21515) Fix assertion in Idea test runner
Mirza Aliev created IGNITE-21515: Summary: Fix assertion in Idea test runner Key: IGNITE-21515 URL: https://issues.apache.org/jira/browse/IGNITE-21515 Project: Ignite Issue Type: Bug Reporter: Mirza Aliev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21481) Annotate threads with allowed operations
[ https://issues.apache.org/jira/browse/IGNITE-21481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816590#comment-17816590 ] Roman Puchkovskiy commented on IGNITE-21481: Thanks > Annotate threads with allowed operations > > > Key: IGNITE-21481 > URL: https://issues.apache.org/jira/browse/IGNITE-21481 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Thread pools that > * can legally execute storage operations > * are forbidden to execute such operations > need to be annotated with allowed operations (that is, the threads in those > pools must implement ThreadAttributes). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21481) Annotate threads with allowed operations
[ https://issues.apache.org/jira/browse/IGNITE-21481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21481: - Fix Version/s: 3.0.0-beta2 > Annotate threads with allowed operations > > > Key: IGNITE-21481 > URL: https://issues.apache.org/jira/browse/IGNITE-21481 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Thread pools that > * can legally execute storage operations > * are forbidden to execute such operations > need to be annotated with allowed operations (that is, the threads in those > pools must implement ThreadAttributes). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21378) Investigate whether it's possible to make txnState local map updates faster
[ https://issues.apache.org/jira/browse/IGNITE-21378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816587#comment-17816587 ] Vladislav Pyatkov edited comment on IGNITE-21378 at 2/12/24 12:32 PM: -- The patch decreases the latency of the single-put operation by about 3.3% (40 microseconds). The full operation latency on my laptop is 1.2 milliseconds. was (Author: v.pyatkov): The patch decreases the latency of the single-put operation by about 3.3% (40 microseconds). > Investigate whether it's possible to make txnState local map updates faster > --- > > Key: IGNITE-21378 > URL: https://issues.apache.org/jira/browse/IGNITE-21378 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: PERFORMANCE, Performance, ignite-3, ignite3_performance, > performance, performence > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > IGNITE-21375 is about removing txnState local map updates within RO txn flow > because it brings us 20% performance drop. For RW transactions, it's however > not possible, because such updates are required by the RW protocol. Thus, it > seems reasonable to verify whether proposed VolatileTxStateMetaStorage is > itself fast enough. > h3. Definition of Done > * Increase VolatileTxStateMetaStorag performance if it's possible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21513) ActiveActorTest#testChangeLeaderForce is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-21513:
-
Assignee: Denis Chudov
> ActiveActorTest#testChangeLeaderForce is flaky
> --
>
> Key: IGNITE-21513
> URL: https://issues.apache.org/jira/browse/IGNITE-21513
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> [05:19:12]F:
> [org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
> 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.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370){code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20882) Append performance tests
[ https://issues.apache.org/jira/browse/IGNITE-20882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800470#comment-17800470 ] Andrey Novikov edited comment on IGNITE-20882 at 2/12/24 10:34 AM: --- Single-node embedded (CriteriaEmbeddedNodeBenchmark): ||Benchmark||Score(us/op)|| |criteriaGet|114,135 ± 1,129| |kvGet|72,062 ± 0,309| |sqlGet|105,260 ± 0,521| Two nodes, thin client(CriteriaThinClientBenchmark): ||Benchmark||Score(us/op)|| |criteriaGet|1780,171 ± 35,306| |kvGet|251,105 ± 8,618| |sqlGet|2694,740 ± 72,396| |criteriaGetNonNullTxDisablesPartitionAwareness|2935,503 ± 192,479| |kvGetNonNullTxDisablesPartitionAwareness|352,037 ± 7,819| |sqlGetNonNullTxDisablesPartitionAwareness|2814,066 ± 88,770| |sqlIterate|1603991,380 ± 12153,762| |criteriaIterate|1501173,640 ± 31600,562| was (Author: anovikov): Single-node embedded (CriteriaSingleNodeBenchmark): ||Benchmark||Score(us/op)|| |criteriaGet|1780,171 ± 35,306| |kvGet|121,114 ± 1,726| |sqlGet|1703,928 ± 34,945| Two nodes, thin client(CriteriaThinClientBenchmark): ||Benchmark||Score(us/op)|| |criteriaGet|1780,171 ± 35,306| |kvGet|251,105 ± 8,618| |sqlGet|2694,740 ± 72,396| |criteriaGetNonNullTxDisablesPartitionAwareness|2935,503 ± 192,479| |kvGetNonNullTxDisablesPartitionAwareness|352,037 ± 7,819| |sqlGetNonNullTxDisablesPartitionAwareness|2814,066 ± 88,770| |sqlIterate|1603991,380 ± 12153,762| |criteriaIterate|1501173,640 ± 31600,562| > Append performance tests > > > Key: IGNITE-20882 > URL: https://issues.apache.org/jira/browse/IGNITE-20882 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Novikov >Assignee: Andrey Novikov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > # Compare single-key criteria vs single-key SQL vs table.get(PK) > * Expect to have similar performance > * Check single-node embedded, distributed with no partition awareness, > distributed with partition awareness > * NOTE: future improvement for criteria query – lookup affinity node if PK > or colocation key is in the criteria. > # Compare criteria vs SQL when affinity key is specified (unicast when > partition pruning is added) > # Compare criteria vs SQL for broadcast queries – latency and throughput > # Compare criteria vs SQL – time it takes to iterate over 10kk entries -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19274) Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into account current tz while storing data.
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-19274:
-
Assignee: Pavel Pereslegin
> Sql. Jdbc side working with TIMESTAMP WITH LOCAL TIME ZONE did not take into
> account current tz while storing data.
> ---
>
> Key: IGNITE-19274
> URL: https://issues.apache.org/jira/browse/IGNITE-19274
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> The {{TIMESTAMP WITH LOCAL TIME ZONE}} data type is a variant of
> {{TIMESTAMP}} that includes a time zone offset in its value. Data stored in
> the database is normalized to the database time zone (UTC) and time zone
> offset is not stored as part of the column data. When the data is retrieved,
> it to be returned in the user's local session time zone.
> i.e:
> {noformat}
> CREATE TABLE timestamp(ts TIMESTAMP, t_tz TIMESTAMP WITH LOCAL TIME ZONE);
> SET TIME ZONE 'tz1';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL
> TIME ZONE '2011-01-01 01:01:01');
> SET TIME ZONE 'tz2';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL
> TIME ZONE '2011-01-01 01:01:01');
> ...
> select * from timestamp;{noformat}
> returned rows need to be different in case of different tz1 and tz2 offsets
> but they are equals for now. Also returned representation need to be present
> in user session time zone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21381) ActiveActorTest#testChangeLeaderForce has problems with resource cleanup
[
https://issues.apache.org/jira/browse/IGNITE-21381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816547#comment-17816547
]
Denis Chudov commented on IGNITE-21381:
---
As we have a PR already that is intended to fix resource leak (
https://github.com/apache/ignite-3/pull/3150 ), I created a new ticket to fix
the flaky test and make a refactoring IGNITE-21513
> ActiveActorTest#testChangeLeaderForce has problems with resource cleanup
>
>
> Key: IGNITE-21381
> URL: https://issues.apache.org/jira/browse/IGNITE-21381
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{ActiveActorTest#testChangeLeaderForce}} is started to be flaky on TC with
> {noformat}
> [05:19:12]F:
> [org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
> 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.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370)
> {noformat}
> From the log we can see that transfer leadership, which was supposed to be
> successful, do not happen. Behaviour is the following:
> 1) Current leader is {{Leader: ClusterNodeImpl
> [id=e99210fb-f872-4e08-a99c-53f9512da20e, name=aat_tclf_1235}}
> 2) We want to transfer leadership to {{Peer to transfer leader: Peer
> [consistentId=aat_tclf_1234, idx=0]}}
> 3) Process of transfer is started
> 4) We receive warn about error during {{GetLeaderRequestImpl}}:
> {noformat}
> [2024-01-29T05:19:08,855][WARN
> ][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable error
> during the request occurred (will be retried on the randomly selected node)
> [request=GetLeaderRequestImpl [groupId=TestReplicationGroup,
> peerId=aat_tclf_1235], peer=Peer [consistentId=aat_tclf_1235, idx=0],
> newPeer=Peer [consistentId=aat_tclf_1234, idx=0]].
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> [?:?]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
> [?:?]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.util.concurrent.TimeoutException
> ... 7 more
> {noformat}
> 5) After that we see that node {{aat_tclf_1236}} sends invalid
> {{RequestVoteResponse}} because it thinks that it is the leader:
> {noformat}
> [2024-01-29T05:19:11,370][WARN
> ][%aat_tclf_1234%JRaft-Response-Processor-15][NodeImpl] Node
> received invalid RequestVoteResponse
> from aat_tclf_1236, state not in STATE_CANDIDATE but STATE_LEADER.
> {noformat}
>
> Tests {{ActiveActorTest#testChangeLeaderForce}} and
> {{TopologyAwareRaftGroupServiceTest#testChangeLeaderForce}} were muted.
> Also there are some other problems with this tests, they incorrectly clean up
> resources in case of failure. Cluster is stopped in test itself, meaning that
> if some assertion is failed, the rest part of the test won't be evaluated,
> hence cluster won't be stopped.
> The next problem is that if we run this test a several times, even if
[jira] [Created] (IGNITE-21514) Deal with index destruction on compaction of catalog during a full state transfer
Kirill Tkalenko created IGNITE-21514: Summary: Deal with index destruction on compaction of catalog during a full state transfer Key: IGNITE-21514 URL: https://issues.apache.org/jira/browse/IGNITE-21514 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko This is the part of IGNITE-18595 in which we will need to deal with the destruction of indexes on catalog compaction during a full state transfer. The way I see it, we will simply need to get rid of read-only indexes for which some special exception will occur (for example, *StorageDestroyedException*) and no longer use such an index in a full state transfer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21513) ActiveActorTest#testChangeLeaderForce is flaky
Denis Chudov created IGNITE-21513:
-
Summary: ActiveActorTest#testChangeLeaderForce is flaky
Key: IGNITE-21513
URL: https://issues.apache.org/jira/browse/IGNITE-21513
Project: Ignite
Issue Type: Bug
Reporter: Denis Chudov
{code:java}
[05:19:12]F:
[org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
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.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21381) ActiveActorTest#testChangeLeaderForce has problems with resource cleanup
[
https://issues.apache.org/jira/browse/IGNITE-21381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21381:
--
Summary: ActiveActorTest#testChangeLeaderForce has problems with resource
cleanup (was: ActiveActorTest#testChangeLeaderForce is flaky )
> ActiveActorTest#testChangeLeaderForce has problems with resource cleanup
>
>
> Key: IGNITE-21381
> URL: https://issues.apache.org/jira/browse/IGNITE-21381
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{ActiveActorTest#testChangeLeaderForce}} is started to be flaky on TC with
> {noformat}
> [05:19:12]F:
> [org.apache.ignite.internal.placementdriver.ActiveActorTest.testChangeLeaderForce(TestInfo)]
> 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.placementdriver.ActiveActorTest.testChangeLeaderForce(ActiveActorTest.java:370)
> {noformat}
> From the log we can see that transfer leadership, which was supposed to be
> successful, do not happen. Behaviour is the following:
> 1) Current leader is {{Leader: ClusterNodeImpl
> [id=e99210fb-f872-4e08-a99c-53f9512da20e, name=aat_tclf_1235}}
> 2) We want to transfer leadership to {{Peer to transfer leader: Peer
> [consistentId=aat_tclf_1234, idx=0]}}
> 3) Process of transfer is started
> 4) We receive warn about error during {{GetLeaderRequestImpl}}:
> {noformat}
> [2024-01-29T05:19:08,855][WARN
> ][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable error
> during the request occurred (will be retried on the randomly selected node)
> [request=GetLeaderRequestImpl [groupId=TestReplicationGroup,
> peerId=aat_tclf_1235], peer=Peer [consistentId=aat_tclf_1235, idx=0],
> newPeer=Peer [consistentId=aat_tclf_1234, idx=0]].
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> [?:?]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
> [?:?]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.util.concurrent.TimeoutException
> ... 7 more
> {noformat}
> 5) After that we see that node {{aat_tclf_1236}} sends invalid
> {{RequestVoteResponse}} because it thinks that it is the leader:
> {noformat}
> [2024-01-29T05:19:11,370][WARN
> ][%aat_tclf_1234%JRaft-Response-Processor-15][NodeImpl] Node
> received invalid RequestVoteResponse
> from aat_tclf_1236, state not in STATE_CANDIDATE but STATE_LEADER.
> {noformat}
>
> Tests {{ActiveActorTest#testChangeLeaderForce}} and
> {{TopologyAwareRaftGroupServiceTest#testChangeLeaderForce}} were muted.
> Also there are some other problems with this tests, they incorrectly clean up
> resources in case of failure. Cluster is stopped in test itself, meaning that
> if some assertion is failed, the rest part of the test won't be evaluated,
> hence cluster won't be stopped.
> The next problem is that if we run this test a several times, even if they
> pass successfully, we can see that at some point new test cannot be run
> because
[jira] [Updated] (IGNITE-21181) Failure to resolve a primary replica after stopping a node
[
https://issues.apache.org/jira/browse/IGNITE-21181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-21181:
-
Reviewer: Alexander Lapin
> Failure to resolve a primary replica after stopping a node
> --
>
> Key: IGNITE-21181
> URL: https://issues.apache.org/jira/browse/IGNITE-21181
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> The scenario is that the cluster consists of 3 nodes (0, 1, 2). Primary
> replica of the sole partition is on node 0. Then node 0 is stopped and an
> attempt to do a put via node 2 is done. The partition still has majority, but
> the put results in the following:
>
> {code:java}
> org.apache.ignite.tx.TransactionException: IGN-REP-5
> TraceId:55c59c96-17d1-4efc-8e3c-cca81b8b41ad Failed to resolve the primary
> replica node [consistentId=itrst_ncisasiti_0]
>
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlist$69(InternalTableImpl.java:1749)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
> at
> java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlist(InternalTableImpl.java:1739)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlistWithRetry(InternalTableImpl.java:480)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.enlistInTx(InternalTableImpl.java:301)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.upsert(InternalTableImpl.java:965)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$putAsync$10(KeyValueViewImpl.java:196)
> at
> org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$1(AbstractTableView.java:111)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:111)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:102)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.putAsync(KeyValueViewImpl.java:193)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.put(KeyValueViewImpl.java:185)
> at
> org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.putToNode(ItTableRaftSnapshotsTest.java:257)
> at
> org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.putToNode(ItTableRaftSnapshotsTest.java:253)
> at
> org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.nodeCanInstallSnapshotsAfterSnapshotInstalledToIt(ItTableRaftSnapshotsTest.java:473){code}
>
> This can be reproduced using
> ItTableRaftSnapshotsTest#nodeCanInstallSnapshotsAfterSnapshotInstalledToIt().
> The reason is that, according to the test, the leader of partition group is
> transferred on node 0, which means that this node most probably will be
> selected as primary, and after that the node 0 is stopped, and then the
> transaction is started. Node 0 is still a leaseholder in the current time
> interval, but it's already left the topology.
> We can fix the test to make it await the new primary, which would be present
> in the cluster, or make the restries on the very first transactional request.
> In the case of latter, we need to ensure that the request is actually first
> and single, no other request in any parallel thread was sent, otherwise we
> cant retry the request on another primary .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
