[jira] [Updated] (IGNITE-22243) Flaky test testInternalRootConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-22243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22243:
Description:
Test is flaky [1] on main branch:
ConfigurationTreeGeneratorTest#testInternalRootConfiguration
{noformat}
org.opentest4j.AssertionFailedError: expected:
but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertSame.failNotSame(AssertSame.java:50)
at app//org.junit.jupiter.api.AssertSame.assertSame(AssertSame.java:35)
at app//org.junit.jupiter.api.AssertSame.assertSame(AssertSame.java:30)
at app//org.junit.jupiter.api.Assertions.assertSame(Assertions.java:2860)
at
app//org.apache.ignite.internal.configuration.asm.ConfigurationTreeGeneratorTest.testInternalRootConfiguration(ConfigurationTreeGeneratorTest.java:162)
{noformat}
[1]
https://ci.ignite.apache.org/test/-6792168119546535105?currentProjectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual&expandTestHistoryChartSection=true
was:
Test is flaky [1] on main branch:
ConfigurationTreeGeneratorTest#testInternalRootConfiguration
[1]
https://ci.ignite.apache.org/test/-6792168119546535105?currentProjectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual&expandTestHistoryChartSection=true
> Flaky test testInternalRootConfiguration
>
>
> Key: IGNITE-22243
> URL: https://issues.apache.org/jira/browse/IGNITE-22243
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Test is flaky [1] on main branch:
> ConfigurationTreeGeneratorTest#testInternalRootConfiguration
> {noformat}
> org.opentest4j.AssertionFailedError: expected:
> but was:
>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertSame.failNotSame(AssertSame.java:50)
> at app//org.junit.jupiter.api.AssertSame.assertSame(AssertSame.java:35)
> at app//org.junit.jupiter.api.AssertSame.assertSame(AssertSame.java:30)
> at app//org.junit.jupiter.api.Assertions.assertSame(Assertions.java:2860)
> at
> app//org.apache.ignite.internal.configuration.asm.ConfigurationTreeGeneratorTest.testInternalRootConfiguration(ConfigurationTreeGeneratorTest.java:162)
> {noformat}
> [1]
> https://ci.ignite.apache.org/test/-6792168119546535105?currentProjectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual&expandTestHistoryChartSection=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22243) Flaky test testInternalRootConfiguration
Evgeny Stanilovsky created IGNITE-22243: --- Summary: Flaky test testInternalRootConfiguration Key: IGNITE-22243 URL: https://issues.apache.org/jira/browse/IGNITE-22243 Project: Ignite Issue Type: Bug Components: general Affects Versions: 3.0.0-beta1 Reporter: Evgeny Stanilovsky Test is flaky [1] on main branch: ConfigurationTreeGeneratorTest#testInternalRootConfiguration [1] https://ci.ignite.apache.org/test/-6792168119546535105?currentProjectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual&expandTestHistoryChartSection=true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22140) Possible pagination bug in GridCacheQueryManager#runQuery()
[ https://issues.apache.org/jira/browse/IGNITE-22140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Valuyskiy updated IGNITE-22140: Description: It looks like there is a pagination bug in the GridCacheQueryManager#runQuery() method caused by fact that the ‘cnt’ counter doesn’t get reset after sending the first page with query results. It is advised to find out whether the bug really exists and fix it if that’s the case. was: It looks like there is a pagination bug in the GridCacheQueryManager#runQuery() method caused by fact that the ‘cnt’ counter doesn’t get reset after sending the first page with query results. It is advised to find out whether the bug really exists and fix it of that’s the case. > Possible pagination bug in GridCacheQueryManager#runQuery() > --- > > Key: IGNITE-22140 > URL: https://issues.apache.org/jira/browse/IGNITE-22140 > Project: Ignite > Issue Type: Task >Reporter: Oleg Valuyskiy >Assignee: Oleg Valuyskiy >Priority: Major > Labels: ise > > It looks like there is a pagination bug in the > GridCacheQueryManager#runQuery() method caused by fact that the ‘cnt’ counter > doesn’t get reset after sending the first page with query results. > It is advised to find out whether the bug really exists and fix it if that’s > the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22215) Fix for ThinClientIndexQueryTest#testPageSize
[ https://issues.apache.org/jira/browse/IGNITE-22215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Valuyskiy updated IGNITE-22215: Description: There is a bug in ThinClientIndexQueryTest#testPageSize where the 'reqs' collection is always empty as a wrong class is used for recording next page requests (GridQueryNextPageRequest instead of GridCacheQueryRequest). (was: There is a bug in ThinClientIndexQueryTest#testPageSize where the 'reqs' collection is always as a wrong class is used for recording next page requests (GridQueryNextPageRequest instead of GridCacheQueryRequest).) > Fix for ThinClientIndexQueryTest#testPageSize > - > > Key: IGNITE-22215 > URL: https://issues.apache.org/jira/browse/IGNITE-22215 > Project: Ignite > Issue Type: Task >Reporter: Oleg Valuyskiy >Assignee: Oleg Valuyskiy >Priority: Minor > Labels: ise > > There is a bug in ThinClientIndexQueryTest#testPageSize where the 'reqs' > collection is always empty as a wrong class is used for recording next page > requests (GridQueryNextPageRequest instead of GridCacheQueryRequest). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22242) Inject LogStorageFactory dependency in Loza & JRaftServer
[
https://issues.apache.org/jira/browse/IGNITE-22242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846376#comment-17846376
]
Tiago Marques Godinho commented on IGNITE-22242:
This is likely going to be needed to implement IGNITE-21930.
> Inject LogStorageFactory dependency in Loza & JRaftServer
> -
>
> Key: IGNITE-22242
> URL: https://issues.apache.org/jira/browse/IGNITE-22242
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Assignee: Tiago Marques Godinho
>Priority: Minor
> Labels: ignite-3
>
> Currently, the default{color:#00} LogStorageFactory in being created in
> the JRaftServerImpl constructor.
> This makes the current solution tightly coupled to this implementation.
> In order to better control the lifecycle of the Raft Log we should inject
> this dependency.
> {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22242) Inject LogStorageFactory dependency in Loza & JRaftServer
Tiago Marques Godinho created IGNITE-22242:
--
Summary: Inject LogStorageFactory dependency in Loza & JRaftServer
Key: IGNITE-22242
URL: https://issues.apache.org/jira/browse/IGNITE-22242
Project: Ignite
Issue Type: Improvement
Affects Versions: 3.0.0-beta1
Reporter: Tiago Marques Godinho
Assignee: Tiago Marques Godinho
Currently, the default{color:#00} LogStorageFactory in being created in the
JRaftServerImpl constructor.
This makes the current solution tightly coupled to this implementation.
In order to better control the lifecycle of the Raft Log we should inject this
dependency.
{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22241) Make ClusterManagementGroupManager more extensible
Tiago Marques Godinho created IGNITE-22241:
--
Summary: Make ClusterManagementGroupManager more extensible
Key: IGNITE-22241
URL: https://issues.apache.org/jira/browse/IGNITE-22241
Project: Ignite
Issue Type: Improvement
Affects Versions: 3.0.0-beta1
Reporter: Tiago Marques Godinho
Assignee: Tiago Marques Godinho
The {color:#00}ClusterManagementGroupManager class is pretty much closed
for extension.
It is getting too complex to add functionality to this class.
It would be very nice for the future if this class supported the EventProducer
API.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22240) Improve handling for RocksDb resources in DefaultLogStorage and SharedRocksDbInstance
Tiago Marques Godinho created IGNITE-22240: -- Summary: Improve handling for RocksDb resources in DefaultLogStorage and SharedRocksDbInstance Key: IGNITE-22240 URL: https://issues.apache.org/jira/browse/IGNITE-22240 Project: Ignite Issue Type: Improvement Affects Versions: 3.0.0-beta1 Reporter: Tiago Marques Godinho Assignee: Tiago Marques Godinho Similarly to IGNITE-22175, some of the RocksResources in these classes are not being closed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22203) Refactor CommandHandler, remove unnecessary code
[
https://issues.apache.org/jira/browse/IGNITE-22203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846332#comment-17846332
]
Ignite TC Bot commented on IGNITE-22203:
{panel:title=Branch: [pull/11343/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11343/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7867552&buildTypeId=IgniteTests24Java8_RunAll]
> Refactor CommandHandler, remove unnecessary code
>
>
> Key: IGNITE-22203
> URL: https://issues.apache.org/jira/browse/IGNITE-22203
> Project: Ignite
> Issue Type: Task
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Minor
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15568:
-
Fix Version/s: 3.0.0-beta2
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
> to dhow increasing in case with high parallelism in one partition.
> There is [an example of the
> benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15568:
-
Reviewer: (was: Semyon Danilov)
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
> to dhow increasing in case with high parallelism in one partition.
> There is [an example of the
> benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22233) Implement zone partition listener and zone replica listener
[ https://issues.apache.org/jira/browse/IGNITE-22233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov reassigned IGNITE-22233: --- Assignee: Kirill Gusakov > Implement zone partition listener and zone replica listener > --- > > Key: IGNITE-22233 > URL: https://issues.apache.org/jira/browse/IGNITE-22233 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > > *Motivation* > After the IGNITE-22231 the empty RAFT and replica listeners implemented. > Under this ticket we need to implement the actual behaviour. > *Definition of done* > - RAFT group listener aggregate the table partition listeners and route the > RAFT events to actual table state machine > - TODO for replica listener -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22231) Implement zone creation trigger for ZoneReplicasManager component
[ https://issues.apache.org/jira/browse/IGNITE-22231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22231: Epic Link: IGNITE-22115 > Implement zone creation trigger for ZoneReplicasManager component > - > > Key: IGNITE-22231 > URL: https://issues.apache.org/jira/browse/IGNITE-22231 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > As a first step of ZoneReplicasManager implementation we need to implement > the basic flow of reaction to new zone creation trigger. > *Definition of done* > - On the component start assignments calculated and wrote to separate > metastore prefix (to avoid the clash with the real current table assignments) > - When the new zone created in catalog - start the appropriate RAFT node with > empty partition listener; start the replica with empty replica listener > - Implement the test PlacementDriver, which always choose the zone replica as > a primary one (zone replicas should have the appropriate prefix) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22233) Implement zone partition listener and zone replica listener
[ https://issues.apache.org/jira/browse/IGNITE-22233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22233: Epic Link: IGNITE-22115 > Implement zone partition listener and zone replica listener > --- > > Key: IGNITE-22233 > URL: https://issues.apache.org/jira/browse/IGNITE-22233 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > > *Motivation* > After the IGNITE-22232 the empty RAFT and replica listeners implemented. > Under this ticket we need to implement the actual behaviour. > *Definition of done* > - RAFT group listener aggregate the table partition listeners and route the > RAFT events to actual table state machine > - TODO for replica listener -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22233) Implement zone partition listener and zone replica listener
[ https://issues.apache.org/jira/browse/IGNITE-22233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22233: Ignite Flags: (was: Docs Required,Release Notes Required) > Implement zone partition listener and zone replica listener > --- > > Key: IGNITE-22233 > URL: https://issues.apache.org/jira/browse/IGNITE-22233 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > > *Motivation* > After the IGNITE-22232 the empty RAFT and replica listeners implemented. > Under this ticket we need to implement the actual behaviour. > *Definition of done* > - RAFT group listener aggregate the table partition listeners and route the > RAFT events to actual table state machine > - TODO for replica listener -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22233) Implement zone partition listener and zone replica listener
[ https://issues.apache.org/jira/browse/IGNITE-22233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22233: Description: *Motivation* After the IGNITE-22231 the empty RAFT and replica listeners implemented. Under this ticket we need to implement the actual behaviour. *Definition of done* - RAFT group listener aggregate the table partition listeners and route the RAFT events to actual table state machine - TODO for replica listener was: *Motivation* After the IGNITE-22232 the empty RAFT and replica listeners implemented. Under this ticket we need to implement the actual behaviour. *Definition of done* - RAFT group listener aggregate the table partition listeners and route the RAFT events to actual table state machine - TODO for replica listener > Implement zone partition listener and zone replica listener > --- > > Key: IGNITE-22233 > URL: https://issues.apache.org/jira/browse/IGNITE-22233 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > > *Motivation* > After the IGNITE-22231 the empty RAFT and replica listeners implemented. > Under this ticket we need to implement the actual behaviour. > *Definition of done* > - RAFT group listener aggregate the table partition listeners and route the > RAFT events to actual table state machine > - TODO for replica listener -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22233) Implement zone partition listener and zone replica listener
[ https://issues.apache.org/jira/browse/IGNITE-22233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22233: Description: *Motivation* After the IGNITE-22232 the empty RAFT and replica listeners implemented. Under this ticket we need to implement the actual behaviour. *Definition of done* - RAFT group listener aggregate the table partition listeners and route the RAFT events to actual table state machine - TODO for replica listener > Implement zone partition listener and zone replica listener > --- > > Key: IGNITE-22233 > URL: https://issues.apache.org/jira/browse/IGNITE-22233 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > > *Motivation* > After the IGNITE-22232 the empty RAFT and replica listeners implemented. > Under this ticket we need to implement the actual behaviour. > *Definition of done* > - RAFT group listener aggregate the table partition listeners and route the > RAFT events to actual table state machine > - TODO for replica listener -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22231) Implement zone creation trigger for ZoneReplicasManager component
[ https://issues.apache.org/jira/browse/IGNITE-22231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22231: Description: *Motivation* As a first step of ZoneReplicasManager implementation we need to implement the basic flow of reaction to new zone creation trigger. *Definition of done* - On the component start assignments calculated and wrote to separate metastore prefix (to avoid the clash with the real current table assignments) - When the new zone created in catalog - start the appropriate RAFT node with empty partition listener; start the replica with empty replica listener - Implement the test PlacementDriver, which always choose the zone replica as a primary one (zone replicas should have the appropriate prefix) > Implement zone creation trigger for ZoneReplicasManager component > - > > Key: IGNITE-22231 > URL: https://issues.apache.org/jira/browse/IGNITE-22231 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > As a first step of ZoneReplicasManager implementation we need to implement > the basic flow of reaction to new zone creation trigger. > *Definition of done* > - On the component start assignments calculated and wrote to separate > metastore prefix (to avoid the clash with the real current table assignments) > - When the new zone created in catalog - start the appropriate RAFT node with > empty partition listener; start the replica with empty replica listener > - Implement the test PlacementDriver, which always choose the zone replica as > a primary one (zone replicas should have the appropriate prefix) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22239) Python Client 3: Implement documentation generation
Igor Sapego created IGNITE-22239: Summary: Python Client 3: Implement documentation generation Key: IGNITE-22239 URL: https://issues.apache.org/jira/browse/IGNITE-22239 Project: Ignite Issue Type: New Feature Reporter: Igor Sapego Assignee: Igor Sapego Consider using Sphinx to generate documentation to be able to upload it to readthedocs.com. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22238) Python Client 3: Implement key-value view API
Igor Sapego created IGNITE-22238: Summary: Python Client 3: Implement key-value view API Key: IGNITE-22238 URL: https://issues.apache.org/jira/browse/IGNITE-22238 Project: Ignite Issue Type: New Feature Reporter: Igor Sapego Assignee: Igor Sapego Implement the API, tests and benchmarks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22237) Python Client 3: Implement record view API
Igor Sapego created IGNITE-22237: Summary: Python Client 3: Implement record view API Key: IGNITE-22237 URL: https://issues.apache.org/jira/browse/IGNITE-22237 Project: Ignite Issue Type: New Feature Reporter: Igor Sapego Assignee: Igor Sapego Implement API, tests and benchmarks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22231) Implement zone creation trigger for ZoneReplicasManager component
[ https://issues.apache.org/jira/browse/IGNITE-22231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov reassigned IGNITE-22231: --- Assignee: Kirill Gusakov > Implement zone creation trigger for ZoneReplicasManager component > - > > Key: IGNITE-22231 > URL: https://issues.apache.org/jira/browse/IGNITE-22231 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22232) Python Client 3: Implement benchmarks for binary record view operations
[ https://issues.apache.org/jira/browse/IGNITE-22232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-22232: - Summary: Python Client 3: Implement benchmarks for binary record view operations (was: Python Client 3: Implement benchmarks for record view operations) > Python Client 3: Implement benchmarks for binary record view operations > --- > > Key: IGNITE-22232 > URL: https://issues.apache.org/jira/browse/IGNITE-22232 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > > Python client performance is a major concern, as it is a big issue in Ignite > 2. Some basic benchmarks are required: > - Benchmark scenario: insert values into cluster, get values from cluster; > - Measure both throughput and latency; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22236) Python Client 3: Implement key-value binary view API
[ https://issues.apache.org/jira/browse/IGNITE-22236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-22236: - Summary: Python Client 3: Implement key-value binary view API (was: Python 3.0: Implement key-value binary view API) > Python Client 3: Implement key-value binary view API > > > Key: IGNITE-22236 > URL: https://issues.apache.org/jira/browse/IGNITE-22236 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > > Implement API, add tests and benchmarks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22236) Python 3.0: Implement key-value binary view API
Igor Sapego created IGNITE-22236: Summary: Python 3.0: Implement key-value binary view API Key: IGNITE-22236 URL: https://issues.apache.org/jira/browse/IGNITE-22236 Project: Ignite Issue Type: New Feature Reporter: Igor Sapego Assignee: Igor Sapego Implement API, add tests and benchmarks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22234) Python Client 3: Implement binary record view API
Igor Sapego created IGNITE-22234: Summary: Python Client 3: Implement binary record view API Key: IGNITE-22234 URL: https://issues.apache.org/jira/browse/IGNITE-22234 Project: Ignite Issue Type: New Feature Reporter: Igor Sapego Assignee: Igor Sapego Implement binary record view API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22231) Implement zone creation trigger for ZoneReplicasManager component
[ https://issues.apache.org/jira/browse/IGNITE-22231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22231: Labels: ignite-3 (was: ) > Implement zone creation trigger for ZoneReplicasManager component > - > > Key: IGNITE-22231 > URL: https://issues.apache.org/jira/browse/IGNITE-22231 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22235) Remove eviction-related leftovers of AI2
[ https://issues.apache.org/jira/browse/IGNITE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Myskov updated IGNITE-22235: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Remove eviction-related leftovers of AI2 > > > Key: IGNITE-22235 > URL: https://issues.apache.org/jira/browse/IGNITE-22235 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Myskov >Priority: Major > Labels: ignite-3 > > There is some code ported from AI2 but dead at the moment. The following > pieces are related to eviction and can be safely removed: > * org.apache.ignite.internal.pagememory.evict.PageEvictionTracker > * eviction-related configs in VolatilePageMemoryDataRegionConfigurationSchema -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22235) Remove eviction-related leftovers of AI2
Maksim Myskov created IGNITE-22235: -- Summary: Remove eviction-related leftovers of AI2 Key: IGNITE-22235 URL: https://issues.apache.org/jira/browse/IGNITE-22235 Project: Ignite Issue Type: Improvement Reporter: Maksim Myskov There is some code ported from AI2 but dead at the moment. The following pieces are related to eviction and can be safely removed: * org.apache.ignite.internal.pagememory.evict.PageEvictionTracker * eviction-related configs in VolatilePageMemoryDataRegionConfigurationSchema -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22233) Implement zone partition listener and zone replica listener
Kirill Gusakov created IGNITE-22233: --- Summary: Implement zone partition listener and zone replica listener Key: IGNITE-22233 URL: https://issues.apache.org/jira/browse/IGNITE-22233 Project: Ignite Issue Type: Improvement Reporter: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22232) Python Client 3: Implement benchmarks for record view operations
Igor Sapego created IGNITE-22232: Summary: Python Client 3: Implement benchmarks for record view operations Key: IGNITE-22232 URL: https://issues.apache.org/jira/browse/IGNITE-22232 Project: Ignite Issue Type: New Feature Reporter: Igor Sapego Assignee: Igor Sapego Python client performance is a major concern, as it is a big issue in Ignite 2. Some basic benchmarks are required: - Benchmark scenario: insert values into cluster, get values from cluster; - Measure both throughput and latency; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22231) Implement zone creation trigger for ZoneReplicasManager component
Kirill Gusakov created IGNITE-22231: --- Summary: Implement zone creation trigger for ZoneReplicasManager component Key: IGNITE-22231 URL: https://issues.apache.org/jira/browse/IGNITE-22231 Project: Ignite Issue Type: Improvement Reporter: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22230) Python Client 3: Implement SQL API
Igor Sapego created IGNITE-22230: Summary: Python Client 3: Implement SQL API Key: IGNITE-22230 URL: https://issues.apache.org/jira/browse/IGNITE-22230 Project: Ignite Issue Type: New Feature Reporter: Igor Sapego Assignee: Igor Sapego Implement SQL API and add related tests and benchmarks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22229) Python Client 3: Design Python Client for Ignite 3
Igor Sapego created IGNITE-9: Summary: Python Client 3: Design Python Client for Ignite 3 Key: IGNITE-9 URL: https://issues.apache.org/jira/browse/IGNITE-9 Project: Ignite Issue Type: New Feature Reporter: Igor Sapego Create, discuss with community and approve an IEP for Python Client for Ignite 3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22229) Python Client 3: Design Python Client for Ignite 3
[ https://issues.apache.org/jira/browse/IGNITE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-9: Assignee: Igor Sapego > Python Client 3: Design Python Client for Ignite 3 > -- > > Key: IGNITE-9 > URL: https://issues.apache.org/jira/browse/IGNITE-9 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > > Create, discuss with community and approve an IEP for Python Client for > Ignite 3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22228) Python Client 3: Implement Table API
Igor Sapego created IGNITE-8: Summary: Python Client 3: Implement Table API Key: IGNITE-8 URL: https://issues.apache.org/jira/browse/IGNITE-8 Project: Ignite Issue Type: New Feature Reporter: Igor Sapego Assignee: Igor Sapego Implement Table API and tests for it for Python Client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22227) Python Client 3: Implement the most basic version of Client for Ignite 3
Igor Sapego created IGNITE-7: Summary: Python Client 3: Implement the most basic version of Client for Ignite 3 Key: IGNITE-7 URL: https://issues.apache.org/jira/browse/IGNITE-7 Project: Ignite Issue Type: New Feature Reporter: Igor Sapego Assignee: Igor Sapego Needs to be done: - Set-up project structure; - Implement basic version of Python Client, that can connect to cluster; - Implement basic tests (connection to the cluster); -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22225) Start embedded AI3 in isolated class loader
[ https://issues.apache.org/jira/browse/IGNITE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin updated IGNITE-5: --- Description: > Start embedded AI3 in isolated class loader > --- > > Key: IGNITE-5 > URL: https://issues.apache.org/jira/browse/IGNITE-5 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22227) Python Client 3: Implement the most basic version of Client for Ignite 3
[ https://issues.apache.org/jira/browse/IGNITE-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-7: - Epic Link: IGNITE-6 > Python Client 3: Implement the most basic version of Client for Ignite 3 > > > Key: IGNITE-7 > URL: https://issues.apache.org/jira/browse/IGNITE-7 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > > Needs to be done: > - Set-up project structure; > - Implement basic version of Python Client, that can connect to cluster; > - Implement basic tests (connection to the cluster); -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22225) Start embedded AI3 in isolated class loader
[ https://issues.apache.org/jira/browse/IGNITE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin updated IGNITE-5: --- Description: (was: ) > Start embedded AI3 in isolated class loader > --- > > Key: IGNITE-5 > URL: https://issues.apache.org/jira/browse/IGNITE-5 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22226) Python Client 3.0
[ https://issues.apache.org/jira/browse/IGNITE-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-6: - Labels: ignite-3 (was: ) > Python Client 3.0 > - > > Key: IGNITE-6 > URL: https://issues.apache.org/jira/browse/IGNITE-6 > Project: Ignite > Issue Type: Epic > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > > An epic for tickets to implement initial version of Python Client for Ignite > 3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22226) Python Client 3.0
Igor Sapego created IGNITE-6: Summary: Python Client 3.0 Key: IGNITE-6 URL: https://issues.apache.org/jira/browse/IGNITE-6 Project: Ignite Issue Type: Epic Components: platforms, thin client Reporter: Igor Sapego Assignee: Igor Sapego An epic for tickets to implement initial version of Python Client for Ignite 3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22225) Start embedded AI3 in isolated class loader
Mikhail Pochatkin created IGNITE-5: -- Summary: Start embedded AI3 in isolated class loader Key: IGNITE-5 URL: https://issues.apache.org/jira/browse/IGNITE-5 Project: Ignite Issue Type: Improvement Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22224) Rework embedded mode API
[
https://issues.apache.org/jira/browse/IGNITE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin updated IGNITE-4:
---
Description:
Currently, we have follow classes in *ignite-api*
# org.apache.ignite.Ignite
# org.apache.ignite.Ignition
# org.apache.ignite.IgnitionManager
# org.apache.ignite.InitParameters
# org.apache.ignite.InitParametersBuilder
While the first interface still makes sense, since it is the access point to
the entire public API, the others have no such relationship to the API. These
classes and interface are necessary to start *Apache Ignite 3* in embedded mode
and cannot be used on their own, but you need to have access to the
*ignite-runner* module and use implementations from there.
This ticket proposes to remove these interfaces from the module with the public
API and move them to the new module {*}ignite-embedded{*}. Also, by anology
with Thin Clients we should rework *Ignition* interface and create
*IgniteEmbedded* interface which should be entry point to embedded mode.
*IgnitionManager* interface should be removed and *IgniteEmbedded* creation
process reworked to builder pattern like Thin Clients.
Cluster initialization process also should be reworked and all initialization
methods moved to *IgniteEmbedded* interface.
> Rework embedded mode API
> -
>
> Key: IGNITE-4
> URL: https://issues.apache.org/jira/browse/IGNITE-4
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3
>
> Currently, we have follow classes in *ignite-api*
> # org.apache.ignite.Ignite
> # org.apache.ignite.Ignition
> # org.apache.ignite.IgnitionManager
> # org.apache.ignite.InitParameters
> # org.apache.ignite.InitParametersBuilder
> While the first interface still makes sense, since it is the access point to
> the entire public API, the others have no such relationship to the API. These
> classes and interface are necessary to start *Apache Ignite 3* in embedded
> mode and cannot be used on their own, but you need to have access to the
> *ignite-runner* module and use implementations from there.
>
> This ticket proposes to remove these interfaces from the module with the
> public API and move them to the new module {*}ignite-embedded{*}. Also, by
> anology with Thin Clients we should rework *Ignition* interface and create
> *IgniteEmbedded* interface which should be entry point to embedded mode.
> *IgnitionManager* interface should be removed and *IgniteEmbedded* creation
> process reworked to builder pattern like Thin Clients.
> Cluster initialization process also should be reworked and all initialization
> methods moved to *IgniteEmbedded* interface.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22224) Rework embedded mode API
Mikhail Pochatkin created IGNITE-4: -- Summary: Rework embedded mode API Key: IGNITE-4 URL: https://issues.apache.org/jira/browse/IGNITE-4 Project: Ignite Issue Type: Improvement Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21836) KeyValueView. GetNullable produces confusing error for a PoJo when field / column nullability do not match
[
https://issues.apache.org/jira/browse/IGNITE-21836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-21836:
Fix Version/s: 3.0.0-beta2
> KeyValueView. GetNullable produces confusing error for a PoJo when field /
> column nullability do not match
> --
>
> Key: IGNITE-21836
> URL: https://issues.apache.org/jira/browse/IGNITE-21836
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> GetNullable method of KeyValueView produces a confusing error for a PoJo when
> a field is primitive but underlying column is nullable:
> {code:java}
> public class ItKvTest extends BaseSqlIntegrationTest {
> public static class BoolStr {
> boolean boolCol;
> String strCol;
> }
> @Test
> public void testGetNullable() {
> sql("CREATE TABLE t0 (ID INTEGER PRIMARY KEY, boolCol BOOLEAN, strCol
> VARCHAR)");
> Table table = CLUSTER.aliveNode().tables().table("T0");
> KeyValueView view =
> table.keyValueView(Mapper.of(Integer.class), Mapper.of(BoolStr.class));
> view.put(null, 1, null);
> view.getNullable(null, 1);
> }
> }
> {code}
> {code:java}
> org.apache.ignite.lang.MarshallerException: IGN-CMN-65535
> TraceId:ef2d9c71-8f2d-4279-99fc-25e8e14ede40 Failed to write field [id=0]
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.marshal(KeyValueViewImpl.java:524)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$putAsync$16(KeyValueViewImpl.java:225)
> at
> org.apache.ignite.internal.table.AbstractTableView.lambda$withSchemaSync$1(AbstractTableView.java:180)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2341)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:180)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:171)
> at
> org.apache.ignite.internal.table.AbstractTableView.doOperation(AbstractTableView.java:147)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.putAsync(KeyValueViewImpl.java:224)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.lambda$put$15(KeyValueViewImpl.java:216)
> at
> org.apache.ignite.internal.table.AbstractTableView.sync(AbstractTableView.java:124)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.put(KeyValueViewImpl.java:216)
> at
> org.apache.ignite.internal.sql.api.ItKevtest.testGetNullable(ItKevtest.java:24)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> Caused by: org.apache.ignite.internal.marshaller.MarshallerException:
> IGN-CMN-65535 TraceId:ef2d9c71-8f2d-4279-99fc-25e8e14ede40 Failed to write
> field [id=0]
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:401)
> at
> org.apache.ignite.internal.marshaller.Marshaller$PojoMarshaller.writeObject(Marshaller.java:274)
> at
> org.apache.ignite.internal.schema.marshaller.reflection.KvMarshallerImpl.marshal(KvMarshallerImpl.java:102)
> at
> org.apache.ignite.internal.table.KeyValueViewImpl.marshal(KeyValueViewImpl.java:522)
> ... 15 more
> Caused by: java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:233)
> at
> java.base/java.lang.invoke.VarHandleBooleans$FieldInstanceReadOnly.get(VarHandleBooleans.java:90)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$VarHandleAccessor.get(FieldAccessor.java:552)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor$BooleanPrimitiveAccessor.write0(FieldAccessor.java:581)
> at
> org.apache.ignite.internal.marshaller.FieldAccessor.write(FieldAccessor.java:399)
> ... 18 more
> {code}
> This error message can be improved to say exactly what is wrong with user
> configuration and how to fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22187) Cluster of 2 or 3 nodes doesn't work if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-22187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Pligin reassigned IGNITE-22187:
Assignee: Aleksandr Polovtsev
> Cluster of 2 or 3 nodes doesn't work if one node is down
>
>
> Key: IGNITE-22187
> URL: https://issues.apache.org/jira/browse/IGNITE-22187
> Project: Ignite
> Issue Type: Bug
> Components: general, jdbc, networking, persistence
>Affects Versions: 3.0.0-beta1
> Environment: The 2 or 3 nodes cluster running locally.
>Reporter: Igor
>Assignee: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
>
> *Steps to reproduce:*
> # Create zone with replication equals to amount of nodes (2 or 3
> corresponding)
> # Create 10 tables inside the zone.
> # Insert 100 rows in every table.
> # Await all tables*partitions*nodes local state is "HEALTHY"
> # Await all tables*partitions*nodes global state is "AVAILABLE"
> # Kill first node with kill -9.
> # Assert all tables*partitions*nodes local state is "HEALTHY"
> # Await all tables*partitions*nodes global state is "READ_ONLY" for 2 nodes
> cluster or "DEGRADED" for 3 nodes cluster,
> # Execute select query using JDBC connecting to the second node (which is
> alive).
> *Expected:*
> Data is returned.
> *Actual:*
> On the step 7 it returns error by REST API:
> {code:java}
> {"title":"Internal Server
> Error","status":500,"code":"IGN-RECOVERY-3","type":null,"detail":"io.netty.channel.AbstractChannel$AnnotatedConnectException:
> Connection refused:
> /172.120.6.2:3344","node":null,"traceId":"2acb52fc-3275-411b-a4de-45f14873f15c","invalidParams":null}{code}
> In the server logs continuous errors:
> {code:java}
> 2024-05-08 10:37:19:796 +0200
> [ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-9][AbstractClientService]
> Fail to connect ClusterFailover3NodesTest_cluster_0, exception:
> java.net.ConnectException.
> 2024-05-08 10:37:19:796 +0200
> [ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-9][ReplicatorGroupImpl]
> Fail to check replicator connection to
> peer=ClusterFailover3NodesTest_cluster_0, replicatorType=Follower.
> 2024-05-08 10:37:19:796 +0200
> [ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-12][AbstractClientService]
> Fail to connect ClusterFailover3NodesTest_cluster_0, exception:
> java.net.ConnectException.
> 2024-05-08 10:37:19:796 +0200
> [ERROR][%ClusterFailover3NodesTest_cluster_1%JRaft-StepDownTimer-12][ReplicatorGroupImpl]
> Fail to check replicator connection to
> peer=ClusterFailover3NodesTest_cluster_0, replicatorType=Follower. {code}
> If skip steps 7 and 8, then the exception on step 9 occurs:
> {code:java}
> java.sql.SQLException: Unable to send fragment
> [targetNode=ClusterFailover3NodesTest_cluster_0, fragmentId=1,
> cause=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: no further information: /192.168.100.5:3344]
> at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111)
> at
> org.gridgain.ai3tests.tests.teststeps.JdbcSteps.executeQuery(JdbcSteps.java:91)
> at
> org.gridgain.ai3tests.tests.failover.ClusterFailoverTestBase.getActualResult(ClusterFailoverTestBase.java:336)
> at
> org.gridgain.ai3tests.tests.failover.ClusterFailoverTestBase.assertDataIsFilledWithoutErrors(ClusterFailoverTestBase.java:154)
> at
> org.gridgain.ai3tests.tests.failover.ClusterFailover3NodesTest.singleKillAndCheckOtherNodeWorks(ClusterFailover3NodesTest.java:96)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21605) C++ 3.0: Pass client time zone to server
[ https://issues.apache.org/jira/browse/IGNITE-21605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846297#comment-17846297 ] Pavel Tupitsyn commented on IGNITE-21605: - [~isapego] looks good to me. > C++ 3.0: Pass client time zone to server > > > Key: IGNITE-21605 > URL: https://issues.apache.org/jira/browse/IGNITE-21605 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Pavel Pereslegin >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Once IGNITE-21551 is implemented, it will be possible to set the time zone in > a user session. > The session time zone is taken into account when calling functions for > obtaining the current time (CURRENT_TIMESTAMP, etc), as well as when > processing a string literal for the 'TIMESTAMP WITH LOCAL TIME ZONE' type. > For this to work correctly, you need to transfer the client's time zone > through the thin client. > p.s. check the TODOs that point to this ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22215) Fix for ThinClientIndexQueryTest#testPageSize
[ https://issues.apache.org/jira/browse/IGNITE-22215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-22215: - Summary: Fix for ThinClientIndexQueryTest#testPageSize (was: Fox for ThinClientIndexQueryTest#testPageSize) > Fix for ThinClientIndexQueryTest#testPageSize > - > > Key: IGNITE-22215 > URL: https://issues.apache.org/jira/browse/IGNITE-22215 > Project: Ignite > Issue Type: Task >Reporter: Oleg Valuyskiy >Assignee: Oleg Valuyskiy >Priority: Minor > Labels: ise > > There is a bug in ThinClientIndexQueryTest#testPageSize where the 'reqs' > collection is always as a wrong class is used for recording next page > requests (GridQueryNextPageRequest instead of GridCacheQueryRequest). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22201) .NET: Use NetArchTest instead of manual parsing
[ https://issues.apache.org/jira/browse/IGNITE-22201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-22201: - Labels: ignite-3 (was: ) > .NET: Use NetArchTest instead of manual parsing > --- > > Key: IGNITE-22201 > URL: https://issues.apache.org/jira/browse/IGNITE-22201 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > [ProjectFilesTests|https://github.com/apache/ignite-3/blob/main/modules/platforms/dotnet/Apache.Ignite.Tests/ProjectFilesTests.cs] > uses primitive parsing to enforce architectural rules. This is fiddly and > not reliable. > We can use [NetArchTest|https://github.com/BenMorris/NetArchTest] instead > (inspired by Java ArchUnit) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22031) .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency
[ https://issues.apache.org/jira/browse/IGNITE-22031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846288#comment-17846288 ] Pavel Tupitsyn commented on IGNITE-22031: - Merged to main: [185e568d4536b686794dc1011d3f9ba561e91d7b|https://github.com/apache/ignite-3/commit/185e568d4536b686794dc1011d3f9ba561e91d7b] > .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency > -- > > Key: IGNITE-22031 > URL: https://issues.apache.org/jira/browse/IGNITE-22031 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Timer-based partition assignment check is not necessary. > *Table.GetPartitionAssignmentAsync* is backed by a cache with a > double-checked locking, and uses a *ValueTask*, so there is no overhead in > case of unchanged assignment - we can call it as often as needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21979) Extend test coverage for SQL F781(Self-referencing operations)
[ https://issues.apache.org/jira/browse/IGNITE-21979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-21979: - Assignee: Maksim Zhuravkov > Extend test coverage for SQL F781(Self-referencing operations) > -- > > Key: IGNITE-21979 > URL: https://issues.apache.org/jira/browse/IGNITE-21979 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Test coverage for SQL F781(Self-referencing operations) is poor. > Let's increase the test coverage. > > ref - subquery/scalar/test_delete_subquery.test > - test/sql/subquery/scalar/test_update_subquery.test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22223) Allow listening for node lifecycle
Vadim Pakhnushev created IGNITE-3:
-
Summary: Allow listening for node lifecycle
Key: IGNITE-3
URL: https://issues.apache.org/jira/browse/IGNITE-3
Project: Ignite
Issue Type: Improvement
Reporter: Vadim Pakhnushev
{{org.apache.ignite.internal.app.LifecycleManager#onStartComplete}} could call
listeners to enable components to do some tasks that are only make sense after
the node joined the cluster.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22185) DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation became flaky on the main
[
https://issues.apache.org/jira/browse/IGNITE-22185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-22185:
Assignee: Vladislav Pyatkov (was: Mirza Aliev)
> DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation
> became flaky on the main
> -
>
> Key: IGNITE-22185
> URL: https://issues.apache.org/jira/browse/IGNITE-22185
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation}}
> started to fail quite often recently.
> There are two possible errors in the logs:
> {noformat}
> java.lang.AssertionError: java.util.concurrent.TimeoutException
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
> at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:195)
> at
> org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:115)
> at
> org.apache.ignite.internal.distributionzones.BaseDistributionZoneManagerTest.createZone(BaseDistributionZoneManagerTest.java:159)
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(DistributionZoneCausalityDataNodesTest.java:627)
> {noformat}
> or
> {noformat}
> org.mockito.exceptions.misusing.UnfinishedStubbingException:
> Unfinished stubbing detected here:
> -> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.blockDataNodesUpdatesInMetaStorage(DistributionZoneCausalityDataNodesTest.java:1593)
> {noformat}
> Need to investigate the problem
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21304) Internal API for restarting partitions
[ https://issues.apache.org/jira/browse/IGNITE-21304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-21304: - Reviewer: Ivan Bessonov > Internal API for restarting partitions > -- > > Key: IGNITE-21304 > URL: https://issues.apache.org/jira/browse/IGNITE-21304 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > API and implementation should be provided for restarting peers in raft groups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21304) Internal API for restarting partitions
[ https://issues.apache.org/jira/browse/IGNITE-21304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-21304: - Fix Version/s: 3.0.0-beta2 > Internal API for restarting partitions > -- > > Key: IGNITE-21304 > URL: https://issues.apache.org/jira/browse/IGNITE-21304 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > API and implementation should be provided for restarting peers in raft groups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22217) Meta storage idempotent invokes: implement idempotent cache cleanup logic
[ https://issues.apache.org/jira/browse/IGNITE-22217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-22217: Assignee: Alexander Lapin > Meta storage idempotent invokes: implement idempotent cache cleanup logic > - > > Key: IGNITE-22217 > URL: https://issues.apache.org/jira/browse/IGNITE-22217 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General context is available in the IGNITE-21881. Specifics related to the > idempotent cache persistency is covered in the IGNITE-22214. Given ticket is > about removing obsolete cache entries from both volatile and persistent > idempotent command caches. > h3. Definition of Done > * Obsolete idempotent cache entries are eventually removed from both > volatile cache and meta storage persistent backup. > h3. Implementation Notes > There's no need to have command result longer than > org.apache.ignite.internal.raft.configuration.RaftConfiguration#responseTimeout > + CLOCK_SKEW. In future we may use MS GC in order to check aforementioned > condition and asynchronously remove obsolete cache entries. For now we may > use any other trigger, like some invoke calls. > It's reasonable to remove persistent obsolete entry prior to removing > corresponding entry from volatile cache for better robustness, thus we will > only have entry in persistent storage if it's available in volatile one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22202) Deal with null when getting storages in IndexBuildController
[ https://issues.apache.org/jira/browse/IGNITE-22202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-22202: Assignee: Denis Chudov > Deal with null when getting storages in IndexBuildController > > > Key: IGNITE-22202 > URL: https://issues.apache.org/jira/browse/IGNITE-22202 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > IGNITE-22191 describes the problem and includes a temporary solution that > needs to be somehow corrected in the current one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22129) Partition, CMG and metastorage should not share threads
[
https://issues.apache.org/jira/browse/IGNITE-22129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-22129:
Assignee: Vladislav Pyatkov
> Partition, CMG and metastorage should not share threads
> ---
>
> Key: IGNITE-22129
> URL: https://issues.apache.org/jira/browse/IGNITE-22129
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> These three subsystems have different purposes. Hence, using the same threads
> might lead to starvation. For the same reason, we already have a separate FMC
> caller disruptor for Metastorage, but other disruptors are still shared.
> {code:java}
> NodeImpl#ownFsmCallerExecutorDisruptorConfig
> {code}
> h3. Definition of done
> At least, all partiton disruptor threads have to be different from the
> threads that are used by Metastorage and CMG.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22118) Explicitly specify pool to execute start/stop on IgniteComponent
[
https://issues.apache.org/jira/browse/IGNITE-22118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-22118:
Assignee: Kirill Sizov
> Explicitly specify pool to execute start/stop on IgniteComponent
>
>
> Key: IGNITE-22118
> URL: https://issues.apache.org/jira/browse/IGNITE-22118
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Sizov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
>
> start/stop methods of {{IgniteComponent}} should be called from specific
> thread pools.
> At the moment start is called from two different threads - some components
> start on _main_ while the others start on _startupExecutor_.
> We need a consistent process of starting and stoping all components.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22031) .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency
[ https://issues.apache.org/jira/browse/IGNITE-22031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846264#comment-17846264 ] Igor Sapego commented on IGNITE-22031: -- Looks good to me. > .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency > -- > > Key: IGNITE-22031 > URL: https://issues.apache.org/jira/browse/IGNITE-22031 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Timer-based partition assignment check is not necessary. > *Table.GetPartitionAssignmentAsync* is backed by a cache with a > double-checked locking, and uses a *ValueTask*, so there is no overhead in > case of unchanged assignment - we can call it as often as needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22185) DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation became flaky on the main
[
https://issues.apache.org/jira/browse/IGNITE-22185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-22185:
-
Epic Link: IGNITE-21389
> DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation
> became flaky on the main
> -
>
> Key: IGNITE-22185
> URL: https://issues.apache.org/jira/browse/IGNITE-22185
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation}}
> started to fail quite often recently.
> There are two possible errors in the logs:
> {noformat}
> java.lang.AssertionError: java.util.concurrent.TimeoutException
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
> at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:195)
> at
> org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.createZone(DistributionZonesTestUtil.java:115)
> at
> org.apache.ignite.internal.distributionzones.BaseDistributionZoneManagerTest.createZone(BaseDistributionZoneManagerTest.java:159)
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(DistributionZoneCausalityDataNodesTest.java:627)
> {noformat}
> or
> {noformat}
> org.mockito.exceptions.misusing.UnfinishedStubbingException:
> Unfinished stubbing detected here:
> -> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.DistributionZoneCausalityDataNodesTest.blockDataNodesUpdatesInMetaStorage(DistributionZoneCausalityDataNodesTest.java:1593)
> {noformat}
> Need to investigate the problem
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20137) testOneNodeRestartWithGap's assert throws TransactionException is failed
[
https://issues.apache.org/jira/browse/IGNITE-20137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20137:
-
Epic Link: IGNITE-21389
> testOneNodeRestartWithGap's assert throws TransactionException is failed
>
>
> Key: IGNITE-20137
> URL: https://issues.apache.org/jira/browse/IGNITE-20137
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> *Description*
> With unchanged code there 2 ways to fail, both in the same assert that waits
> {{TransactionException}} to be thrown:
> # assert returns false because there is no any thrown exception;
> # assert returns false because the caught exception is timeout with
> {{{}PrimaryReplicaAwaitTimeoutException{}}}.
> We could remove the assert and fix the follow line:
> {code:java}
> TableManager tableManager = unwrapTableManager(ignite1.tables());{code}
> {color:#383838}Without unwrapping there will be {{{}ClassCastException{}}}.
> With this 2 changes the test will pass with 100% rate.{color}
>
> *What to fix*
> Probably, the assert should be left, but the issue needs an investigation:
> why there 2 reasons of fail and what exactly do we expect there?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22182) Move snapshop metadata validation to SnapshotMetadataVerificationTask
[
https://issues.apache.org/jira/browse/IGNITE-22182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22182:
--
Description:
In the the snapshot validation, we do some metadata checks within
`IgniteSnapshotManager` instead of dedicated
`SnapshotMetadataVerificationTask`. Like:
{code:java}
if (masterKeyDigest == null && snpMasterKeyDigest != null) {
res.onDone(new SnapshotPartitionsVerifyTaskResult(metas, new
IdleVerifyResultV2(
Collections.singletonMap(cctx.localNode(), new
IllegalArgumentException("Snapshot '" +
meta.snapshotName() + "' has encrypted caches while encryption is
disabled. To " +
"restore this snapshot, start Ignite with configured encryption and
the same " +
"master key.");
return;
}
{code}
Such checks should be moved to the task.
was:
In the the snapshot validation, we do some metaadas checks within
`IgniteSnapshotManager` instead of dedicated
`SnapshotMetadataVerificationTask`. Like:
{code:java}
if (masterKeyDigest == null && snpMasterKeyDigest != null) {
res.onDone(new
SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
Collections.singletonMap(cctx.localNode(), new
IllegalArgumentException("Snapshot '" +
meta.snapshotName() + "' has encrypted
caches while encryption is disabled. To " +
"restore this snapshot, start Ignite with
configured encryption and the same " +
"master key.");
return;
}
{code}
Such checks should be moved to the task.
> Move snapshop metadata validation to SnapshotMetadataVerificationTask
> -
>
> Key: IGNITE-22182
> URL: https://issues.apache.org/jira/browse/IGNITE-22182
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In the the snapshot validation, we do some metadata checks within
> `IgniteSnapshotManager` instead of dedicated
> `SnapshotMetadataVerificationTask`. Like:
> {code:java}
> if (masterKeyDigest == null && snpMasterKeyDigest != null) {
> res.onDone(new SnapshotPartitionsVerifyTaskResult(metas, new
> IdleVerifyResultV2(
> Collections.singletonMap(cctx.localNode(), new
> IllegalArgumentException("Snapshot '" +
> meta.snapshotName() + "' has encrypted caches while encryption is
> disabled. To " +
> "restore this snapshot, start Ignite with configured encryption
> and the same " +
> "master key.");
> return;
> }
> {code}
> Such checks should be moved to the task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22034) ItRebalanceTest#testRebalanceTablesCounterForZone is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-22034:
-
Epic Link: IGNITE-21389
> ItRebalanceTest#testRebalanceTablesCounterForZone is flaky
> --
>
> Key: IGNITE-22034
> URL: https://issues.apache.org/jira/browse/IGNITE-22034
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.rebalance.ItRebalanceTest.waitForTablesCounterInMetastore(ItRebalanceTest.java:261)
> at
> org.apache.ignite.internal.rebalance.ItRebalanceTest.testRebalanceTablesCounterForZone(ItRebalanceTest.java:199)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> {noformat}
> The reason of this NPE is {{lastAssignmentsHolderForLog[0]}} equals {{null}}.
> We have not wait of appier a key in the metastorage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22213) Schema PUBLIC not found for a short time right after start using JDBC
[
https://issues.apache.org/jira/browse/IGNITE-22213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22213:
Labels: ignite-3 (was: )
> Schema PUBLIC not found for a short time right after start using JDBC
> -
>
> Key: IGNITE-22213
> URL: https://issues.apache.org/jira/browse/IGNITE-22213
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Major
> Labels: ignite-3
>
> 1) Start cluster,
> 2) Init cluster,
> 3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color}
> 4) Create table
> Expected result: table successfully created
> Actual result: error
> {noformat}
> java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
> {color:#1d1c1d}After cluster is fully initialized (logical topology meets
> expectations), it fixes.{color}
> {color:#1d1c1d}If the cluster is not ready to process the connection - it
> shouldn't accept it. Or wait until metadata schema available on request
> processing.{color}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22213) Schema PUBLIC not found for a short time right after start using JDBC
[
https://issues.apache.org/jira/browse/IGNITE-22213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22213:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Schema PUBLIC not found for a short time right after start using JDBC
> -
>
> Key: IGNITE-22213
> URL: https://issues.apache.org/jira/browse/IGNITE-22213
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Major
> Labels: ignite-3
>
> 1) Start cluster,
> 2) Init cluster,
> 3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color}
> 4) Create table
> Expected result: table successfully created
> Actual result: error
> {noformat}
> java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
> {color:#1d1c1d}After cluster is fully initialized (logical topology meets
> expectations), it fixes.{color}
> {color:#1d1c1d}If the cluster is not ready to process the connection - it
> shouldn't accept it. Or wait until metadata schema available on request
> processing.{color}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22182) Move snapshop metadata validation to SnapshotMetadataVerificationTask
[
https://issues.apache.org/jira/browse/IGNITE-22182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-22182:
--
Description:
In the the snapshot validation, we do some metaadas checks within
`IgniteSnapshotManager` instead of dedicated
`SnapshotMetadataVerificationTask`. Like:
{code:java}
if (masterKeyDigest == null && snpMasterKeyDigest != null) {
res.onDone(new
SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
Collections.singletonMap(cctx.localNode(), new
IllegalArgumentException("Snapshot '" +
meta.snapshotName() + "' has encrypted
caches while encryption is disabled. To " +
"restore this snapshot, start Ignite with
configured encryption and the same " +
"master key.");
return;
}
{code}
Such checks should be moved to the task.
was:
In the the snapshot validation, we do some metaadas checks within
`IgniteSnapshotManager` instead of dedicated
`SnapshotMetadataVerificationTask`. Like:
{code:java}
if (masterKeyDigest == null && snpMasterKeyDigest != null) {
res.onDone(new
SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
Collections.singletonMap(cctx.localNode(), new
IllegalArgumentException("Snapshot '" +
meta.snapshotName() + "' has encrypted
caches while encryption is disabled. To " +
"restore this snapshot, start Ignite with
configured encryption and the same " +
"master key.");
return;
}
{code}
Suck checks should be moved to the task.
> Move snapshop metadata validation to SnapshotMetadataVerificationTask
> -
>
> Key: IGNITE-22182
> URL: https://issues.apache.org/jira/browse/IGNITE-22182
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In the the snapshot validation, we do some metaadas checks within
> `IgniteSnapshotManager` instead of dedicated
> `SnapshotMetadataVerificationTask`. Like:
> {code:java}
> if (masterKeyDigest == null && snpMasterKeyDigest != null) {
> res.onDone(new
> SnapshotPartitionsVerifyTaskResult(metas, new IdleVerifyResultV2(
> Collections.singletonMap(cctx.localNode(),
> new IllegalArgumentException("Snapshot '" +
> meta.snapshotName() + "' has encrypted
> caches while encryption is disabled. To " +
> "restore this snapshot, start Ignite with
> configured encryption and the same " +
> "master key.");
> return;
> }
> {code}
> Such checks should be moved to the task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20137) testOneNodeRestartWithGap's assert throws TransactionException is failed
[
https://issues.apache.org/jira/browse/IGNITE-20137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-20137:
Assignee: Alexander Lapin
> testOneNodeRestartWithGap's assert throws TransactionException is failed
>
>
> Key: IGNITE-20137
> URL: https://issues.apache.org/jira/browse/IGNITE-20137
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> *Description*
> With unchanged code there 2 ways to fail, both in the same assert that waits
> {{TransactionException}} to be thrown:
> # assert returns false because there is no any thrown exception;
> # assert returns false because the caught exception is timeout with
> {{{}PrimaryReplicaAwaitTimeoutException{}}}.
> We could remove the assert and fix the follow line:
> {code:java}
> TableManager tableManager = unwrapTableManager(ignite1.tables());{code}
> {color:#383838}Without unwrapping there will be {{{}ClassCastException{}}}.
> With this 2 changes the test will pass with 100% rate.{color}
>
> *What to fix*
> Probably, the assert should be left, but the issue needs an investigation:
> why there 2 reasons of fail and what exactly do we expect there?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22204) Sql. Set operation. Incorrect query transformation for a query with limit / offset that uses the same table
[
https://issues.apache.org/jira/browse/IGNITE-22204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846256#comment-17846256
]
Evgeny Stanilovsky commented on IGNITE-22204:
-
pure calcite shows also incorrect results and seems plan :
{code:java}
EnumerableUnion(all=[true])
> EnumerableCalc(expr#0..1=[{inputs}], A=[$t0])
> EnumerableLimit(offset=[1], fetch=[1])
> EnumerableSort(sort0=[$0], dir0=[ASC])
> EnumerableTableScan(table=[[BLANK, TEST]])
> EnumerableCalc(expr#0..1=[{inputs}], A=[$t0])
> EnumerableLimit(offset=[2], fetch=[3])
> EnumerableSort(sort0=[$0], dir0=[ASC])
> EnumerableTableScan(table=[[BLANK, TEST]])
{code}
and returns:
{code:java}
> +---+
> | A |
> +---+
> | 2 |
> | 3 |
> | 4 |
> +---+
{code}
to reproduce with pure calcite: simple modify for example blank.iq and call
CoreQuidemTest#main
> Sql. Set operation. Incorrect query transformation for a query with limit /
> offset that uses the same table
> ---
>
> Key: IGNITE-22204
> URL: https://issues.apache.org/jira/browse/IGNITE-22204
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
>
> Combination of LIMIT / OFFSET and set operator results in incorrect
> transformation of a plan tree:
> {noformat}
> statement ok
> CREATE TABLE test (a INTEGER);
> statement ok
> INSERT INTO test VALUES (1), (2), (3), (4);
> # query 1
> query I rowsort
> SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
>
> 2
> # query 2
> query I rowsort
> SELECT a FROM
> (SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
> ORDER BY a OFFSET 1
> ) t(a)
>
> 4
> # combined query should return 2, 4
> # but it returns 2
> query I rowsort
> SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
> UNION ALL
> SELECT a FROM
> (SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
> ORDER BY a OFFSET 1
> ) t(a)
>
> 2
> 4
> {noformat}
> Query 1
> {noformat}
> SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
> Limit(offset=[1], fetch=[1]), id = 80
> Exchange(distribution=[single]), id = 79
>Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 78
> TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 50
> {noformat}
> Query 2
> {noformat}
> SELECT a FROM
> (SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
> ORDER BY a OFFSET 1
> ) t(a)
> Limit(offset=[1]), id = 201
>Limit(offset=[2], fetch=[3]), id = 200
> Exchange(distribution=[single]), id = 199
>Sort(sort0=[$0], dir0=[ASC], offset=[2], fetch=[3]), id = 198
> TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 168
> {noformat}
> Combine queries using UNION ALL
> {noformat}
> SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 1 OFFSET 1) t(a)
> UNION ALL
> SELECT a FROM
> (SELECT a FROM
> (SELECT a FROM test ORDER BY a LIMIT 3 OFFSET 2) i(a)
> ORDER BY a OFFSET 1
> ) t(a)
> UnionAll(all=[true]), id = 403
> Limit(offset=[1], fetch=[1]), id = 400
> Exchange(distribution=[single]), id = 399 # subtree is duplicated in
> another part of a query
> Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398 #
> TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
> Limit(offset=[1]), id = 402
> Limit(offset=[2], fetch=[3]), id = 401
> Exchange(distribution=[single]), id = 399 # duplicate
> Sort(sort0=[$0], dir0=[ASC], offset=[1], fetch=[1]), id = 398
> TableScan(table=[[PUBLIC, TEST]], requiredColumns=[{0}]), id = 345
> {noformat}
> When tables are different, results are correct.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22222) Move ThreadLocalPartitionCommandsMarshaller to ReplicaManager module with cycle dependency fix
Mikhail Efremov created IGNITE-2:
Summary: Move ThreadLocalPartitionCommandsMarshaller to
ReplicaManager module with cycle dependency fix
Key: IGNITE-2
URL: https://issues.apache.org/jira/browse/IGNITE-2
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Efremov
Assignee: Mikhail Efremov
*Description*
Now the marshaller starts in {{IgniteImpl}} and using only for
{{ReplicaManager}} creation, there is a reason to move it in
{{{}ReplicaManager{}}}'s constructor, but there is cyclic dependency arises.
Also in some places in tests classes like
{{org.apache.ignite.internal.replicator.ItPlacementDriverReplicaSideTest#beforeTest}}
we can't pass or mock this specific marshaller's class.
*Definition of done*
{{ThreadLocalPartitionCommandsMarshaller}} instantiation is moved into
{{ReplicaManager}} and there no any another places of it's instance creation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22205) Java thin 3.0: Reuse SQL API implementations from embedded
[ https://issues.apache.org/jira/browse/IGNITE-22205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846253#comment-17846253 ] Pavel Tupitsyn commented on IGNITE-22205: - Merged to main: [6dc1021e3ee00b8f599a1742bda0456c45f30710|https://github.com/apache/ignite-3/commit/6dc1021e3ee00b8f599a1742bda0456c45f30710] > Java thin 3.0: Reuse SQL API implementations from embedded > -- > > Key: IGNITE-22205 > URL: https://issues.apache.org/jira/browse/IGNITE-22205 > Project: Ignite > Issue Type: Improvement > Components: sql, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > The following classes can be moved to *core* module and reused across client > and embedded APIs: > * StatementImpl > * StatementBuilderImpl > * ResultSetMetadataImpl > * ColumnMetadataImpl > * ColumnOriginImpl -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22188) Add metrics for debugging ItSqlLogicTest
[ https://issues.apache.org/jira/browse/IGNITE-22188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-22188: --- Description: * jvm.gc.CollectionTime (long gauge) * os.LoadAverage (long gauge, LA from the OS) * metastorage.SafeTimeLag (long gauge, number of milliseconds between local HLC and local Metastorage SafeTime) was: * jvm.gc..CollectionCount (long gauge) * jvm.gc..CollectionTime (long gauge) * os.LoadAverage (long gauge, LA from the OS) * metastorage.SafeTimeLag (long gauge, number of milliseconds between local HLC and local Metastorage SafeTime) > Add metrics for debugging ItSqlLogicTest > > > Key: IGNITE-22188 > URL: https://issues.apache.org/jira/browse/IGNITE-22188 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > * jvm.gc.CollectionTime (long gauge) > * os.LoadAverage (long gauge, LA from the OS) > * metastorage.SafeTimeLag (long gauge, number of milliseconds between local > HLC and local Metastorage SafeTime) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22217) Meta storage idempotent invokes: implement idempotent cache cleanup logic
[ https://issues.apache.org/jira/browse/IGNITE-22217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22217: - Description: h3. Motivation General context is available in the IGNITE-21881. Specifics related to the idempotent cache persistency is covered in the IGNITE-22214. Given ticket is about removing obsolete cache entries from both volatile and persistent idempotent command caches. h3. Definition of Done * Obsolete idempotent cache entries are eventually removed from both volatile cache and meta storage persistent backup. h3. Implementation Notes There's no need to have command result longer than org.apache.ignite.internal.raft.configuration.RaftConfiguration#responseTimeout + CLOCK_SKEW. In future we may use MS GC in order to check aforementioned condition and asynchronously remove obsolete cache entries. For now we may use any other trigger, like some invoke calls. It's reasonable to remove persistent obsolete entry prior to removing corresponding entry from volatile cache for better robustness, thus we will only have entry in persistent storage if it's available in volatile one. was: h3. Motivation General context is available in the IGNITE-21881. Specifics related to the idempotent cache persistency is covered in the IGNITE-22214. Given ticket is about removing obsolete cache entries from both volatile and persistent idempotent command caches. h3. Definition of Done * Obsolete idempotent cache entries are eventually removed from both volatile cache and meta storage persistent backup. h3. Implementation Notes > Meta storage idempotent invokes: implement idempotent cache cleanup logic > - > > Key: IGNITE-22217 > URL: https://issues.apache.org/jira/browse/IGNITE-22217 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General context is available in the IGNITE-21881. Specifics related to the > idempotent cache persistency is covered in the IGNITE-22214. Given ticket is > about removing obsolete cache entries from both volatile and persistent > idempotent command caches. > h3. Definition of Done > * Obsolete idempotent cache entries are eventually removed from both > volatile cache and meta storage persistent backup. > h3. Implementation Notes > There's no need to have command result longer than > org.apache.ignite.internal.raft.configuration.RaftConfiguration#responseTimeout > + CLOCK_SKEW. In future we may use MS GC in order to check aforementioned > condition and asynchronously remove obsolete cache entries. For now we may > use any other trigger, like some invoke calls. > It's reasonable to remove persistent obsolete entry prior to removing > corresponding entry from volatile cache for better robustness, thus we will > only have entry in persistent storage if it's available in volatile one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22205) Java thin 3.0: Reuse SQL API implementations from embedded
[ https://issues.apache.org/jira/browse/IGNITE-22205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846238#comment-17846238 ] Igor Sapego commented on IGNITE-22205: -- Looks good to me > Java thin 3.0: Reuse SQL API implementations from embedded > -- > > Key: IGNITE-22205 > URL: https://issues.apache.org/jira/browse/IGNITE-22205 > Project: Ignite > Issue Type: Improvement > Components: sql, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > The following classes can be moved to *core* module and reused across client > and embedded APIs: > * StatementImpl > * StatementBuilderImpl > * ResultSetMetadataImpl > * ColumnMetadataImpl > * ColumnOriginImpl -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22213) Schema PUBLIC not found for a short time right after start using JDBC
[
https://issues.apache.org/jira/browse/IGNITE-22213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak updated IGNITE-22213:
--
Description:
1) Start cluster,
2) Init cluster,
3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color}
4) Create table
Expected result: table successfully created
Actual result: error
{noformat}
java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
at
org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
{color:#1d1c1d}After cluster is fully initialized (logical topology meets
expectations), it fixes.{color}
{color:#1d1c1d}If the cluster is not ready to process the connection - it
shouldn't accept it. Or wait until metadata schema available on request
processing.{color}
was:
1) Start cluster,
2) Init cluster,
3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color}
4) Create table
Expected result: table successfully created
Actual result: error
{noformat}
java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
at
org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
{color:#1d1c1d}After cluster is fully initialized (logical topology meets
expectations), it fixes.{color}
{color:#1d1c1d}If the cluster is not ready to process the connection - it
shouldn't accept it. Or wait until metadata schema available on request
processing.{color}
> Schema PUBLIC not found for a short time right after start using JDBC
> -
>
> Key: IGNITE-22213
> URL: https://issues.apache.org/jira/browse/IGNITE-22213
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Minor
>
> 1) Start cluster,
> 2) Init cluster,
> 3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color}
> 4) Create table
> Expected result: table successfully created
> Actual result: error
> {noformat}
> java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
> {color:#1d1c1d}After cluster is fully initialized (logical topology meets
> expectations), it fixes.{color}
> {color:#1d1c1d}If the cluster is not ready to process the connection - it
> shouldn't accept it. Or wait until metadata schema available on request
> processing.{color}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22213) Schema PUBLIC not found for a short time right after start using JDBC
[
https://issues.apache.org/jira/browse/IGNITE-22213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak updated IGNITE-22213:
--
Priority: Major (was: Minor)
> Schema PUBLIC not found for a short time right after start using JDBC
> -
>
> Key: IGNITE-22213
> URL: https://issues.apache.org/jira/browse/IGNITE-22213
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Major
>
> 1) Start cluster,
> 2) Init cluster,
> 3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color}
> 4) Create table
> Expected result: table successfully created
> Actual result: error
> {noformat}
> java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
> {color:#1d1c1d}After cluster is fully initialized (logical topology meets
> expectations), it fixes.{color}
> {color:#1d1c1d}If the cluster is not ready to process the connection - it
> shouldn't accept it. Or wait until metadata schema available on request
> processing.{color}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22213) Schema PUBLIC not found for a short time right after start using JDBC
[
https://issues.apache.org/jira/browse/IGNITE-22213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak updated IGNITE-22213:
--
Description:
1) Start cluster,
2) Init cluster,
3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color}
4) Create table
Expected result: table successfully created
Actual result: error
{noformat}
java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
at
org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
{color:#1d1c1d}After cluster is fully initialized (logical topology meets
expectations), it fixes.{color}
{color:#1d1c1d}If the cluster is not ready to process the connection - it
shouldn't accept it. Or wait until metadata schema available on request
processing.{color}
was:
1) Start cluster,
2) Activate,
3) Connect using JDBC
4) Create table
Expected result: table successfully created
Actual result: error
{noformat}
java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
at
org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
{color:#1d1c1d}After cluster is fully initialized (logical topology meets
expectations), it fixes.{color}
{color:#1d1c1d}If the cluster is not ready to process the connection - it
shouldn't accept it. Or wait until metadata schema available on request
processing.{color}
> Schema PUBLIC not found for a short time right after start using JDBC
> -
>
> Key: IGNITE-22213
> URL: https://issues.apache.org/jira/browse/IGNITE-22213
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Minor
>
> 1) Start cluster,
> 2) Init cluster,
> 3) {color:#1d1c1d}Without waiting expected topology, connect using JDBC{color}
> 4) Create table
> Expected result: table successfully created
> Actual result: error
> {noformat}
> java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
> {color:#1d1c1d}After cluster is fully initialized (logical topology meets
> expectations), it fixes.{color}
> {color:#1d1c1d}If the cluster is not ready to process the connection - it
> shouldn't accept it. Or wait until metadata schema available on request
> processing.{color}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22213) Schema PUBLIC not found for a short time right after start using JDBC
[
https://issues.apache.org/jira/browse/IGNITE-22213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak updated IGNITE-22213:
--
Description:
1) Start cluster,
2) Activate,
3) Connect using JDBC
4) Create table
Expected result: table successfully created
Actual result: error
{noformat}
java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
at
org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
{color:#1d1c1d}After cluster is fully initialized (logical topology meets
expectations), it fixes.{color}
{color:#1d1c1d}If the cluster is not ready to process the connection - it
shouldn't accept it. Or wait until metadata schema available on request
processing.{color}
was:
1) Start cluster,
2) Activate,
3) Connect using JDBC
4) Create table
Expected result: table successfully created
Actual result: error
{noformat}
java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
at
org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
After a few seconds, it fixes.
If the cluster is not ready to process the connection - it shouldn't accept it.
Or wait until metadata schema available on request processing.
> Schema PUBLIC not found for a short time right after start using JDBC
> -
>
> Key: IGNITE-22213
> URL: https://issues.apache.org/jira/browse/IGNITE-22213
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Priority: Minor
>
> 1) Start cluster,
> 2) Activate,
> 3) Connect using JDBC
> 4) Create table
> Expected result: table successfully created
> Actual result: error
> {noformat}
> java.sql.SQLException: Schema not found [schemaName=PUBLIC] at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111){noformat}
> {color:#1d1c1d}After cluster is fully initialized (logical topology meets
> expectations), it fixes.{color}
> {color:#1d1c1d}If the cluster is not ready to process the connection - it
> shouldn't accept it. Or wait until metadata schema available on request
> processing.{color}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22220) Rename rocksDb field in RocksDbStorageEngineExtensionConfigurationSchema
[
https://issues.apache.org/jira/browse/IGNITE-0?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtsev updated IGNITE-0:
-
Fix Version/s: 3.0.0-beta2
> Rename rocksDb field in RocksDbStorageEngineExtensionConfigurationSchema
>
>
> Key: IGNITE-0
> URL: https://issues.apache.org/jira/browse/IGNITE-0
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a follow-up of https://issues.apache.org/jira/browse/IGNITE-22137,
> looks like some "rocksDb" remnants are still present in the configuration:
> {code:java}
> /**
> * Storages configuration extension for rocksdb storage.
> */
> @ConfigurationExtension
> public class RocksDbStorageEngineExtensionConfigurationSchema extends
> StorageEngineConfigurationSchema {
> @ConfigValue
> public RocksDbStorageEngineConfigurationSchema rocksDb;
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22221) Implement SQL F393 feature (Unicode escapes in literals) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-1: -- Description: Let's support Unicode escapes in literals (F393 SQL feature) and unmute tests. (was: We don't have at all any tests for F393(Unicode escapes in literals) SQL feature. Let's cover it and create tickets to fix them in case find any issues related to the covered area) > Implement SQL F393 feature (Unicode escapes in literals) feature by tests > - > > Key: IGNITE-1 > URL: https://issues.apache.org/jira/browse/IGNITE-1 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Let's support Unicode escapes in literals (F393 SQL feature) and unmute tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22221) Implement SQL F393 feature (Unicode escapes in literals) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-1: -- Epic Link: (was: IGNITE-21915) > Implement SQL F393 feature (Unicode escapes in literals) feature by tests > - > > Key: IGNITE-1 > URL: https://issues.apache.org/jira/browse/IGNITE-1 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for F393(Unicode escapes in literals) SQL > feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22221) Implement SQL F393 feature (Unicode escapes in literals) feature by tests
Andrey Mashenkov created IGNITE-1: - Summary: Implement SQL F393 feature (Unicode escapes in literals) feature by tests Key: IGNITE-1 URL: https://issues.apache.org/jira/browse/IGNITE-1 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov Assignee: Andrey Mashenkov We don't have at all any tests for F393(Unicode escapes in literals) SQL feature. Let's cover it and create tickets to fix them in case find any issues related to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22220) Rename rocksDb field in RocksDbStorageEngineExtensionConfigurationSchema
[
https://issues.apache.org/jira/browse/IGNITE-0?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtsev updated IGNITE-0:
-
Description:
This is a follow-up of https://issues.apache.org/jira/browse/IGNITE-22137,
looks like some "rocksDb" remnants are still present in the configuration:
{code:java}
/**
* Storages configuration extension for rocksdb storage.
*/
@ConfigurationExtension
public class RocksDbStorageEngineExtensionConfigurationSchema extends
StorageEngineConfigurationSchema {
@ConfigValue
public RocksDbStorageEngineConfigurationSchema rocksDb;
}
{code}
was:
This is a follow-up of https://issues.apache.org/jira/browse/IGNITE-22137,
looks like some "rocksDb" remnants are still present in the configuration:
{{{
/**
* Storages configuration extension for rocksdb storage.
*/
@ConfigurationExtension
public class RocksDbStorageEngineExtensionConfigurationSchema extends
StorageEngineConfigurationSchema {
@ConfigValue
public RocksDbStorageEngineConfigurationSchema rocksDb;
}
}}}
> Rename rocksDb field in RocksDbStorageEngineExtensionConfigurationSchema
>
>
> Key: IGNITE-0
> URL: https://issues.apache.org/jira/browse/IGNITE-0
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
>
> This is a follow-up of https://issues.apache.org/jira/browse/IGNITE-22137,
> looks like some "rocksDb" remnants are still present in the configuration:
> {code:java}
> /**
> * Storages configuration extension for rocksdb storage.
> */
> @ConfigurationExtension
> public class RocksDbStorageEngineExtensionConfigurationSchema extends
> StorageEngineConfigurationSchema {
> @ConfigValue
> public RocksDbStorageEngineConfigurationSchema rocksDb;
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22220) Rename rocksDb field in RocksDbStorageEngineExtensionConfigurationSchema
[
https://issues.apache.org/jira/browse/IGNITE-0?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtsev updated IGNITE-0:
-
Description:
This is a follow-up of https://issues.apache.org/jira/browse/IGNITE-22137,
looks like some "rocksDb" remnants are still present in the configuration:
{{{
/**
* Storages configuration extension for rocksdb storage.
*/
@ConfigurationExtension
public class RocksDbStorageEngineExtensionConfigurationSchema extends
StorageEngineConfigurationSchema {
@ConfigValue
public RocksDbStorageEngineConfigurationSchema rocksDb;
}
}}}
was:
This is a follow-up of https://issues.apache.org/jira/browse/IGNITE-22137,
looks like some "rocksDb" remnants are still present in the configuration:
```
/**
* Storages configuration extension for rocksdb storage.
*/
@ConfigurationExtension
public class RocksDbStorageEngineExtensionConfigurationSchema extends
StorageEngineConfigurationSchema {
@ConfigValue
public RocksDbStorageEngineConfigurationSchema rocksDb;
}
```
> Rename rocksDb field in RocksDbStorageEngineExtensionConfigurationSchema
>
>
> Key: IGNITE-0
> URL: https://issues.apache.org/jira/browse/IGNITE-0
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
>
> This is a follow-up of https://issues.apache.org/jira/browse/IGNITE-22137,
> looks like some "rocksDb" remnants are still present in the configuration:
> {{{
> /**
> * Storages configuration extension for rocksdb storage.
> */
> @ConfigurationExtension
> public class RocksDbStorageEngineExtensionConfigurationSchema extends
> StorageEngineConfigurationSchema {
> @ConfigValue
> public RocksDbStorageEngineConfigurationSchema rocksDb;
> }
> }}}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22220) Rename rocksDb field in RocksDbStorageEngineExtensionConfigurationSchema
[
https://issues.apache.org/jira/browse/IGNITE-0?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtsev updated IGNITE-0:
-
Description:
This is a follow-up of https://issues.apache.org/jira/browse/IGNITE-22137,
looks like some "rocksDb" remnants are still present in the configuration:
```
/**
* Storages configuration extension for rocksdb storage.
*/
@ConfigurationExtension
public class RocksDbStorageEngineExtensionConfigurationSchema extends
StorageEngineConfigurationSchema {
@ConfigValue
public RocksDbStorageEngineConfigurationSchema rocksDb;
}
```
> Rename rocksDb field in RocksDbStorageEngineExtensionConfigurationSchema
>
>
> Key: IGNITE-0
> URL: https://issues.apache.org/jira/browse/IGNITE-0
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
>
> This is a follow-up of https://issues.apache.org/jira/browse/IGNITE-22137,
> looks like some "rocksDb" remnants are still present in the configuration:
> ```
> /**
> * Storages configuration extension for rocksdb storage.
> */
> @ConfigurationExtension
> public class RocksDbStorageEngineExtensionConfigurationSchema extends
> StorageEngineConfigurationSchema {
> @ConfigValue
> public RocksDbStorageEngineConfigurationSchema rocksDb;
> }
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22220) Rename rocksDb field in RocksDbStorageEngineExtensionConfigurationSchema
Aleksandr Polovtsev created IGNITE-0: Summary: Rename rocksDb field in RocksDbStorageEngineExtensionConfigurationSchema Key: IGNITE-0 URL: https://issues.apache.org/jira/browse/IGNITE-0 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtsev Assignee: Aleksandr Polovtsev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22219) Remove unused code for hanlding SqlQuery
Maksim Timonin created IGNITE-22219: --- Summary: Remove unused code for hanlding SqlQuery Key: IGNITE-22219 URL: https://issues.apache.org/jira/browse/IGNITE-22219 Project: Ignite Issue Type: Improvement Reporter: Maksim Timonin Assignee: Maksim Timonin SqlQuery uses SqlFieldsQuery pipeline, then code for SqlQuery in cache queries is useless. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22217) Meta storage idempotent invokes: implement idempotent cache cleanup logic
[ https://issues.apache.org/jira/browse/IGNITE-22217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22217: - Description: h3. Motivation General context is available in the IGNITE-21881. Specifics related to the idempotent cache persistency is covered in the IGNITE-22214. Given ticket is about removing obsolete cache entries from both volatile and persistent idempotent command caches. h3. Definition of Done * Obsolete idempotent cache entries are eventually removed from both volatile cache and meta storage persistent backup. h3. Implementation Notes was: h3. Motivation General context is available in the IGNITE-21881. Specifics related to the idempotent cache persistency is covered in the IGNITE-22214. Given ticket is about removing obsolete cache entries from both volatile and persistent idempotent command caches. h3. Definition of Done * Obsolete idempotent cache entries are eventually removed from both volatile cache and meta storage persistent backup. h3. Implementation Notes > Meta storage idempotent invokes: implement idempotent cache cleanup logic > - > > Key: IGNITE-22217 > URL: https://issues.apache.org/jira/browse/IGNITE-22217 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General context is available in the IGNITE-21881. Specifics related to the > idempotent cache persistency is covered in the IGNITE-22214. Given ticket is > about removing obsolete cache entries from both volatile and persistent > idempotent command caches. > h3. Definition of Done > * Obsolete idempotent cache entries are eventually removed from both > volatile cache and meta storage persistent backup. > h3. Implementation Notes > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22217) Meta storage idempotent invokes: implement idempotent cache cleanup logic
[ https://issues.apache.org/jira/browse/IGNITE-22217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22217: - Description: h3. Motivation General context is available in the IGNITE-21881. Specifics related to the idempotent cache persistency is covered in the IGNITE-22214. Given ticket is about removing obsolete cache entries from both volatile and persistent idempotent command caches. h3. Definition of Done * Obsolete idempotent cache entries are eventually removed from both volatile cache and meta storage persistent backup. h3. Implementation Notes was: h3. Motivation General context is available in the IGNITE-21881. Specifics related to the idempotent cache persistency is covered in the IGNITE-22214. Given ticket is about removing obsolete cache entries from both volatile and persistent idempotent command caches. h3. Definition of Done * Obsolete idempotent cache entries are eventually removed from both volatile cache and meta storage persistent backup. h3. Implementation Notes > Meta storage idempotent invokes: implement idempotent cache cleanup logic > - > > Key: IGNITE-22217 > URL: https://issues.apache.org/jira/browse/IGNITE-22217 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General context is available in the IGNITE-21881. Specifics related to the > idempotent cache persistency is covered in the IGNITE-22214. Given ticket is > about removing obsolete cache entries from both volatile and persistent > idempotent command caches. > h3. Definition of Done > * Obsolete idempotent cache entries are eventually removed from both > volatile cache and meta storage persistent backup. > h3. Implementation Notes > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22217) Meta storage idempotent invokes: implement idempotent cache cleanup logic
[ https://issues.apache.org/jira/browse/IGNITE-22217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22217: - Description: h3. Motivation General context is available in the IGNITE-21881. Specifics related to the idempotent cache persistency is covered in the IGNITE-22214. Given ticket is about removing obsolete cache entries from both volatile and persistent idempotent command caches. h3. Definition of Done * Obsolete idempotent cache entries are eventually removed from both volatile cache and meta storage persistent backup. h3. Implementation Notes was: h3. Motivation General context is available in the IGNITE-21881. Specifics related to the idempotent cache persistency is covered in the IGNITE-22214. Given ticket is about removing obsolete cache entries from both volatile and persistent idempotent command caches. h3. Definition of Done * Obsolete idempotent cache entries are removed from both volatile cache and meta storage persistent backup. h3. Implementation Notes > Meta storage idempotent invokes: implement idempotent cache cleanup logic > - > > Key: IGNITE-22217 > URL: https://issues.apache.org/jira/browse/IGNITE-22217 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General context is available in the IGNITE-21881. Specifics related to the > idempotent cache persistency is covered in the IGNITE-22214. Given ticket is > about removing obsolete cache entries from both volatile and persistent > idempotent command caches. > h3. Definition of Done > * Obsolete idempotent cache entries are eventually removed from both > volatile cache and meta storage persistent backup. > h3. Implementation Notes > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22217) Meta storage idempotent invokes: implement idempotent cache cleanup logic
[ https://issues.apache.org/jira/browse/IGNITE-22217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22217: - Description: h3. Motivation General context is available in the IGNITE-21881. Specifics related to the idempotent cache persistency is covered in the [IGNITE-22214|https://issues.apache.org/jira/browse/IGNITE-22214]. Given ticket is about removing obsolete cache entries from both volatile and persistent idempotent command caches. h3. Definition of Done * Obsolete idempotent cache entries are removed from both volatile cache and meta storage persistent backup. was: h3. Motivation General context is available in the IGNITE-21881. > Meta storage idempotent invokes: implement idempotent cache cleanup logic > - > > Key: IGNITE-22217 > URL: https://issues.apache.org/jira/browse/IGNITE-22217 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General context is available in the IGNITE-21881. Specifics related to the > idempotent cache persistency is covered in the > [IGNITE-22214|https://issues.apache.org/jira/browse/IGNITE-22214]. Given > ticket is about removing obsolete cache entries from both volatile and > persistent idempotent command caches. > h3. Definition of Done > * Obsolete idempotent cache entries are removed from both volatile cache and > meta storage persistent backup. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22217) Meta storage idempotent invokes: implement idempotent cache cleanup logic
[ https://issues.apache.org/jira/browse/IGNITE-22217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22217: - Description: h3. Motivation General context is available in the IGNITE-21881. Specifics related to the idempotent cache persistency is covered in the IGNITE-22214. Given ticket is about removing obsolete cache entries from both volatile and persistent idempotent command caches. h3. Definition of Done * Obsolete idempotent cache entries are removed from both volatile cache and meta storage persistent backup. h3. Implementation Notes was: h3. Motivation General context is available in the IGNITE-21881. Specifics related to the idempotent cache persistency is covered in the [IGNITE-22214|https://issues.apache.org/jira/browse/IGNITE-22214]. Given ticket is about removing obsolete cache entries from both volatile and persistent idempotent command caches. h3. Definition of Done * Obsolete idempotent cache entries are removed from both volatile cache and meta storage persistent backup. > Meta storage idempotent invokes: implement idempotent cache cleanup logic > - > > Key: IGNITE-22217 > URL: https://issues.apache.org/jira/browse/IGNITE-22217 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General context is available in the IGNITE-21881. Specifics related to the > idempotent cache persistency is covered in the IGNITE-22214. Given ticket is > about removing obsolete cache entries from both volatile and persistent > idempotent command caches. > h3. Definition of Done > * Obsolete idempotent cache entries are removed from both volatile cache and > meta storage persistent backup. > h3. Implementation Notes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22217) Meta storage idempotent invokes: implement idempotent cache cleanup logic
[ https://issues.apache.org/jira/browse/IGNITE-22217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22217: - Description: h3. Motivation General context is available in the IGNITE-21881. > Meta storage idempotent invokes: implement idempotent cache cleanup logic > - > > Key: IGNITE-22217 > URL: https://issues.apache.org/jira/browse/IGNITE-22217 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General context is available in the IGNITE-21881. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22217) Meta storage idempotent invokes: implement idempotent cache cleanup logic
Alexander Lapin created IGNITE-22217: Summary: Meta storage idempotent invokes: implement idempotent cache cleanup logic Key: IGNITE-22217 URL: https://issues.apache.org/jira/browse/IGNITE-22217 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22217) Meta storage idempotent invokes: implement idempotent cache cleanup logic
[ https://issues.apache.org/jira/browse/IGNITE-22217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22217: - Ignite Flags: (was: Docs Required,Release Notes Required) > Meta storage idempotent invokes: implement idempotent cache cleanup logic > - > > Key: IGNITE-22217 > URL: https://issues.apache.org/jira/browse/IGNITE-22217 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22214) Meta storage idempotent invokes: persist and recovery idempotent command cache
[ https://issues.apache.org/jira/browse/IGNITE-22214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin reassigned IGNITE-22214: Assignee: Alexander Lapin > Meta storage idempotent invokes: persist and recovery idempotent command cache > -- > > Key: IGNITE-22214 > URL: https://issues.apache.org/jira/browse/IGNITE-22214 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General context is available in the IGNITE-21881. Within given ticket it's > required to persist and restore idempotent command cache in order to return > original command result after raft node restart. > h3. Definition of Done > * Original command result is returned after raft node restart. > h3. Implementation Notes > Seems that the easiest way to implement the desired solution and get all > snapshot consistency aspects out of the box is to store each idempotent cache > entry in dedicated MS key where key itself will be > commandId with the original command result as > value. I don't think that we need to persist command startTime, we may > recalculate it on cache initialisation - it's all matter of optimisation and > not correctness. Meaning that it's safe to have value in cache a little bit > longer than it's actually required. > The only non-trivial part here is to consistently update storage with both > command specific keys and idempotent cache meta ones. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22214) Meta storage idempotent invokes: persist and recovery idempotent command cache
[ https://issues.apache.org/jira/browse/IGNITE-22214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22214: - Description: h3. Motivation General context is available in the IGNITE-21881. Within given ticket it's required to persist and restore idempotent command cache in order to return original command result after raft node restart. h3. Definition of Done * Original command result is returned after raft node restart. h3. Implementation Notes Seems that the easiest way to implement the desired solution and get all snapshot consistency aspects out of the box is to store each idempotent cache entry in dedicated MS key where key itself will be commandId with the original command result as value. I don't think that we need to persist command startTime, we may recalculate it on cache initialisation - it's all matter of optimisation and not correctness. Meaning that it's safe to have value in cache a little bit longer than it's actually required. The only non-trivial part here is to consistently update storage with both command specific keys and idempotent cache meta ones. was: h3. Motivation General context is available in the IGNITE-21881. Within given ticket it's required to persist and restore idempotent command cache in order to return original command result after raft node restart. h3. Definition of Done * Original command result is returned after raft node restart. h3. Implementation Notes Seems that the easiest way to implement the desired solution and get all snapshot consistency aspects out of the box is to store each idempotent cache entry in dedicated MS key where key itself will be commandId with the original command result as value. I don't think that we need to persist command startTime, we may recalculate it on cache initialisation - it's all matter of optimisation and not correctness. Meaning that it's safe to have value in cache a little bit longer than it's actually required. > Meta storage idempotent invokes: persist and recovery idempotent command cache > -- > > Key: IGNITE-22214 > URL: https://issues.apache.org/jira/browse/IGNITE-22214 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General context is available in the IGNITE-21881. Within given ticket it's > required to persist and restore idempotent command cache in order to return > original command result after raft node restart. > h3. Definition of Done > * Original command result is returned after raft node restart. > h3. Implementation Notes > Seems that the easiest way to implement the desired solution and get all > snapshot consistency aspects out of the box is to store each idempotent cache > entry in dedicated MS key where key itself will be > commandId with the original command result as > value. I don't think that we need to persist command startTime, we may > recalculate it on cache initialisation - it's all matter of optimisation and > not correctness. Meaning that it's safe to have value in cache a little bit > longer than it's actually required. > The only non-trivial part here is to consistently update storage with both > command specific keys and idempotent cache meta ones. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22216) Remove the GridCacheQueryInfo#all property
Oleg Valuyskiy created IGNITE-22216: --- Summary: Remove the GridCacheQueryInfo#all property Key: IGNITE-22216 URL: https://issues.apache.org/jira/browse/IGNITE-22216 Project: Ignite Issue Type: Task Reporter: Oleg Valuyskiy Assignee: Oleg Valuyskiy The GridCacheQueryInfo#all property doesn't serve any real purpose but makes some of the code where it is used rather confusing. Therefore it is advised to remove the 'all' property from the GridCacheQueryInfo class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22214) Meta storage idempotent invokes: persist and recovery idempotent command cache
[ https://issues.apache.org/jira/browse/IGNITE-22214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22214: - Description: h3. Motivation General context is available in the IGNITE-21881. Within given ticket it's required to persist and restore idempotent command cache in order to return original command result after raft node restart. h3. Definition of Done * Original command result is returned after raft node restart. h3. Implementation Notes Seems that the easiest way to implement the desired solution and get all snapshot consistency aspects out of the box is to store each idempotent cache entry in dedicated MS key where key itself will be commandId with the original command result as value. I don't think that we need to persist command startTime, we may recalculate it on cache initialisation - it's all matter of optimisation and not correctness. Meaning that it's safe to have value in cache a little bit longer than it's actually required. was: h3. Motivation General context is available in the [IGNITE-21881|https://issues.apache.org/jira/browse/IGNITE-21881]. Within given ticket it's requ > Meta storage idempotent invokes: persist and recovery idempotent command cache > -- > > Key: IGNITE-22214 > URL: https://issues.apache.org/jira/browse/IGNITE-22214 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General context is available in the IGNITE-21881. Within given ticket it's > required to persist and restore idempotent command cache in order to return > original command result after raft node restart. > h3. Definition of Done > * Original command result is returned after raft node restart. > h3. Implementation Notes > Seems that the easiest way to implement the desired solution and get all > snapshot consistency aspects out of the box is to store each idempotent cache > entry in dedicated MS key where key itself will be > commandId with the original command result as > value. I don't think that we need to persist command startTime, we may > recalculate it on cache initialisation - it's all matter of optimisation and > not correctness. Meaning that it's safe to have value in cache a little bit > longer than it's actually required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
