[jira] [Updated] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
[ https://issues.apache.org/jira/browse/IGNITE-20372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20372: -- Fix Version/s: 3.0.0-beta2 > Sql. EXPLAIN PLAN ignores detail attributes. > > > Key: IGNITE-20372 > URL: https://issues.apache.org/jira/browse/IGNITE-20372 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of > a plan such as detail level, depth, and format. > Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL > ATTRIBUTES. > Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION > Format: AS XML, AS JSON, AS DOT. > All these properties of SqlExplain are ignored, when EXPLAIN PLAN FOR [stmt] > is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
[ https://issues.apache.org/jira/browse/IGNITE-20372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20372: -- Fix Version/s: (was: 3.0.0-beta2) > Sql. EXPLAIN PLAN ignores detail attributes. > > > Key: IGNITE-20372 > URL: https://issues.apache.org/jira/browse/IGNITE-20372 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of > a plan such as detail level, depth, and format. > Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL > ATTRIBUTES. > Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION > Format: AS XML, AS JSON, AS DOT. > All these properties of SqlExplain are ignored, when EXPLAIN PLAN FOR [stmt] > is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20371) Move handlers of index-related commands from CatalogManager
[ https://issues.apache.org/jira/browse/IGNITE-20371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-20371: - Assignee: Konstantin Orlov > Move handlers of index-related commands from CatalogManager > --- > > Key: IGNITE-20371 > URL: https://issues.apache.org/jira/browse/IGNITE-20371 > Project: Ignite > Issue Type: Improvement >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > As described in IGNITE-20284, we need to restructure code to improve code > locality and avoid conflict when introducing new commands in future. > Under this ticket let's address index-related commands. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
[ https://issues.apache.org/jira/browse/IGNITE-20372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20372: -- Fix Version/s: 3.0.0-beta2 > Sql. EXPLAIN PLAN ignores detail attributes. > > > Key: IGNITE-20372 > URL: https://issues.apache.org/jira/browse/IGNITE-20372 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of > a plan such as detail level, depth, and format. > Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL > ATTRIBUTES. > Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION > Format: AS XML, AS JSON, AS DOT. > All these properties of SqlExplain are ignored, when EXPLAIN PLAN FOR [stmt] > is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
[ https://issues.apache.org/jira/browse/IGNITE-20372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20372: -- Description: EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of a plan such as detail level, depth, and format. Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL ATTRIBUTES. Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION Format: AS XML, AS JSON, AS DOT. All these properties of SqlExplain are ignored, when EXPLAIN PLAN FOR [stmt] is executed. was: EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of a plan such as detail level, depth, and format. Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL ATTRIBUTES. Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION Format: AS XML, AS JSON, AS DOT. All these properties of SqlExplainNode are ignored, when EXPLAIN PLAN FOR [stmt] is executed. > Sql. EXPLAIN PLAN ignores detail attributes. > > > Key: IGNITE-20372 > URL: https://issues.apache.org/jira/browse/IGNITE-20372 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of > a plan such as detail level, depth, and format. > Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL > ATTRIBUTES. > Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION > Format: AS XML, AS JSON, AS DOT. > All these properties of SqlExplain are ignored, when EXPLAIN PLAN FOR [stmt] > is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
[ https://issues.apache.org/jira/browse/IGNITE-20372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20372: -- Labels: ignite-3 (was: ) > Sql. EXPLAIN PLAN ignores detail attributes. > > > Key: IGNITE-20372 > URL: https://issues.apache.org/jira/browse/IGNITE-20372 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of > a plan such as detail level, depth, and format. > Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL > ATTRIBUTES. > Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION > Format: AS XML, AS JSON, AS DOT. > All these properties of SqlExplainNode are ignored, when EXPLAIN PLAN FOR > [stmt] is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
Maksim Zhuravkov created IGNITE-20372: - Summary: Sql. EXPLAIN PLAN ignores detail attributes. Key: IGNITE-20372 URL: https://issues.apache.org/jira/browse/IGNITE-20372 Project: Ignite Issue Type: Bug Components: sql Reporter: Maksim Zhuravkov EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of a plan such as detail level, depth, and format. Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL ATTRIBUTES. Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION Format: AS XML, AS JSON, AS DOT. All these properties of SqlExplainNode are ignored, when EXPLAIN PLAN FOR [stmt] is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18670) Sql. It is possible to reference aliases in GROUP BY clause.
[
https://issues.apache.org/jira/browse/IGNITE-18670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-18670:
Labels: calcite2-required ignite-3 (was: calcite2-required
calcite3-required ignite-3)
> Sql. It is possible to reference aliases in GROUP BY clause.
>
>
> Key: IGNITE-18670
> URL: https://issues.apache.org/jira/browse/IGNITE-18670
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently we expect the query bellow to fail
> {code:java}
> SELECT 1 AS k, SUM(i) FROM integers GROUP BY k+1 ORDER BY 2;
> {code}
> But in https://issues.apache.org/jira/browse/IGNITE-18212 we decided that
> ignite's dialect of the SQL supports this behaviour.
> Update test_group_by.test and mark the query as OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20332) Fix ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpTriggeredByFilterUpdateIsRestoredAfterRestart
[ https://issues.apache.org/jira/browse/IGNITE-20332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-20332: --- Reviewer: Mirza Aliev > Fix > ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpTriggeredByFilterUpdateIsRestoredAfterRestart > --- > > Key: IGNITE-20332 > URL: https://issues.apache.org/jira/browse/IGNITE-20332 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > *org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpTriggeredByFilterUpdateIsRestoredAfterRestart* > started to fall in the > [catalog-feature|https://github.com/apache/ignite-3/tree/catalog-feature] > branch, and on other branches that are created from it branch, need to fix it. > https://ci.ignite.apache.org/viewLog.html?buildId=7470189&buildTypeId=ApacheIgnite3xGradle_Test_RunAllTests&fromSakuraUI=true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20239) Sql. Remove row type transformations from SetOpConverterRule.
[ https://issues.apache.org/jira/browse/IGNITE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762417#comment-17762417 ] Maksim Zhuravkov commented on IGNITE-20239: --- [~korlov], [~xtern]. Could you please review this PR? > Sql. Remove row type transformations from SetOpConverterRule. > -- > > Key: IGNITE-20239 > URL: https://issues.apache.org/jira/browse/IGNITE-20239 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > `SetOpConverterRule` creates a rowType produced by set operation by means of > `TypeFactory::leastRestrictive`. This should not be necessary because types > of rows returned by inputs to set operation should be coerced at the > validation stage by `SqlValidator`/ SetopOperandTypeChecker`. > Remove calls to `TypeFactory::leastRestrictive` from `SetOpConverterRule` for > both colocated and map/reduce versions of operators and use `rowType` > returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20344) Create tests for rebalance recovery
[ https://issues.apache.org/jira/browse/IGNITE-20344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-20344: Assignee: Aleksandr Polovtcev > Create tests for rebalance recovery > --- > > Key: IGNITE-20344 > URL: https://issues.apache.org/jira/browse/IGNITE-20344 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > When implementing IGNITE-20187, I've encountered multiple problems with > writing an integration test for it. Since it required multiple node restarts, > it interfered with the rebalance algorithm a lot and the test was hanging for > various reasons. This must be investigated and fixed/overcome and a proper > test must be implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20233) jdbc: Propagate observable timestamp to sql-engine.
[ https://issues.apache.org/jira/browse/IGNITE-20233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20233: --- Description: We need to pass the observable timestamp from jdbc client to the sql engine. This must be done after the completion of IGNITE-19898. Investigate possibility of migrating from JDBC_* client messages to SQL_* was: We need to pass the observable timestamp from jdbc client to the sql engine. This must be done after the completion of IGNITE-19898. Investigate possibility of migrating from JDBC_* client messages to SQL_*. > jdbc: Propagate observable timestamp to sql-engine. > --- > > Key: IGNITE-20233 > URL: https://issues.apache.org/jira/browse/IGNITE-20233 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > We need to pass the observable timestamp from jdbc client to the sql engine. > This must be done after the completion of IGNITE-19898. > Investigate possibility of migrating from JDBC_* client messages to SQL_* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20369) Breakdown tasks for initial implementation of FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-20369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20369: - Description: . > Breakdown tasks for initial implementation of FailureHandler > > > Key: IGNITE-20369 > URL: https://issues.apache.org/jira/browse/IGNITE-20369 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20306) .NET: Thin 3.0: TestAutoFlushFrequency is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762407#comment-17762407
]
Pavel Tupitsyn commented on IGNITE-20306:
-
Merged to main: 40bb4f70f6bddf422d49407584c3ef5e38f4742d
> .NET: Thin 3.0: TestAutoFlushFrequency is flaky
> ---
>
> Key: IGNITE-20306
> URL: https://issues.apache.org/jira/browse/IGNITE-20306
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Both variants are flaky (true/false parameter):
> *
> https://ci.ignite.apache.org/test/4035794459336688174?currentProjectId=ApacheIgnite3xGradle_Test&expandTestHistoryChartSection=true
> *
> https://ci.ignite.apache.org/test/-2348764802366634257?currentProjectId=ApacheIgnite3xGradle_Test&expandTestHistoryChartSection=true
> {code}
> Condition not reached after 00:00:01.0081298
>at Apache.Ignite.Tests.TestUtils.WaitForConditionAsync(Func`1 condition,
> Int32 timeoutMs, Func`1 messageFactory) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/TestUtils.cs:line
> 68
>at
> Apache.Ignite.Tests.Table.DataStreamerTests.TestAutoFlushFrequency(Boolean
> enabled) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Table/DataStreamerTests.cs:line
> 108
>at
> Apache.Ignite.Tests.Table.DataStreamerTests.TestAutoFlushFrequency(Boolean
> enabled) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Table/DataStreamerTests.cs:line
> 108
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19967) Design restart of Distribution Zone Manager in accordance with the new local recovery process
[ https://issues.apache.org/jira/browse/IGNITE-19967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-19967: - Description: In https://issues.apache.org/jira/browse/IGNITE-19061 we have provided and later implemented algorithm for restoring zones states after restart. In https://issues.apache.org/jira/browse/IGNITE-19778 and other tickets new invariants for recovery were introduced, in particular, in the new proposal node state is recovered not until applied revision, but until some higher revision, which brings inconsistency for restoring Distribution Zone Manager because the process was based on saving states to the Vault and on mechanism with restoring from the Vault. Previously we could based our recovery on the fact, that all events, that node missed during absence, will be applied to starting from metastorage applied revision, but in the new recovery process, node receives only snapshot of the data and we cannot restore the history of data nodes related events. In this task we need to provide a new approach, taking into account new circumstances. was: In https://issues.apache.org/jira/browse/IGNITE-19061 we have provided and later implemented algorithm for restoring zones states after restart. In https://issues.apache.org/jira/browse/IGNITE-19778 and other tickets new invariants for recovery were introduced, in particular, in the new proposal node state is recovered not until applied revision, but until some higher revision, which brings inconsistency for restoring Distribution Zone Manager because the process was based on saving states to the Vault and on previous mechanism with restoring from the Vault In this task we need to provide a new approach, taking into account new circumstances. > Design restart of Distribution Zone Manager in accordance with the new local > recovery process > - > > Key: IGNITE-19967 > URL: https://issues.apache.org/jira/browse/IGNITE-19967 > Project: Ignite > Issue Type: Task >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In https://issues.apache.org/jira/browse/IGNITE-19061 we have provided and > later implemented algorithm for restoring zones states after restart. > In https://issues.apache.org/jira/browse/IGNITE-19778 and other tickets new > invariants for recovery were introduced, in particular, in the new proposal > node state is recovered not until applied revision, but until some higher > revision, which brings inconsistency for restoring Distribution Zone Manager > because the process was based on saving states to the Vault and on mechanism > with restoring from the Vault. Previously we could based our recovery on the > fact, that all events, that node missed during absence, will be applied to > starting from metastorage applied revision, but in the new recovery process, > node receives only snapshot of the data and we cannot restore the history of > data nodes related events. > In this task we need to provide a new approach, taking into account new > circumstances. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20369) Breakdown tasks for initial implementation of FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-20369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20369: - Fix Version/s: 3.0.0-beta2 > Breakdown tasks for initial implementation of FailureHandler > > > Key: IGNITE-20369 > URL: https://issues.apache.org/jira/browse/IGNITE-20369 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20358) Make distributed node storage config local
[
https://issues.apache.org/jira/browse/IGNITE-20358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20358:
-
Labels: ignite-3 (was: )
> Make distributed node storage config local
> --
>
> Key: IGNITE-20358
> URL: https://issues.apache.org/jira/browse/IGNITE-20358
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Assignee: Kirill Gusakov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> At the moment, all {{*StorageEngineConfigurationSchema}} has the
> {{ConfigurationType.DISTRIBUTED}} type. But it is not the case anymore, each
> node can have the different storage configurations by new design.
> *Definition of done*
> - All {{*StorageEngineConfigurationSchema}} configurations moved to the
> {{ConfigurationType.LOCAL}} scope.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20357) Design node config, zone and table storage relations
[ https://issues.apache.org/jira/browse/IGNITE-20357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20357: - Labels: ignite-3 (was: ) > Design node config, zone and table storage relations > > > Key: IGNITE-20357 > URL: https://issues.apache.org/jira/browse/IGNITE-20357 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > We need to clarify the UX around the table storage, zone and node configs > according to zone-based collocation. > *Definition of done* > User has the simple and predictable flow to: > - Configure the node storage from the point of view: tables with which > requirements for storage can use this node. > - Describe on the zone creation, the nodes with which table storages can be a > part of this zone > - Describe on the table creation, which storage needed for this table and > receive the error as soon as possible if chosen zone can't guarantee that its > nodes have this storage -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20366) ItTxDistributedTestThreeNodesThreeReplicas(Collocated)#testBatchReadPutConcurrently is broken
[
https://issues.apache.org/jira/browse/IGNITE-20366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20366:
-
Description:
{code:java}
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.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:474)
{code}
Need to find a root cause of the issue.
was:
{code:java}
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.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:474)
{code}
> ItTxDistributedTestThreeNodesThreeReplicas(Collocated)#testBatchReadPutConcurrently
> is broken
> -
>
> Key: IGNITE-20366
> URL: https://issues.apache.org/jira/browse/IGNITE-20366
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
>
> {code:java}
> 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.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:474)
>
> {code}
> Need to find a root cause of the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20357) Design node config, zone and table storage relations
[ https://issues.apache.org/jira/browse/IGNITE-20357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20357: - Ignite Flags: (was: Docs Required,Release Notes Required) > Design node config, zone and table storage relations > > > Key: IGNITE-20357 > URL: https://issues.apache.org/jira/browse/IGNITE-20357 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > > *Motivation* > We need to clarify the UX around the table storage, zone and node configs > according to zone-based collocation. > *Definition of done* > User has the simple and predictable flow to: > - Configure the node storage from the point of view: tables with which > requirements for storage can use this node. > - Describe on the zone creation, the nodes with which table storages can be a > part of this zone > - Describe on the table creation, which storage needed for this table and > receive the error as soon as possible if chosen zone can't guarantee that its > nodes have this storage -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20358) Make distributed node storage config local
[
https://issues.apache.org/jira/browse/IGNITE-20358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20358:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Make distributed node storage config local
> --
>
> Key: IGNITE-20358
> URL: https://issues.apache.org/jira/browse/IGNITE-20358
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Assignee: Kirill Gusakov
>Priority: Major
>
> *Motivation*
> At the moment, all {{*StorageEngineConfigurationSchema}} has the
> {{ConfigurationType.DISTRIBUTED}} type. But it is not the case anymore, each
> node can have the different storage configurations by new design.
> *Definition of done*
> - All {{*StorageEngineConfigurationSchema}} configurations moved to the
> {{ConfigurationType.LOCAL}} scope.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20355) TxLocalTest RO tests hangs infinitely
[
https://issues.apache.org/jira/browse/IGNITE-20355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20355:
-
Description:
{code:java}
testReadOnlyGet
testReadOnlyScan
testReadOnlyGetWriteIntentResolutionUpdate
testReadOnlyGetWriteIntentResolutionRemove
testReadOnlyGetAll
testReadOnlyPendingWriteIntentSkippedCombined
{code}
These tests hang infinitely.
was:
{code:java}
testReadOnlyGet
testReadOnlyScan
testReadOnlyGetWriteIntentResolutionUpdate
testReadOnlyGetWriteIntentResolutionRemove
testReadOnlyGetAll
testReadOnlyPendingWriteIntentSkippedCombined
{code}
hangs infinitely.
> TxLocalTest RO tests hangs infinitely
> --
>
> Key: IGNITE-20355
> URL: https://issues.apache.org/jira/browse/IGNITE-20355
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
>
> {code:java}
> testReadOnlyGet
> testReadOnlyScan
> testReadOnlyGetWriteIntentResolutionUpdate
> testReadOnlyGetWriteIntentResolutionRemove
> testReadOnlyGetAll
> testReadOnlyPendingWriteIntentSkippedCombined
> {code}
> These tests hang infinitely.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18856) Switch primary replica calls from Raft leader to primary replica
[ https://issues.apache.org/jira/browse/IGNITE-18856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-18856: - Reviewer: Denis Chudov > Switch primary replica calls from Raft leader to primary replica > > > Key: IGNITE-18856 > URL: https://issues.apache.org/jira/browse/IGNITE-18856 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Assignee: Alexander Lapin >Priority: Major > Labels: iep-101, ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > *Motivation* > As for now, RW requests to primary replica (see calls of > `ReplicaService#invoke` ) are sent to raft leader, for which the refresh > leader operation is needed. In presence of placement driver which is > responsible for assigning primary replicas, this is not needed, the request > can be sent directly to primary replica node. > Th information about primary replicas assigned by placement driver should be > available on every node after IGNITE-18859 . This task is about switching > primary replica calls and eliminating excessive code related to refreshing > leader of raft group. > *Definition of done* > Requests to primary replica are made to those nodes that are assigned by > placement driver, and no related Raft calls are made. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20356) Sql. Replace the RowHandler "set" operation with "append".
[
https://issues.apache.org/jira/browse/IGNITE-20356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-20356:
--
Description:
In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}" method
Instead of using {{set(int, RowT, Object)}} method, we can use the
{{append(RowT, Object)}} method to add field values sequentially.
To add this method we need:
* Implement an efficient addition of field values to BinaryTuple if it is not
implemented yet.
* Remove the {{RowHandler#set()}} method and rework all related code/tests to
use the {{RowHandler#append()}} method.
was:
In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}" method
Instead of using {{set(int, RowT, Object)}} method, we can use the
{{append(RowT, Object)}} method to add fields sequentially.
To add this method we need:
* Implement an efficient addition of field values to BinaryTuple if it is not
implemented yet.
* Remove the {{RowHandler#set()}} method and rework all related code/tests to
use the {{RowHandler#append()}} method.
> Sql. Replace the RowHandler "set" operation with "append".
> --
>
> Key: IGNITE-20356
> URL: https://issues.apache.org/jira/browse/IGNITE-20356
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
> This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}"
> method
> Instead of using {{set(int, RowT, Object)}} method, we can use the
> {{append(RowT, Object)}} method to add field values sequentially.
> To add this method we need:
> * Implement an efficient addition of field values to BinaryTuple if it is
> not implemented yet.
> * Remove the {{RowHandler#set()}} method and rework all related code/tests
> to use the {{RowHandler#append()}} method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20370) Sql. Unexpected error while create different indexes on common columns
[
https://issues.apache.org/jira/browse/IGNITE-20370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky resolved IGNITE-20370.
-
Resolution: Invalid
> Sql. Unexpected error while create different indexes on common columns
> --
>
> Key: IGNITE-20370
> URL: https://issues.apache.org/jira/browse/IGNITE-20370
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> I just change a bit test: ItSqlAsynchronousApiTest#ddl
> and it still passed.
> {code:java}
> checkDdl(true, ses, "CREATE INDEX TEST_IDX1 ON TEST using
> tree(VAL0)");
> checkDdl(true, ses, "CREATE INDEX TEST_IDX2 ON TEST using
> hash(VAL0)");
> checkDdl(true, ses, "CREATE INDEX TEST_IDX3 ON TEST(ID, VAL0, VAL1)");
> checkSqlError(
> Index.INVALID_INDEX_DEFINITION_ERR,
> "Can't create index on duplicate columns: VAL0, VAL0",
> ses,
> "CREATE INDEX TEST_IDX4 ON TEST(VAL0, VAL0)"
> );
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20306) .NET: Thin 3.0: TestAutoFlushFrequency is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762396#comment-17762396
]
Igor Sapego commented on IGNITE-20306:
--
Looks good to me
> .NET: Thin 3.0: TestAutoFlushFrequency is flaky
> ---
>
> Key: IGNITE-20306
> URL: https://issues.apache.org/jira/browse/IGNITE-20306
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Both variants are flaky (true/false parameter):
> *
> https://ci.ignite.apache.org/test/4035794459336688174?currentProjectId=ApacheIgnite3xGradle_Test&expandTestHistoryChartSection=true
> *
> https://ci.ignite.apache.org/test/-2348764802366634257?currentProjectId=ApacheIgnite3xGradle_Test&expandTestHistoryChartSection=true
> {code}
> Condition not reached after 00:00:01.0081298
>at Apache.Ignite.Tests.TestUtils.WaitForConditionAsync(Func`1 condition,
> Int32 timeoutMs, Func`1 messageFactory) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/TestUtils.cs:line
> 68
>at
> Apache.Ignite.Tests.Table.DataStreamerTests.TestAutoFlushFrequency(Boolean
> enabled) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Table/DataStreamerTests.cs:line
> 108
>at
> Apache.Ignite.Tests.Table.DataStreamerTests.TestAutoFlushFrequency(Boolean
> enabled) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Table/DataStreamerTests.cs:line
> 108
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20371) Move handlers of index-related commands from CatalogManager
[ https://issues.apache.org/jira/browse/IGNITE-20371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-20371: -- Summary: Move handlers of index-related commands from CatalogManager (was: IGNITE-20340 Move handlers of index-related commands from CatalogManager) > Move handlers of index-related commands from CatalogManager > --- > > Key: IGNITE-20371 > URL: https://issues.apache.org/jira/browse/IGNITE-20371 > Project: Ignite > Issue Type: Improvement >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > As described in IGNITE-20284, we need to restructure code to improve code > locality and avoid conflict when introducing new commands in future. > Under this ticket let's address index-related commands. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20371) IGNITE-20340 Move handlers of index-related commands from CatalogManager
[ https://issues.apache.org/jira/browse/IGNITE-20371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-20371: -- Fix Version/s: 3.0.0-beta2 > IGNITE-20340 Move handlers of index-related commands from CatalogManager > > > Key: IGNITE-20371 > URL: https://issues.apache.org/jira/browse/IGNITE-20371 > Project: Ignite > Issue Type: Improvement >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > As described in IGNITE-20284, we need to restructure code to improve code > locality and avoid conflict when introducing new commands in future. > Under this ticket let's address index-related commands. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20371) IGNITE-20340 Move handlers of index-related commands from CatalogManager
[ https://issues.apache.org/jira/browse/IGNITE-20371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-20371: -- Ignite Flags: (was: Docs Required,Release Notes Required) > IGNITE-20340 Move handlers of index-related commands from CatalogManager > > > Key: IGNITE-20371 > URL: https://issues.apache.org/jira/browse/IGNITE-20371 > Project: Ignite > Issue Type: Improvement >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > As described in IGNITE-20284, we need to restructure code to improve code > locality and avoid conflict when introducing new commands in future. > Under this ticket let's address index-related commands. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20371) IGNITE-20340 Move handlers of index-related commands from CatalogManager
Konstantin Orlov created IGNITE-20371: - Summary: IGNITE-20340 Move handlers of index-related commands from CatalogManager Key: IGNITE-20371 URL: https://issues.apache.org/jira/browse/IGNITE-20371 Project: Ignite Issue Type: Improvement Reporter: Konstantin Orlov As described in IGNITE-20284, we need to restructure code to improve code locality and avoid conflict when introducing new commands in future. Under this ticket let's address index-related commands. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20370) Sql. Unexpected error while create different indexes on common columns
[
https://issues.apache.org/jira/browse/IGNITE-20370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-20370:
Description:
I just change a bit test: ItSqlAsynchronousApiTest#ddl
and it still passed.
{code:java}
checkDdl(true, ses, "CREATE INDEX TEST_IDX1 ON TEST using tree(VAL0)");
checkDdl(true, ses, "CREATE INDEX TEST_IDX2 ON TEST using hash(VAL0)");
checkDdl(true, ses, "CREATE INDEX TEST_IDX3 ON TEST(ID, VAL0, VAL1)");
checkSqlError(
Index.INVALID_INDEX_DEFINITION_ERR,
"Can't create index on duplicate columns: VAL0, VAL0",
ses,
"CREATE INDEX TEST_IDX4 ON TEST(VAL0, VAL0)"
);
{code}
was:
I just change a bit test: ItSqlAsynchronousApiTest#ddl
and it still passed, also need to be discussed equal columns with different
inline_size, i don`t know the case for such case, but probably it exist.
{code:java}
checkDdl(true, ses, "CREATE INDEX TEST_IDX1 ON TEST using tree(VAL0)");
checkDdl(true, ses, "CREATE INDEX TEST_IDX2 ON TEST using hash(VAL0)");
checkDdl(true, ses, "CREATE INDEX TEST_IDX3 ON TEST(ID, VAL0, VAL1)");
checkSqlError(
Index.INVALID_INDEX_DEFINITION_ERR,
"Can't create index on duplicate columns: VAL0, VAL0",
ses,
"CREATE INDEX TEST_IDX4 ON TEST(VAL0, VAL0)"
);
{code}
> Sql. Unexpected error while create different indexes on common columns
> --
>
> Key: IGNITE-20370
> URL: https://issues.apache.org/jira/browse/IGNITE-20370
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> I just change a bit test: ItSqlAsynchronousApiTest#ddl
> and it still passed.
> {code:java}
> checkDdl(true, ses, "CREATE INDEX TEST_IDX1 ON TEST using
> tree(VAL0)");
> checkDdl(true, ses, "CREATE INDEX TEST_IDX2 ON TEST using
> hash(VAL0)");
> checkDdl(true, ses, "CREATE INDEX TEST_IDX3 ON TEST(ID, VAL0, VAL1)");
> checkSqlError(
> Index.INVALID_INDEX_DEFINITION_ERR,
> "Can't create index on duplicate columns: VAL0, VAL0",
> ses,
> "CREATE INDEX TEST_IDX4 ON TEST(VAL0, VAL0)"
> );
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20273) Breakdown for zone-based collocation
[ https://issues.apache.org/jira/browse/IGNITE-20273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov resolved IGNITE-20273. - Resolution: Fixed Breakdown prepared under the issue epic > Breakdown for zone-based collocation > > > Key: IGNITE-20273 > URL: https://issues.apache.org/jira/browse/IGNITE-20273 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > Based on the current design goals we need to prepare the tickets' breakdown > for the first phase of collocation > [design|https://github.com/gridgain/apache-ignite-3/blob/1abb67c8770179d5d3e295876b73893f3845a08e/modules/distribution-zones/tech-notes/zone-collocation.md#L1]: > Under the first phase we want to implement the following steps: > - Store the table partitions data inside the one zone partition > - Change the RAFT servers and clients management to support the separate > start of zone partitions and start of table state machine listeners > - Refactor the structure of our storage layer to support the many tables > inside the one logical partition > - Implement the way to configure available storages in node configs -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20370) Sql. Unexpected error while create different indexes on common columns
Evgeny Stanilovsky created IGNITE-20370:
---
Summary: Sql. Unexpected error while create different indexes on
common columns
Key: IGNITE-20370
URL: https://issues.apache.org/jira/browse/IGNITE-20370
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
I just change a bit test: ItSqlAsynchronousApiTest#ddl
and it still passed, also need to be discussed equal columns with different
inline_size, i don`t know the case for such case, but probably it exist.
{code:java}
checkDdl(true, ses, "CREATE INDEX TEST_IDX1 ON TEST using tree(VAL0)");
checkDdl(true, ses, "CREATE INDEX TEST_IDX2 ON TEST using hash(VAL0)");
checkDdl(true, ses, "CREATE INDEX TEST_IDX3 ON TEST(ID, VAL0, VAL1)");
checkSqlError(
Index.INVALID_INDEX_DEFINITION_ERR,
"Can't create index on duplicate columns: VAL0, VAL0",
ses,
"CREATE INDEX TEST_IDX4 ON TEST(VAL0, VAL0)"
);
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20358) Make distributed node storage config local
[
https://issues.apache.org/jira/browse/IGNITE-20358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-20358:
Assignee: Kirill Gusakov
> Make distributed node storage config local
> --
>
> Key: IGNITE-20358
> URL: https://issues.apache.org/jira/browse/IGNITE-20358
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Assignee: Kirill Gusakov
>Priority: Major
>
> *Motivation*
> At the moment, all {{*StorageEngineConfigurationSchema}} has the
> {{ConfigurationType.DISTRIBUTED}} type. But it is not the case anymore, each
> node can have the different storage configurations by new design.
> *Definition of done*
> - All {{*StorageEngineConfigurationSchema}} configurations moved to the
> {{ConfigurationType.LOCAL}} scope.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20357) Design node config, zone and table storage relations
[ https://issues.apache.org/jira/browse/IGNITE-20357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-20357: Assignee: Kirill Gusakov > Design node config, zone and table storage relations > > > Key: IGNITE-20357 > URL: https://issues.apache.org/jira/browse/IGNITE-20357 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > > *Motivation* > We need to clarify the UX around the table storage, zone and node configs > according to zone-based collocation. > *Definition of done* > User has the simple and predictable flow to: > - Configure the node storage from the point of view: tables with which > requirements for storage can use this node. > - Describe on the zone creation, the nodes with which table storages can be a > part of this zone > - Describe on the table creation, which storage needed for this table and > receive the error as soon as possible if chosen zone can't guarantee that its > nodes have this storage -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20366) ItTxDistributedTestThreeNodesThreeReplicas(Collocated)#testBatchReadPutConcurrently is broken
[
https://issues.apache.org/jira/browse/IGNITE-20366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-20366:
Assignee: Alexander Lapin
> ItTxDistributedTestThreeNodesThreeReplicas(Collocated)#testBatchReadPutConcurrently
> is broken
> -
>
> Key: IGNITE-20366
> URL: https://issues.apache.org/jira/browse/IGNITE-20366
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
>
> {code:java}
> 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.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:474)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20355) TxLocalTest RO tests hangs infinitely
[
https://issues.apache.org/jira/browse/IGNITE-20355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-20355:
Assignee: Alexander Lapin
> TxLocalTest RO tests hangs infinitely
> --
>
> Key: IGNITE-20355
> URL: https://issues.apache.org/jira/browse/IGNITE-20355
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
>
> {code:java}
> testReadOnlyGet
> testReadOnlyScan
> testReadOnlyGetWriteIntentResolutionUpdate
> testReadOnlyGetWriteIntentResolutionRemove
> testReadOnlyGetAll
> testReadOnlyPendingWriteIntentSkippedCombined
> {code}
> hangs infinitely.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16899) Implement node failure process
[ https://issues.apache.org/jira/browse/IGNITE-16899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16899: - Epic Link: IGNITE-20368 > Implement node failure process > -- > > Key: IGNITE-16899 > URL: https://issues.apache.org/jira/browse/IGNITE-16899 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > Similar to 2.0, we need to implement a node failure process, that describe in > [IEP-14|https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20369) Breakdown tasks for initial implementation of FailureHandler
Vyacheslav Koptilin created IGNITE-20369: Summary: Breakdown tasks for initial implementation of FailureHandler Key: IGNITE-20369 URL: https://issues.apache.org/jira/browse/IGNITE-20369 Project: Ignite Issue Type: Task Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20368) Critical failures handling API (Ignite 3)
[ https://issues.apache.org/jira/browse/IGNITE-20368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20368: - Labels: ignite-3 (was: ) > Critical failures handling API (Ignite 3) > - > > Key: IGNITE-20368 > URL: https://issues.apache.org/jira/browse/IGNITE-20368 > Project: Ignite > Issue Type: Epic >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20368) Critical failures handling API (Ignite 3)
Vyacheslav Koptilin created IGNITE-20368: Summary: Critical failures handling API (Ignite 3) Key: IGNITE-20368 URL: https://issues.apache.org/jira/browse/IGNITE-20368 Project: Ignite Issue Type: Epic Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20367) ItTableRaftSnapshotsTest#snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst timedout
Alexander Lapin created IGNITE-20367:
Summary:
ItTableRaftSnapshotsTest#snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst
timedout
Key: IGNITE-20367
URL: https://issues.apache.org/jira/browse/IGNITE-20367
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
{code:java}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:f1535407-3cf9-48cd-9091-825ecf308526 at
java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
at
app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772)
at
app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706)
at
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543)
at
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641)
at
app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494)
at
app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
at
app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:38)
at
app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:50)
at
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$1(ItTableRaftSnapshotsTest.java:231)
at app//org.apache.ignite.internal.Cluster.doInSession(Cluster.java:448) at
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$2(ItTableRaftSnapshotsTest.java:230)
at
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.withRetry(ItTableRaftSnapshotsTest.java:184)
at
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.executeDmlWithRetry(ItTableRaftSnapshotsTest.java:229)
at
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.prepareClusterForInstallingSnapshotToNode2(ItTableRaftSnapshotsTest.java:351)
at
app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst(ItTableRaftSnapshotsTest.java:685)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) at
app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at
app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at
app//org.junit.jupiter.engine
[jira] [Updated] (IGNITE-20355) TxLocalTest RO tests hangs infinitely
[
https://issues.apache.org/jira/browse/IGNITE-20355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20355:
-
Priority: Blocker (was: Major)
> TxLocalTest RO tests hangs infinitely
> --
>
> Key: IGNITE-20355
> URL: https://issues.apache.org/jira/browse/IGNITE-20355
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Blocker
> Labels: ignite-3
>
> {code:java}
> testReadOnlyGet
> testReadOnlyScan
> testReadOnlyGetWriteIntentResolutionUpdate
> testReadOnlyGetWriteIntentResolutionRemove
> testReadOnlyGetAll
> testReadOnlyPendingWriteIntentSkippedCombined
> {code}
> hangs infinitely.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20366) ItTxDistributedTestThreeNodesThreeReplicas(Collocated)#testBatchReadPutConcurrently is broken
Alexander Lapin created IGNITE-20366:
Summary:
ItTxDistributedTestThreeNodesThreeReplicas(Collocated)#testBatchReadPutConcurrently
is broken
Key: IGNITE-20366
URL: https://issues.apache.org/jira/browse/IGNITE-20366
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
{code:java}
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.table.TxAbstractTest.testBatchReadPutConcurrently(TxAbstractTest.java:474)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20355) TxLocalTest RO tests hangs infinitely
[
https://issues.apache.org/jira/browse/IGNITE-20355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20355:
-
Description:
{code:java}
testReadOnlyGet
testReadOnlyScan
testReadOnlyGetWriteIntentResolutionUpdate
testReadOnlyGetWriteIntentResolutionRemove
testReadOnlyGetAll
testReadOnlyPendingWriteIntentSkippedCombined
{code}
hangs infinitely.
was:
{code:java}
testReadOnlyGet
testReadOnlyScan
testReadOnlyGetWriteIntentResolutionUpdate
testReadOnlyGetWriteIntentResolutionRemove
testReadOnlyGetAll
testReadOnlyPendingWriteIntentSkippedCombined
{code}
hangs infinitely.
> TxLocalTest RO tests hangs infinitely
> --
>
> Key: IGNITE-20355
> URL: https://issues.apache.org/jira/browse/IGNITE-20355
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> testReadOnlyGet
> testReadOnlyScan
> testReadOnlyGetWriteIntentResolutionUpdate
> testReadOnlyGetWriteIntentResolutionRemove
> testReadOnlyGetAll
> testReadOnlyPendingWriteIntentSkippedCombined
> {code}
> hangs infinitely.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20365) Add ability to intentially change primary replica
[ https://issues.apache.org/jira/browse/IGNITE-20365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20365: - Summary: Add ability to intentially change primary replica (was: Add ability to intentially change primaryReplica) > Add ability to intentially change primary replica > - > > Key: IGNITE-20365 > URL: https://issues.apache.org/jira/browse/IGNITE-20365 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > Some tests, e.g. testTxStateReplicaRequestMissLeaderMiss expects primary > replica to be changed. Earlier when primary replica was collocated with > leader refreshAndGetLeaderWithTerm was used in order to change leader and > thus primary replica. Now when Placement driver assigns primary replica it's > no longer the case. All in all, some PlacementDriver#changePrimaryReplica or > similar will be useful, at least within tests. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20365) Add ability to intentionally change primary replica
[ https://issues.apache.org/jira/browse/IGNITE-20365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20365: - Summary: Add ability to intentionally change primary replica (was: Add ability to intentially change primary replica) > Add ability to intentionally change primary replica > --- > > Key: IGNITE-20365 > URL: https://issues.apache.org/jira/browse/IGNITE-20365 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > Some tests, e.g. testTxStateReplicaRequestMissLeaderMiss expects primary > replica to be changed. Earlier when primary replica was collocated with > leader refreshAndGetLeaderWithTerm was used in order to change leader and > thus primary replica. Now when Placement driver assigns primary replica it's > no longer the case. All in all, some PlacementDriver#changePrimaryReplica or > similar will be useful, at least within tests. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20365) Add ability to intentially change primaryReplica
[ https://issues.apache.org/jira/browse/IGNITE-20365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20365: - Ignite Flags: (was: Docs Required,Release Notes Required) > Add ability to intentially change primaryReplica > > > Key: IGNITE-20365 > URL: https://issues.apache.org/jira/browse/IGNITE-20365 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > Some tests, e.g. testTxStateReplicaRequestMissLeaderMiss expects primary > replica to be changed. Earlier when primary replica was collocated with > leader refreshAndGetLeaderWithTerm was used in order to change leader and > thus primary replica. Now when Placement driver assigns primary replica it's > no longer the case. All in all, some PlacementDriver#changePrimaryReplica or > similar will be useful, at least within tests. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20365) Add ability to intentially change primaryReplica
[ https://issues.apache.org/jira/browse/IGNITE-20365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20365: - Labels: ignite-3 (was: ) > Add ability to intentially change primaryReplica > > > Key: IGNITE-20365 > URL: https://issues.apache.org/jira/browse/IGNITE-20365 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > Some tests, e.g. testTxStateReplicaRequestMissLeaderMiss expects primary > replica to be changed. Earlier when primary replica was collocated with > leader refreshAndGetLeaderWithTerm was used in order to change leader and > thus primary replica. Now when Placement driver assigns primary replica it's > no longer the case. All in all, some PlacementDriver#changePrimaryReplica or > similar will be useful, at least within tests. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20365) Add ability to intentially change primaryReplica
[ https://issues.apache.org/jira/browse/IGNITE-20365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20365: - Description: Some tests, e.g. testTxStateReplicaRequestMissLeaderMiss expects primary replica to be changed. Earlier when primary replica was collocated with leader refreshAndGetLeaderWithTerm was used in order to change leader and thus primary replica. Now when Placement driver assigns primary replica it's no longer the case. All in all, some PlacementDriver#changePrimaryReplica or similar will be useful, at least within tests. > Add ability to intentially change primaryReplica > > > Key: IGNITE-20365 > URL: https://issues.apache.org/jira/browse/IGNITE-20365 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > > Some tests, e.g. testTxStateReplicaRequestMissLeaderMiss expects primary > replica to be changed. Earlier when primary replica was collocated with > leader refreshAndGetLeaderWithTerm was used in order to change leader and > thus primary replica. Now when Placement driver assigns primary replica it's > no longer the case. All in all, some PlacementDriver#changePrimaryReplica or > similar will be useful, at least within tests. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20365) Add ability to intentially change primaryReplica
Alexander Lapin created IGNITE-20365: Summary: Add ability to intentially change primaryReplica Key: IGNITE-20365 URL: https://issues.apache.org/jira/browse/IGNITE-20365 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18670) Sql. It is possible to reference aliases in GROUP BY clause.
[
https://issues.apache.org/jira/browse/IGNITE-18670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762373#comment-17762373
]
Yury Gerzhedovich commented on IGNITE-18670:
[~mzhuravkov] LGTM
> Sql. It is possible to reference aliases in GROUP BY clause.
>
>
> Key: IGNITE-18670
> URL: https://issues.apache.org/jira/browse/IGNITE-18670
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently we expect the query bellow to fail
> {code:java}
> SELECT 1 AS k, SUM(i) FROM integers GROUP BY k+1 ORDER BY 2;
> {code}
> But in https://issues.apache.org/jira/browse/IGNITE-18212 we decided that
> ignite's dialect of the SQL supports this behaviour.
> Update test_group_by.test and mark the query as OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20364) Design the details how zone partition listeners will support multiple table partitions
Kirill Gusakov created IGNITE-20364: --- Summary: Design the details how zone partition listeners will support multiple table partitions Key: IGNITE-20364 URL: https://issues.apache.org/jira/browse/IGNITE-20364 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov *Motivation* Due to the fact, that the new data layout will be built around the zone-based partition: one zone partition (one RAFT peer at the node) will store multiple table partitions (multiple state machines for one RAFT peer). So, we need to prepare details according for [document|https://github.com/apache/ignite-3/blob/1abb67c8770179d5d3e295876b73893f3845a08e/modules/distribution-zones/tech-notes/zone-collocation.md#L1] to clarify implementation details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20363) Implement the aggregated state machine, which routes the command to appropriate concrete state machines
Kirill Gusakov created IGNITE-20363: --- Summary: Implement the aggregated state machine, which routes the command to appropriate concrete state machines Key: IGNITE-20363 URL: https://issues.apache.org/jira/browse/IGNITE-20363 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov *Motivation* According to the new zone-based partitions design every raft peer handle the command for different tables. So, we need to introduce the abstracted "aggregated state machine", which will route the commands to the concrete tables state machines TODO: Add details of implementation and definition of done -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20362) Implement the ReplicationServerManager component
Kirill Gusakov created IGNITE-20362: --- Summary: Implement the ReplicationServerManager component Key: IGNITE-20362 URL: https://issues.apache.org/jira/browse/IGNITE-20362 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov *Motivation* Under the design [document|https://github.com/apache/ignite-3/blob/1abb67c8770179d5d3e295876b73893f3845a08e/modules/distribution-zones/tech-notes/zone-collocation.md#L1] was introduced new component, which must decouple the intention to start new zone partition peer and intention to populate it by concrete table partition listeners. *Definition of done* - The right name for this component chosen ( :) ) - Component is implemented with appropriate start/stop behaviour: -- if component is not started addReplicationServer/addTablePartitionListener just populate the internal state machine with the appropriate intentions -- on the start of the component all intentions must be resolved in real peers with aggregated state machines -- after the start addReplicationServer/addTablePartitionListener methods must immediately start the needed entities -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20361) Implement the table storage description
[ https://issues.apache.org/jira/browse/IGNITE-20361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-20361: Description: *Motivation* According to IGNITE-20357 we need to have an appropriate table storage configuration, which can be used on the table create/alter to check if the chosen zone has appropriate storage requirements. *Definition of done* - Table has the storage configuration, which can be used for early validation if table can be "deployed" in its zone correctly. - Data storage configuration removed from zone configuration > Implement the table storage description > --- > > Key: IGNITE-20361 > URL: https://issues.apache.org/jira/browse/IGNITE-20361 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > > *Motivation* > According to IGNITE-20357 we need to have an appropriate table storage > configuration, which can be used on the table create/alter to check if the > chosen zone has appropriate storage requirements. > *Definition of done* > - Table has the storage configuration, which can be used for early validation > if table can be "deployed" in its zone correctly. > - Data storage configuration removed from zone configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20361) Implement the table storage description
Kirill Gusakov created IGNITE-20361: --- Summary: Implement the table storage description Key: IGNITE-20361 URL: https://issues.apache.org/jira/browse/IGNITE-20361 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20360) Implement the zone filter for storage types and profiles
Kirill Gusakov created IGNITE-20360: --- Summary: Implement the zone filter for storage types and profiles Key: IGNITE-20360 URL: https://issues.apache.org/jira/browse/IGNITE-20360 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov *Motivation* According to IGNITE-20357 we need to have an appropriate zone filter, which filters the nodes based on their available storages. *Definition of done* - Zone has the filters, which can be unambiguously used to check if table can be "deployed" in this zone -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20359) Expose node storage as a node attribute
Kirill Gusakov created IGNITE-20359: --- Summary: Expose node storage as a node attribute Key: IGNITE-20359 URL: https://issues.apache.org/jira/browse/IGNITE-20359 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov *Motivation* To introduce the nodes' filtering by storage type and profile we need to expose the appropriate node storage configurations as node attributes. *Definition of done* - Node storage and storage profile exposed as node attributes (TODO: clarify the details, when design will be finished) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20358) Make distributed node storage config local
Kirill Gusakov created IGNITE-20358:
---
Summary: Make distributed node storage config local
Key: IGNITE-20358
URL: https://issues.apache.org/jira/browse/IGNITE-20358
Project: Ignite
Issue Type: Task
Reporter: Kirill Gusakov
*Motivation*
At the moment, all {{*StorageEngineConfigurationSchema}} has the
{{ConfigurationType.DISTRIBUTED}} type. But it is not the case anymore, each
node can have the different storage configurations by new design.
*Definition of done*
- All {{*StorageEngineConfigurationSchema}} configurations moved to the
{{ConfigurationType.LOCAL}} scope.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20357) Design node config, zone and table storage relations
Kirill Gusakov created IGNITE-20357: --- Summary: Design node config, zone and table storage relations Key: IGNITE-20357 URL: https://issues.apache.org/jira/browse/IGNITE-20357 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov *Motivation* We need to clarify the UX around the table storage, zone and node configs according to zone-based collocation. *Definition of done* User has the simple and predictable flow to: - Configure the node storage from the point of view: tables with which requirements for storage can use this node. - Describe on the zone creation, the nodes with which table storages can be a part of this zone - Describe on the table creation, which storage needed for this table and receive the error as soon as possible if chosen zone can't guarantee that its nodes have this storage -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20356) Sql. Replace the RowHandler "set" operation with "append".
[
https://issues.apache.org/jira/browse/IGNITE-20356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-20356:
--
Description:
In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}" method
Instead of using {{set(int, RowT, Object)}} method, we can use the
{{append(RowT, Object)}} method to add fields sequentially.
To add this method we need:
* Implement an efficient addition of field values to BinaryTuple if it is not
implemented yet.
* Remove the {{RowHandler#set()}} method and rework all related code/tests to
use the {{RowHandler#append()}} method.
was:
In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}" method
Instead of using "{{set(int, RowT, Object)}}" method, we can use the
"{{append(RowT, Object)}}" method to add fields sequentially.
To add this method we need:
* Implement an efficient addition of field values to BinaryTuple if it is not
implemented yet.
* Remove the {{RowHandler#set()}} method and rework all related code/tests to
use the {{RowHandler#append()}} method.
> Sql. Replace the RowHandler "set" operation with "append".
> --
>
> Key: IGNITE-20356
> URL: https://issues.apache.org/jira/browse/IGNITE-20356
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
> This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}"
> method
> Instead of using {{set(int, RowT, Object)}} method, we can use the
> {{append(RowT, Object)}} method to add fields sequentially.
> To add this method we need:
> * Implement an efficient addition of field values to BinaryTuple if it is
> not implemented yet.
> * Remove the {{RowHandler#set()}} method and rework all related code/tests
> to use the {{RowHandler#append()}} method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20356) Sql. Replace the RowHandler "set" operation with "append".
[ https://issues.apache.org/jira/browse/IGNITE-20356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-20356: -- Description: In IGNITE-19791, a wrapper over BinaryTuple was added. This wrapper (BinaryTupleRowWrapper) does not support the "set()" method Instead of using "set(int, RowT, Object)" method, we can use the "append(RowT, Object)" method to add fields sequentially. To add this method we need: * Implement an efficient addition of field values to BinaryTuple if it is not implemented yet. * Remove the RowHandler#set() method and rework all related code/tests to use the "RowHandler#append()" method. was: In IGNITE-19791, a wrapper over BinaryTuple was added. This wrapper (BinaryTupleRowWrapper) does not support the "set()" method Instead of using "set(int, RowT, Object)" method, we can use the "append(RowT, Object)" method to add fields sequentially. To add this method we need: * Implement an efficient addition of fields to BinaryTuple if it is not implemented yet. * Remove the RowHandler#set() method and rework all related code/tests to use the "RowHandler#append()" method. > Sql. Replace the RowHandler "set" operation with "append". > -- > > Key: IGNITE-20356 > URL: https://issues.apache.org/jira/browse/IGNITE-20356 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > In IGNITE-19791, a wrapper over BinaryTuple was added. > This wrapper (BinaryTupleRowWrapper) does not support the "set()" method > Instead of using "set(int, RowT, Object)" method, we can use the > "append(RowT, Object)" method to add fields sequentially. > To add this method we need: > * Implement an efficient addition of field values to BinaryTuple if it is > not implemented yet. > * Remove the RowHandler#set() method and rework all related code/tests to > use the "RowHandler#append()" method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20356) Sql. Replace the RowHandler "set" operation with "append".
[
https://issues.apache.org/jira/browse/IGNITE-20356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-20356:
--
Description:
In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}" method
Instead of using "{{set(int, RowT, Object)}}" method, we can use the
"{{append(RowT, Object)}}" method to add fields sequentially.
To add this method we need:
* Implement an efficient addition of field values to BinaryTuple if it is not
implemented yet.
* Remove the {{RowHandler#set()}} method and rework all related code/tests to
use the {{RowHandler#append()}} method.
was:
In IGNITE-19791, a wrapper over BinaryTuple was added.
This wrapper (BinaryTupleRowWrapper) does not support the "set()" method
Instead of using "set(int, RowT, Object)" method, we can use the "append(RowT,
Object)" method to add fields sequentially.
To add this method we need:
* Implement an efficient addition of field values to BinaryTuple if it is not
implemented yet.
* Remove the RowHandler#set() method and rework all related code/tests to use
the "RowHandler#append()" method.
> Sql. Replace the RowHandler "set" operation with "append".
> --
>
> Key: IGNITE-20356
> URL: https://issues.apache.org/jira/browse/IGNITE-20356
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
> This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}"
> method
> Instead of using "{{set(int, RowT, Object)}}" method, we can use the
> "{{append(RowT, Object)}}" method to add fields sequentially.
> To add this method we need:
> * Implement an efficient addition of field values to BinaryTuple if it is
> not implemented yet.
> * Remove the {{RowHandler#set()}} method and rework all related code/tests
> to use the {{RowHandler#append()}} method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20356) Sql. Replace the RowHandler "set" operation with "append".
Pavel Pereslegin created IGNITE-20356: - Summary: Sql. Replace the RowHandler "set" operation with "append". Key: IGNITE-20356 URL: https://issues.apache.org/jira/browse/IGNITE-20356 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Pereslegin In IGNITE-19791, a wrapper over BinaryTuple was added. This wrapper (BinaryTupleRowWrapper) does not support the "set()" method Instead of using "set(int, RowT, Object)" method, we can use the "append(RowT, Object)" method to add fields sequentially. To add this method we need: * Implement an efficient addition of fields to BinaryTuple if it is not implemented yet. * Remove the RowHandler#set() method and rework all related code/tests to use the "RowHandler#append()" method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20355) TxLocalTest RO tests hangs infinitely
[
https://issues.apache.org/jira/browse/IGNITE-20355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20355:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> TxLocalTest RO tests hangs infinitely
> --
>
> Key: IGNITE-20355
> URL: https://issues.apache.org/jira/browse/IGNITE-20355
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
>
> {code:java}
> testReadOnlyGet
> testReadOnlyScan
> testReadOnlyGetWriteIntentResolutionUpdate
> testReadOnlyGetWriteIntentResolutionRemove
> testReadOnlyGetAll
> testReadOnlyPendingWriteIntentSkippedCombined
> {code}
> hangs infinitely.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20355) TxLocalTest RO tests hangs infinitely
[
https://issues.apache.org/jira/browse/IGNITE-20355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20355:
-
Description:
{code:java}
testReadOnlyGet
testReadOnlyScan
testReadOnlyGetWriteIntentResolutionUpdate
testReadOnlyGetWriteIntentResolutionRemove
testReadOnlyGetAll
testReadOnlyPendingWriteIntentSkippedCombined
{code}
hangs infinitely.
was:
{code:java}
testReadOnlyGet
testReadOnlyScan
testReadOnlyGetWriteIntentResolutionUpdate
testReadOnlyGetWriteIntentResolutionRemove
testReadOnlyGetAll
testReadOnlyPendingWriteIntentSkippedCombined
{code}
hangs infinitely.
> TxLocalTest RO tests hangs infinitely
> --
>
> Key: IGNITE-20355
> URL: https://issues.apache.org/jira/browse/IGNITE-20355
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
>
> {code:java}
> testReadOnlyGet
> testReadOnlyScan
> testReadOnlyGetWriteIntentResolutionUpdate
> testReadOnlyGetWriteIntentResolutionRemove
> testReadOnlyGetAll
> testReadOnlyPendingWriteIntentSkippedCombined
> {code}
> hangs infinitely.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20355) TxLocalTest RO tests hangs infinitely
Alexander Lapin created IGNITE-20355:
Summary: TxLocalTest RO tests hangs infinitely
Key: IGNITE-20355
URL: https://issues.apache.org/jira/browse/IGNITE-20355
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
{code:java}
testReadOnlyGet
testReadOnlyScan
testReadOnlyGetWriteIntentResolutionUpdate
testReadOnlyGetWriteIntentResolutionRemove
testReadOnlyGetAll
testReadOnlyPendingWriteIntentSkippedCombined
{code}
hangs infinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20354) Reduce code duplication in commit cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov updated IGNITE-20354: --- Description: PartitionListener and PartitionReplicaListener have the storage cleanup code duplicated, any change to it should be introduced in both places. *Implementation details* There is already a StorageUpdateHandler that was created to reuse the storage access logic. The storage commit cleanup should be moved into this class from both *Listener classes. was: PartitionListener and PartitionReplicaListener have the storage cleanup code duplicated, any change to it should be introduced in both places. *Implementation details* There is already a StorageUpdateHandler that was created to reuse the storage access logic. The storage commit cleanup should be moved into this class from both *LIstener classes. > Reduce code duplication in commit cleanup > - > > Key: IGNITE-20354 > URL: https://issues.apache.org/jira/browse/IGNITE-20354 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > > PartitionListener and PartitionReplicaListener have the storage cleanup code > duplicated, any change to it should be introduced in both places. > *Implementation details* > There is already a StorageUpdateHandler that was created to reuse the storage > access logic. > The storage commit cleanup should be moved into this class from both > *Listener classes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20308) Java thin 3.0: testBasicStreamingRecordBinaryView is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762354#comment-17762354
]
Pavel Tupitsyn commented on IGNITE-20308:
-
Merged to main: c07258e61b2bfc134c04b3d461dab330d8a509af
> Java thin 3.0: testBasicStreamingRecordBinaryView is flaky
> --
>
> Key: IGNITE-20308
> URL: https://issues.apache.org/jira/browse/IGNITE-20308
> 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
>
>
> *ItAbstractDataStreamerTest.clearTable* fails:
> {code}
> org.apache.ignite.lang.IgniteException: IGN-TX-4
> TraceId:18f1582b-d06b-450e-8086-82b7cdd9d02a Query remote fragment execution
> failed: nodeName=isdst_n_0, queryId=8d7c7cdf-6603-4273-9451-c467aa9d93e7,
> fragmentId=11503, originalMessage=Failed to acquire a lock due to a conflict
> [txId=018a3bc3-dd20---eef4a2bb, conflictingWaiter=WaiterImpl
> [txId=018a3bc3-dd1c---eef4a2bb, intendedLockMode=null,
> lockMode=IX, ex=null, isDone=true]]
> at
> app//org.apache.ignite.internal.sql.engine.util.SqlExceptionMapperProvider.lambda$mappers$2(SqlExceptionMapperProvider.java:55)
> at
> app//org.apache.ignite.lang.IgniteExceptionMapper.map(IgniteExceptionMapper.java:59)
> at
> app//org.apache.ignite.lang.IgniteExceptionMapperUtil.map(IgniteExceptionMapperUtil.java:138)
> at
> app//org.apache.ignite.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:97)
> at
> app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.wrapIfNecessary(AsyncSqlCursorImpl.java:104)
> at
> app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:79)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:157)
> at
> java.base@11.0.17/java.util.concurrent.ConcurrentLinkedQueue.forEachFrom(ConcurrentLinkedQueue.java:1037)
> at
> java.base@11.0.17/java.util.concurrent.ConcurrentLinkedQueue.forEach(ConcurrentLinkedQueue.java:1054)
> at
> app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:157)
> at
> app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:112)
> at
> app//org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$onError$2(ExecutionServiceImpl.java:526)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniAcceptNow(CompletableFuture.java:753)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:731)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:2108)
> at
> app//org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.onError(ExecutionServiceImpl.java:525)
> at
> app//org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:377)
> at
> app//org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$4(ExecutionServiceImpl.java:226)
> at
> app//org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:150)
> at
> app//org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$1(MessageServiceImpl.java:121)
> at
> app//org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:81)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
> Suppressed: java.lang.RuntimeException: This is a trimmed root
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:743)
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:763)
> at
> org.apache.ignite.internal.sql.engine.util.CursorUtils.getAllFromCursor(CursorUtils.java:70)
[jira] [Commented] (IGNITE-20308) Java thin 3.0: testBasicStreamingRecordBinaryView is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762352#comment-17762352
]
Igor Sapego commented on IGNITE-20308:
--
Looks good to me.
> Java thin 3.0: testBasicStreamingRecordBinaryView is flaky
> --
>
> Key: IGNITE-20308
> URL: https://issues.apache.org/jira/browse/IGNITE-20308
> 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
>
>
> *ItAbstractDataStreamerTest.clearTable* fails:
> {code}
> org.apache.ignite.lang.IgniteException: IGN-TX-4
> TraceId:18f1582b-d06b-450e-8086-82b7cdd9d02a Query remote fragment execution
> failed: nodeName=isdst_n_0, queryId=8d7c7cdf-6603-4273-9451-c467aa9d93e7,
> fragmentId=11503, originalMessage=Failed to acquire a lock due to a conflict
> [txId=018a3bc3-dd20---eef4a2bb, conflictingWaiter=WaiterImpl
> [txId=018a3bc3-dd1c---eef4a2bb, intendedLockMode=null,
> lockMode=IX, ex=null, isDone=true]]
> at
> app//org.apache.ignite.internal.sql.engine.util.SqlExceptionMapperProvider.lambda$mappers$2(SqlExceptionMapperProvider.java:55)
> at
> app//org.apache.ignite.lang.IgniteExceptionMapper.map(IgniteExceptionMapper.java:59)
> at
> app//org.apache.ignite.lang.IgniteExceptionMapperUtil.map(IgniteExceptionMapperUtil.java:138)
> at
> app//org.apache.ignite.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:97)
> at
> app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.wrapIfNecessary(AsyncSqlCursorImpl.java:104)
> at
> app//org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:79)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:157)
> at
> java.base@11.0.17/java.util.concurrent.ConcurrentLinkedQueue.forEachFrom(ConcurrentLinkedQueue.java:1037)
> at
> java.base@11.0.17/java.util.concurrent.ConcurrentLinkedQueue.forEach(ConcurrentLinkedQueue.java:1054)
> at
> app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:157)
> at
> app//org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:112)
> at
> app//org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$onError$2(ExecutionServiceImpl.java:526)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniAcceptNow(CompletableFuture.java:753)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:731)
> at
> java.base@11.0.17/java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:2108)
> at
> app//org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.onError(ExecutionServiceImpl.java:525)
> at
> app//org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:377)
> at
> app//org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$4(ExecutionServiceImpl.java:226)
> at
> app//org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:150)
> at
> app//org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$1(MessageServiceImpl.java:121)
> at
> app//org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:81)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base@11.0.17/java.lang.Thread.run(Thread.java:834)
> Suppressed: java.lang.RuntimeException: This is a trimmed root
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:743)
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.await(IgniteTestUtils.java:763)
> at
> org.apache.ignite.internal.sql.engine.util.CursorUtils.getAllFromCursor(CursorUtils.java:70)
> at
> org.apache.ignite.internal.sql.en
[jira] [Updated] (IGNITE-20149) Sql. Revise use INTERNAL_ERR in sql module
[ https://issues.apache.org/jira/browse/IGNITE-20149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-20149: Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Revise use INTERNAL_ERR in sql module > -- > > Key: IGNITE-20149 > URL: https://issues.apache.org/jira/browse/IGNITE-20149 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Error code Common.INTERNAL_ERR should use only for internal error, which > could treat as a bug require attention from developer. However we use the > error code often and for normal situation, e.g. node left during execution of > a query. > Let's revise SQL module on use INTERNAL_ERR error code according the above. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18670) Sql. It is possible to reference aliases in GROUP BY clause.
[
https://issues.apache.org/jira/browse/IGNITE-18670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-18670:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. It is possible to reference aliases in GROUP BY clause.
>
>
> Key: IGNITE-18670
> URL: https://issues.apache.org/jira/browse/IGNITE-18670
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently we expect the query bellow to fail
> {code:java}
> SELECT 1 AS k, SUM(i) FROM integers GROUP BY k+1 ORDER BY 2;
> {code}
> But in https://issues.apache.org/jira/browse/IGNITE-18212 we decided that
> ignite's dialect of the SQL supports this behaviour.
> Update test_group_by.test and mark the query as OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20226) Sql. Some tests are muted after casting char -> varbinary is disallowed
[
https://issues.apache.org/jira/browse/IGNITE-20226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20226:
--
Description:
Some tests was muted under this issue, some refactoring is helpful.
Because BINARY/VARBINARY is not convertible from any other types, the following
test cases should be disabled or moved to appropriate subclasses
{code}
testCoalesceMissingTypesIsIllegal
testEqConditionWithDynamicParameters
testInsertFromDynamicParameterFromConvertible
testDisallowMismatchTypesOnInsertDynamicParam
testDisallowMismatchTypesOnInsert
testUpdateFromDynamicParameterFromConvertible
{code}
`testCastFromString` can simply be moved to `ItUuidExpressionTest`.
was:
Some tests was muted under this issue, some refactoring is helpful.
Because BINARY/VARBINARY is not convertible from any other types, the following
test cases should be disabled for in appropriate subclasses
{code}
testCoalesceMissingTypesIsIllegal
testEqConditionWithDynamicParameters
testInsertFromDynamicParameterFromConvertible
testDisallowMismatchTypesOnInsertDynamicParam
testDisallowMismatchTypesOnInsert
testUpdateFromDynamicParameterFromConvertible
{code}
`testCastFromString` can simply be moved to `ItUuidExpressionTest`.
> Sql. Some tests are muted after casting char -> varbinary is disallowed
> ---
>
> Key: IGNITE-20226
> URL: https://issues.apache.org/jira/browse/IGNITE-20226
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Some tests was muted under this issue, some refactoring is helpful.
> Because BINARY/VARBINARY is not convertible from any other types, the
> following test cases should be disabled or moved to appropriate subclasses
> {code}
> testCoalesceMissingTypesIsIllegal
> testEqConditionWithDynamicParameters
> testInsertFromDynamicParameterFromConvertible
> testDisallowMismatchTypesOnInsertDynamicParam
> testDisallowMismatchTypesOnInsert
> testUpdateFromDynamicParameterFromConvertible
> {code}
> `testCastFromString` can simply be moved to `ItUuidExpressionTest`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20226) Sql. Some tests are muted after casting char -> varbinary is disallowed
[
https://issues.apache.org/jira/browse/IGNITE-20226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20226:
--
Description:
Some tests was muted under this issue, some refactoring is helpful.
Because BINARY/VARBINARY is not convertible from any other types, the following
test cases should be disabled for in appropriate subclasses
{code}
testCoalesceMissingTypesIsIllegal
testEqConditionWithDynamicParameters
testInsertFromDynamicParameterFromConvertible
testDisallowMismatchTypesOnInsertDynamicParam
testDisallowMismatchTypesOnInsert
testUpdateFromDynamicParameterFromConvertible
{code}
`testCastFromString` can simply be moved to `ItUuidExpressionTest`.
was:Some tests was muted under this issue, some refactoring is helpful
> Sql. Some tests are muted after casting char -> varbinary is disallowed
> ---
>
> Key: IGNITE-20226
> URL: https://issues.apache.org/jira/browse/IGNITE-20226
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Some tests was muted under this issue, some refactoring is helpful.
> Because BINARY/VARBINARY is not convertible from any other types, the
> following test cases should be disabled for in appropriate subclasses
> {code}
> testCoalesceMissingTypesIsIllegal
> testEqConditionWithDynamicParameters
> testInsertFromDynamicParameterFromConvertible
> testDisallowMismatchTypesOnInsertDynamicParam
> testDisallowMismatchTypesOnInsert
> testUpdateFromDynamicParameterFromConvertible
> {code}
> `testCastFromString` can simply be moved to `ItUuidExpressionTest`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20354) Reduce code duplication in commit cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov reassigned IGNITE-20354: -- Assignee: Kirill Sizov > Reduce code duplication in commit cleanup > - > > Key: IGNITE-20354 > URL: https://issues.apache.org/jira/browse/IGNITE-20354 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > > PartitionListener and PartitionReplicaListener have the storage cleanup code > duplicated, any change to it should be introduced in both places. > *Implementation details* > There is already a StorageUpdateHandler that was created to reuse the storage > access logic. > The storage commit cleanup should be moved into this class from both > *LIstener classes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20354) Reduce code duplication in commit cleanup
Kirill Sizov created IGNITE-20354: -- Summary: Reduce code duplication in commit cleanup Key: IGNITE-20354 URL: https://issues.apache.org/jira/browse/IGNITE-20354 Project: Ignite Issue Type: Task Reporter: Kirill Sizov PartitionListener and PartitionReplicaListener have the storage cleanup code duplicated, any change to it should be introduced in both places. *Implementation details* There is already a StorageUpdateHandler that was created to reuse the storage access logic. The storage commit cleanup should be moved into this class from both *LIstener classes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20354) Reduce code duplication in commit cleanup
[ https://issues.apache.org/jira/browse/IGNITE-20354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov updated IGNITE-20354: --- Labels: ignite-3 (was: ) > Reduce code duplication in commit cleanup > - > > Key: IGNITE-20354 > URL: https://issues.apache.org/jira/browse/IGNITE-20354 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Priority: Major > Labels: ignite-3 > > PartitionListener and PartitionReplicaListener have the storage cleanup code > duplicated, any change to it should be introduced in both places. > *Implementation details* > There is already a StorageUpdateHandler that was created to reuse the storage > access logic. > The storage commit cleanup should be moved into this class from both > *LIstener classes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20184) Move dataStorage configuration from zone to table configuration config
[ https://issues.apache.org/jira/browse/IGNITE-20184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-20184: Epic Link: IGNITE-19170 > Move dataStorage configuration from zone to table configuration config > --- > > Key: IGNITE-20184 > URL: https://issues.apache.org/jira/browse/IGNITE-20184 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > After IGNITE-19002 we decided to move the dataStorage configuration back, > because the clarification in the design of table-zone relations. Appropriate > tests for table dataStorage configuration should be restored too -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20000) Sql. Add planner test to verify numeric type coercion in binary arithmetic
[ https://issues.apache.org/jira/browse/IGNITE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-2: --- Description: Let's add new tests to validate numeric type coercion in binary arithmetic. The tests should be as easy as possible, every test case must answer a question "what are expected types of each operand when we do arithmetic with a given numeric type pair?" Look to NumericComparisonTypeCoercionTest as example. was:Let's add new tests to validate numeric type coercion in binary arithmetic. The tests should be as easy as possible, every test case must answer a question "what are expected types of each operand when we do arithmetic with a given numeric type pair?" > Sql. Add planner test to verify numeric type coercion in binary arithmetic > --- > > Key: IGNITE-2 > URL: https://issues.apache.org/jira/browse/IGNITE-2 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Let's add new tests to validate numeric type coercion in binary arithmetic. > The tests should be as easy as possible, every test case must answer a > question "what are expected types of each operand when we do arithmetic with > a given numeric type pair?" > Look to NumericComparisonTypeCoercionTest as example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20264) Sql. SortAggregateExecutionTest::countOfEmptyWithRewind [MAP_REDUCE] is flaky.
[
https://issues.apache.org/jira/browse/IGNITE-20264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20264:
---
Description:
This issue is reproduces even on revisions prior to changes made for migration
to BinaryTuple (IGNITE-19785)
{code:java}
org.opentest4j.AssertionFailedError:
Expected :true
Actual :false
at
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
org.apache.ignite.internal.sql.engine.exec.rel.BaseAggregateTest.countOfEmptyWithRewind(BaseAggregateTest.java:659)
{code}
HashAggregateExecutionTest::countOfEmptyWithRewind does not have such problem
(or I was unable to reproduce it).
was:
This issue is reproduces even on revisions prior to changes made for migration
to BinaryTuple (IGNITE-19785).
{code:java}
org.opentest4j.AssertionFailedError:
Expected :true
Actual :false
at
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
org.apache.ignite.internal.sql.engine.exec.rel.BaseAggregateTest.countOfEmptyWithRewind(BaseAggregateTest.java:659)
{code}
HashAggregateExecutionTest::countOfEmptyWithRewind does not have such problem
(or I was unable to reproduce it).
> Sql. SortAggregateExecutionTest::countOfEmptyWithRewind [MAP_REDUCE] is flaky.
> --
>
> Key: IGNITE-20264
> URL: https://issues.apache.org/jira/browse/IGNITE-20264
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> This issue is reproduces even on revisions prior to changes made for
> migration to BinaryTuple (IGNITE-19785)
> {code:java}
> org.opentest4j.AssertionFailedError:
> Expected :true
> Actual :false
> at
> org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.BaseAggregateTest.countOfEmptyWithRewind(BaseAggregateTest.java:659)
> {code}
> HashAggregateExecutionTest::countOfEmptyWithRewind does not have such problem
> (or I was unable to reproduce it).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20264) Sql. SortAggregateExecutionTest::countOfEmptyWithRewind [MAP_REDUCE] is flaky.
[
https://issues.apache.org/jira/browse/IGNITE-20264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20264:
---
Priority: Blocker (was: Minor)
> Sql. SortAggregateExecutionTest::countOfEmptyWithRewind [MAP_REDUCE] is flaky.
> --
>
> Key: IGNITE-20264
> URL: https://issues.apache.org/jira/browse/IGNITE-20264
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> This issue is reproduces even on revisions prior to changes made for
> migration to BinaryTuple (IGNITE-19785).
> {code:java}
> org.opentest4j.AssertionFailedError:
> Expected :true
> Actual :false
> at
> org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.BaseAggregateTest.countOfEmptyWithRewind(BaseAggregateTest.java:659)
> {code}
> HashAggregateExecutionTest::countOfEmptyWithRewind does not have such problem
> (or I was unable to reproduce it).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20295) Get rid of server-side session management
[ https://issues.apache.org/jira/browse/IGNITE-20295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20295: --- Description: At the begining of Ignite 3 was plans to have server side sessions and partially it was implemented, but now it's not actual and we could remove all obsolete code related to the part. At least required to remove package org.apache.ignite.internal.sql.engine.session with all classes Also need to remove org.apache.ignite.sql.Session#idleTimeout All stuff requires for keep 'session' information could be moved to client handlers, like a ClientResource class. was: At the begining of Ignite 3 was plans to have server side sessions and partially it was implemented, but now it's not actual and we could remove all obsolete code related to the part. At least required to remove package org.apache.ignite.internal.sql.engine.session with all classes All stuff requires for keep 'session' information could be moved to client handlers, like a ClientResource class. > Get rid of server-side session management > - > > Key: IGNITE-20295 > URL: https://issues.apache.org/jira/browse/IGNITE-20295 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > At the begining of Ignite 3 was plans to have server side sessions and > partially it was implemented, but now it's not actual and we could remove all > obsolete code related to the part. > At least required to remove package > org.apache.ignite.internal.sql.engine.session with all classes > Also need to remove org.apache.ignite.sql.Session#idleTimeout > All stuff requires for keep 'session' information could be moved to client > handlers, like a ClientResource class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Fix behaviour of ROUND function.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
Implementation we agreed upon:
- For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
- For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision of
N's type, and derived_s is scale of N's type.
Examples:
{code}
# ROUND(N):
SELECT ROUND(1.1)
# Returns 1. Type: DECIMAL(p, 0)
# ROUND(N, s):
SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
# Returns
# 1.000
# 1.100
# 1.120
# 1.123
# 1.1230
{code}
was:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
> Sql. Fix behaviour of ROUND function.
> -
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2, RowSchema
> has NativeType (precision=2, scale=1).
> # Because of that this query returns 2.0
> {code}
> Implementation we agreed upon:
> - For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
> - For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision
> of N's type, and derived_s is scale of N's type.
> Examples:
> {code}
> # ROUND(N):
> SELECT ROUND(1.1)
> # Returns 1. Type: DECIMAL(p, 0)
> # ROUND(N, s):
> SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
> # Returns
> # 1.000
> # 1.100
> # 1.120
> # 1.123
> # 1.1230
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14818) Implement compression of short primitives
[
https://issues.apache.org/jira/browse/IGNITE-14818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14818:
---
Reviewer: Roman Puchkovskiy
> Implement compression of short primitives
> -
>
> Key: IGNITE-14818
> URL: https://issues.apache.org/jira/browse/IGNITE-14818
> Project: Ignite
> Issue Type: Improvement
> Components: networking
>Reporter: Aleksandr Polovtcev
>Assignee: Ivan Bessonov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Network message type consists of two {{short}} values: the message group type
> and the message type. During serialization, these values are written as
> non-compressed (2 bytes each), which can be improved to reduce the network
> pressure by compressing these {{short}} values the same way we currently do
> for {{int}} and {{long}} (see {{DirectByteBufferStreamImplV1}} for details)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19554) [ducktests] Allow to configure more options in communication and data storage
[ https://issues.apache.org/jira/browse/IGNITE-19554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-19554: Labels: ducktests ise (was: ducktests) > [ducktests] Allow to configure more options in communication and data storage > - > > Key: IGNITE-19554 > URL: https://issues.apache.org/jira/browse/IGNITE-19554 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests, ise > Fix For: 2.16 > > > Ducktests need more options to be configurable > _Data storage_ / _Data region_ > * lazy_memory_allocation > * page_size > * wal_page_compression > * wal_page_compression_level > * wal_path > * wal_archive_path > _TcpCommunicationSpi_ > * unacknowledged_messages_buffer_size -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19729) [ducktests] Support sqlConfiguration field in ignite configuration
[
https://issues.apache.org/jira/browse/IGNITE-19729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Nikolaev updated IGNITE-19729:
Labels: ducktests ise (was: ducktests)
> [ducktests] Support sqlConfiguration field in ignite configuration
> --
>
> Key: IGNITE-19729
> URL: https://issues.apache.org/jira/browse/IGNITE-19729
> Project: Ignite
> Issue Type: Task
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Trivial
> Labels: ducktests, ise
> Fix For: 2.16
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> To test the new calcite sql query engine the sqlConfiguration field in ignite
> configuration should be supported in ducktests.
> Additional small ducktests fixes were also included in scope:
> * Add ability to run arbitrary control.sh subcommand.
> * It appears that {{pgrep}} on some linuxes (centos) cuts long command lines
> (say with long list of jars in classpath) even if '-a' option is specified.
> So ducktape fails to detect the PID of the service java process. Rewrite via
> the {{ps}}.
> * One of the source of long command lines was a bug that IgniteSpec adds
> modules to service modules list each time the new node started. So say the
> 6th node gets command line with the same jar modules mentioned 6 times and
> the corresponing command line exceed limit for the {{pgrep}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19106) Sql. Column namings are partially broken after upgrading to calcite 1.34
[
https://issues.apache.org/jira/browse/IGNITE-19106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-19106:
---
Assignee: Evgeny Stanilovsky
> Sql. Column namings are partially broken after upgrading to calcite 1.34
>
>
> Key: IGNITE-19106
> URL: https://issues.apache.org/jira/browse/IGNITE-19106
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite3-required, ignite-3
>
> After upgrading to calcite 1.34 SqlValidator#deriveAlias and overloading call
> IgniteSqlValidator#deriveAlias is changed, thus requests like :
> select v / 2 from t, return EXPR$ instead of column name derived from
> IgniteSqlValidator#deriveAlias. Fast (near) fix looks like cover both such
> queries:
> IgnitePlanner#validateAndGetTypeMetadata ->
> {noformat}
> public ValidationResult validateAndGetTypeMetadata(SqlNode sqlNode) {
> SqlNode validatedNode = validator().validate(sqlNode);
> RelDataType type = validator().getValidatedNodeType(validatedNode);
> List> origins =
> validator().getFieldOrigins(validatedNode);
> List derived = Collections.emptyList();
> if (sqlNode instanceof SqlSelect) {
> SelectScope list = validator().getRawSelectScope((SqlSelect)
> sqlNode);
> assert type.getFieldList().size() ==
> list.getExpandedSelectList().size();
> int cnt = 0;
> derived = new ArrayList<>(list.getExpandedSelectList().size());
> for (SqlNode node : list.getExpandedSelectList()) {
> derived.add(validator().deriveAlias(node, cnt++));
> }
> }
> return new ValidationResult(validatedNode, type, origins, derived);
> }
> {noformat}
> and use this derived instead of aliases here:
> PrepareServiceImpl#resultSetMetadata
> *Be careful !* .net and cpp tests are involved too, check all issue number
> occurrences.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20332) Fix ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpTriggeredByFilterUpdateIsRestoredAfterRestart
[ https://issues.apache.org/jira/browse/IGNITE-20332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel reassigned IGNITE-20332: -- Assignee: Sergey Uttsel > Fix > ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpTriggeredByFilterUpdateIsRestoredAfterRestart > --- > > Key: IGNITE-20332 > URL: https://issues.apache.org/jira/browse/IGNITE-20332 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > *org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpTriggeredByFilterUpdateIsRestoredAfterRestart* > started to fall in the > [catalog-feature|https://github.com/apache/ignite-3/tree/catalog-feature] > branch, and on other branches that are created from it branch, need to fix it. > https://ci.ignite.apache.org/viewLog.html?buildId=7470189&buildTypeId=ApacheIgnite3xGradle_Test_RunAllTests&fromSakuraUI=true -- This message was sent by Atlassian Jira (v8.20.10#820010)
