[jira] [Reopened] (IGNITE-21499) Removal of MvccSnapshot
[ https://issues.apache.org/jira/browse/IGNITE-21499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov reopened IGNITE-21499: > Removal of MvccSnapshot > --- > > Key: IGNITE-21499 > URL: https://issues.apache.org/jira/browse/IGNITE-21499 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21499) Removal of MvccSnapshot
[ https://issues.apache.org/jira/browse/IGNITE-21499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov resolved IGNITE-21499. Resolution: Duplicate > Removal of MvccSnapshot > --- > > Key: IGNITE-21499 > URL: https://issues.apache.org/jira/browse/IGNITE-21499 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IGNITE-21499) Removal of MvccSnapshot
[ https://issues.apache.org/jira/browse/IGNITE-21499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov closed IGNITE-21499. -- > Removal of MvccSnapshot > --- > > Key: IGNITE-21499 > URL: https://issues.apache.org/jira/browse/IGNITE-21499 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21499) Removal of MvccSnapshot
[ https://issues.apache.org/jira/browse/IGNITE-21499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-21499: --- Parent: (was: IGNITE-13871) Issue Type: Task (was: Sub-task) > Removal of MvccSnapshot > --- > > Key: IGNITE-21499 > URL: https://issues.apache.org/jira/browse/IGNITE-21499 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21499) Removal of MvccSnapshot
[ https://issues.apache.org/jira/browse/IGNITE-21499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov resolved IGNITE-21499. Resolution: Duplicate > Removal of MvccSnapshot > --- > > Key: IGNITE-21499 > URL: https://issues.apache.org/jira/browse/IGNITE-21499 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-21499) Removal of MvccSnapshot
[ https://issues.apache.org/jira/browse/IGNITE-21499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov reopened IGNITE-21499: > Removal of MvccSnapshot > --- > > Key: IGNITE-21499 > URL: https://issues.apache.org/jira/browse/IGNITE-21499 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22115) Data collocation: single Primary, single Raft
Alexander Lapin created IGNITE-22115: Summary: Data collocation: single Primary, single Raft Key: IGNITE-22115 URL: https://issues.apache.org/jira/browse/IGNITE-22115 Project: Ignite Issue Type: Epic Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22096) Spring 6 support for ignite spring extensions
[ https://issues.apache.org/jira/browse/IGNITE-22096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-22096: - Description: This epic is about spring 6 support for ignite extensions. Spring Boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications because extensions are based on Spring 5. Most of them should work fine in Spring 6 apps, but we may find ourselves on thin ice. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring-based ignite extensions to spring 6. The upgrade will affect modules which currently don't work in the spring 6 environment(basically, where the API is broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. The project will support both options, spring 6 modules will be enabled only when JDK 17 is used. The main build will be with JDK 17 because it covers all modules. # Use maven.compiler.release=8 for parent pom. We should use the lowest target possible. # If the spring module don't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to the compatibility test, the module should be built only with JDK 17, otherwise, tests will fail. But maven.compiler.release can be 8. # For updated modules use a new versioning approach. Use the same major and minor for spring extension as the corresponding spring module is used. For example, If spring-session-core is updated to 3.2.2, the spring-session-ext version should be 3.2.x, where x is the revision number. # If we update the module to spring 6 and we need a fix for the previous module version(which is based on spring 5), we can apply the fix to the master first, create a release branch(checkout from the previous spring 5 release) and cherry-pick fix. was: This epic is about spring 6 support for ignite extensions. Spring Boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications because extensions are based on Spring 5. Most of them should work fine in Spring 6 apps, but we may find ourselves on thin ice. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring-based ignite extensions to spring 6. The upgrade will affect modules which currently don't work in the spring 6 environment(basically, where the API is broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. The project will support both options, spring 6 modules will be enabled only when JDK 17 is used. The main build will be with JDK 17 because it covers all modules. # Use maven.compiler.release=8 for parent pom. We should use the lowest target possible. # If the spring module don't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to the compatibility test, the module should be built only with JDK 17, otherwise, tests will fail. But maven.compiler.release can be 8. # For updated modules use a new versioning approach. Use the same major and minor for spring extension as the corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, the spring-session-ext version should be 3.2.x, where x is the revision number. # If we update the module to spring 6 and we need a fix for the previous module version(which is based on spring 5), we can apply the fix to the master first, create a release branch(checkout from the previous spring 5 release) and cherry-pick fix. > Spring 6 support for ignite spring extensions > - > > Key: IGNITE-22096 > URL: https://issues.apache.org/jira/browse/IGNITE-22096 > Project: Ignite > Issue Type: Epic >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > > This epic is about spring 6 support for ignite extensions. > Spring Boot 3 and Spring 6 users may have difficulties using ignite spring > extensions in their applications because extensions are based on Spring 5. > Most of them
[jira] [Updated] (IGNITE-22104) Documentation of Custom Metrics
[ https://issues.apache.org/jira/browse/IGNITE-22104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-22104: -- Fix Version/s: 2.17 > Documentation of Custom Metrics > --- > > Key: IGNITE-22104 > URL: https://issues.apache.org/jira/browse/IGNITE-22104 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.17 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 1h > Remaining Estimate: 0h > > New Custom Metric feature should be documented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22114) NullPointerException when restarting a node few times in a row
Andrey Khitrin created IGNITE-22114:
---
Summary: NullPointerException when restarting a node few times in
a row
Key: IGNITE-22114
URL: https://issues.apache.org/jira/browse/IGNITE-22114
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin
Steps to reproduce:
1. Start a 3-node cluster (`node-1`, `node-2`, `node-3`)
2. Run some load on it (read and write)
3. Shutdown a single node, wait some time, start it again
4. After a little time (say, 30 seconds) shutdown the same node again, wait
some time, start it again
In my case, an issue was reproduced on commit
`d593e6487aa36a806bab075d19c8b831ca096a28` (2024-04-24 IGNITE-2124) on the 2nd
restart of `node-3`.
Expected results: node starts without error.
Actual results: NPE in `ignite3-startup.log`.
{code}
Error when starting the node: org.apache.ignite.lang.IgniteException:
IGN-CMN-65535 TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe Unable to start [node=node-3]
java.util.concurrent.ExecutionException:
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe Unable to start [node=node-3]
at
java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
at
org.apache.ignite.internal.app.IgniteRunner.main(IgniteRunner.java:74)
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe Unable to start [node=node-3]
at
org.apache.ignite.internal.app.IgnitionImpl.handleStartException(IgnitionImpl.java:224)
at
org.apache.ignite.internal.app.IgnitionImpl.lambda$doStart$1(IgnitionImpl.java:205)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
at
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:840)
at
java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at
java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: java.util.concurrent.CompletionException:
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe Unable to start [node=node-3]
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:932)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
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:829)
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe Unable to start [node=node-3]
at
org.apache.ignite.internal.app.IgniteImpl.handleStartException(IgniteImpl.java:1185)
at
org.apache.ignite.internal.app.IgniteImpl.lambda$start$27(IgniteImpl.java:1129)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
... 5 more
Caused by: java.util.concurrent.CompletionException:
java.lang.NullPointerException
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
[jira] [Commented] (IGNITE-22105) Add busy lock to ClusterStateStorage
[
https://issues.apache.org/jira/browse/IGNITE-22105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840813#comment-17840813
]
Roman Puchkovskiy commented on IGNITE-22105:
The patch looks good to me
> Add busy lock to ClusterStateStorage
>
>
> Key: IGNITE-22105
> URL: https://issues.apache.org/jira/browse/IGNITE-22105
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtsev
>Assignee: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {{ClusterStateStorage}} is a full-blown IgniteComponent, but doesn't have a
> busy lock that will signal the users that the component has been stopped.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22109) [SQL] TPC-H q4 query hangs with sc=0.1
[
https://issues.apache.org/jira/browse/IGNITE-22109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-22109:
---
Description:
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time
h1. Actual result
The benchmark hangs for hours on
[Q4|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q4.java]
query:
{noformat}
SELECT
o_orderpriority,
COUNT(*) AS order_count
FROM
orders
WHERE
o_orderdate >= ?::date
AND o_orderdate < ?::date + INTERVAL '3' MONTH
AND EXISTS
(
SELECT
*
FROM
lineitem
WHERE
l_orderkey = o_orderkey
AND l_commitdate < l_receiptdate
)
GROUP BY
o_orderpriority
ORDER BY
o_orderpriority{noformat}
was:
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time
h1. Actual result
The benchmark hangs for hours on
[Q4|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q4.java]
query:
{noformat}
SELECT
o_orderpriority,
COUNT(*) AS order_count
FROM
orders
WHERE
o_orderdate >= DATE ?
AND o_orderdate < DATE ? + INTERVAL '3' MONTH
AND EXISTS
(
SELECT
*
FROM
lineitem
WHERE
l_orderkey = o_orderkey
AND l_commitdate < l_receiptdate
)
GROUP BY
o_orderpriority
ORDER BY
o_orderpriority {noformat}
> [SQL] TPC-H q4 query hangs with sc=0.1
> --
>
> Key: IGNITE-22109
> URL: https://issues.apache.org/jira/browse/IGNITE-22109
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3, ignite3_performance
>
> Benchmark:
> [https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
>
> h1. Setup
> * 1 server node
> * TPC-H with scale factor = 0.1
> h1. Steps
> # Start an Ignite node
> # Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
> preload data
> # Observe via the benchbase log that the data was successfully loaded
> # Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
> run the benchmark
> h1. Expected result
> The benchmark finishes after warmup + duration time
> h1. Actual result
> The benchmark hangs for hours on
> [Q4|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q4.java]
> query:
>
> {noformat}
> SELECT
> o_orderpriority,
> COUNT(*) AS order_count
> FROM
> orders
> WHERE
> o_orderdate >= ?::date
> AND o_orderdate < ?::date + INTERVAL '3' MONTH
> AND EXISTS
> (
> SELECT
> *
> FROM
> lineitem
> WHERE
> l_orderkey = o_orderkey
> AND l_commitdate < l_receiptdate
> )
> GROUP BY
> o_orderpriority
> ORDER BY
> o_orderpriority{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19082) Catalog. Cleanup dead code.
[ https://issues.apache.org/jira/browse/IGNITE-19082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-19082: - Assignee: Maksim Zhuravkov > Catalog. Cleanup dead code. > --- > > Key: IGNITE-19082 > URL: https://issues.apache.org/jira/browse/IGNITE-19082 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Let's > * ensure Catalog is used by default as a single schema management point by > TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. > * drop schema related code from configuration. > * drop outdated code from TableManager, IndexManager, SqlSchemaManager, > SchemaRegistry. > * make a PR for merging feature branch to main (if applicable). > * ensure there are end-to-end tests for the cases (if applicable) described > in CatalogServiceSelfTest. Also drop InternalSchemaTest. > * Let’s remove using/keeping schema name instaed of schema id (NewIndexEntry > class as example) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22113) Remove unused MetaStorageManagerImpl getAnd<> methods
[ https://issues.apache.org/jira/browse/IGNITE-22113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin reassigned IGNITE-22113: Assignee: Kirill Sizov > Remove unused MetaStorageManagerImpl getAnd<> methods > - > > Key: IGNITE-22113 > URL: https://issues.apache.org/jira/browse/IGNITE-22113 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > > h3. Motivation > There is bunch of getAnd<> methods in MetaStorageManagerImpl which aren't > used. Moreover they aren't even declared in the MetaStorageManager interface. > Worth mentioning, that their support will require additional efforts due to > idempotency issue. > All in all, It's better to remove them. > h3. Definition of Done > * Unused getAnd<> are removed from MetaStorageManagerImpl, > MetastorageService along with corresponding tests etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22113) Remove unused MetaStorageManagerImpl getAnd<> methods
[
https://issues.apache.org/jira/browse/IGNITE-22113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-22113:
-
Description:
h3. Motivation
There is bunch of getAnd<> methods in MetaStorageManagerImpl which aren't used.
Moreover they aren't even declared in the MetaStorageManager interface. Worth
mentioning, that their support will require additional efforts due to
idempotency issue.
All in all, It's better to remove them.
h3. Definition of Done
* Unused getAnd<> are removed from MetaStorageManagerImpl, MetastorageService
along with corresponding tests etc.
was:
h3. Motivation
There is bunch of {{getAnd<>}} methods in {{MetaStorageManagerImpl}} which
aren't used. Moreover they aren't even declared in the {{MetaStorageManager}}
interface. Worth mentioning, that their support will require additional efforts
due to idempotency issue.
All in all, It's better to remove them.
h3. Definition of Done
* Unused {{getAnd<>}} are removed from {{MetaStorageManagerImpl,
}}{{MetastorageService }}along with corresponding tests etc.{{{}{}}}
> Remove unused MetaStorageManagerImpl getAnd<> methods
> -
>
> Key: IGNITE-22113
> URL: https://issues.apache.org/jira/browse/IGNITE-22113
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
>
> h3. Motivation
> There is bunch of getAnd<> methods in MetaStorageManagerImpl which aren't
> used. Moreover they aren't even declared in the MetaStorageManager interface.
> Worth mentioning, that their support will require additional efforts due to
> idempotency issue.
> All in all, It's better to remove them.
> h3. Definition of Done
> * Unused getAnd<> are removed from MetaStorageManagerImpl,
> MetastorageService along with corresponding tests etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22113) Remove unused MetaStorageManagerImpl getAnd<> methods
[ https://issues.apache.org/jira/browse/IGNITE-22113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22113: - Labels: ignite-3 (was: ) > Remove unused MetaStorageManagerImpl getAnd<> methods > - > > Key: IGNITE-22113 > URL: https://issues.apache.org/jira/browse/IGNITE-22113 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > There is bunch of getAnd<> methods in MetaStorageManagerImpl which aren't > used. Moreover they aren't even declared in the MetaStorageManager interface. > Worth mentioning, that their support will require additional efforts due to > idempotency issue. > All in all, It's better to remove them. > h3. Definition of Done > * Unused getAnd<> are removed from MetaStorageManagerImpl, > MetastorageService along with corresponding tests etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22113) Remove unused MetaStorageManagerImpl getAnd<> methods
[
https://issues.apache.org/jira/browse/IGNITE-22113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-22113:
-
Summary: Remove unused MetaStorageManagerImpl getAnd<> methods (was:
Remove unused MetaStorageManagerImpl getAnd<> methods)
> Remove unused MetaStorageManagerImpl getAnd<> methods
> -
>
> Key: IGNITE-22113
> URL: https://issues.apache.org/jira/browse/IGNITE-22113
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
>
> h3. Motivation
> There is bunch of {{getAnd<>}} methods in {{MetaStorageManagerImpl}} which
> aren't used. Moreover they aren't even declared in the {{MetaStorageManager}}
> interface. Worth mentioning, that their support will require additional
> efforts due to idempotency issue.
> All in all, It's better to remove them.
> h3. Definition of Done
> * Unused {{getAnd<>}} are removed from {{MetaStorageManagerImpl,
> }}{{MetastorageService }}along with corresponding tests etc.{{{}{}}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22113) Remove unused MetaStorageManagerImpl getAnd<> methods
Alexander Lapin created IGNITE-22113:
Summary: Remove unused MetaStorageManagerImpl getAnd<> methods
Key: IGNITE-22113
URL: https://issues.apache.org/jira/browse/IGNITE-22113
Project: Ignite
Issue Type: Improvement
Reporter: Alexander Lapin
h3. Motivation
There is bunch of {{getAnd<>}} methods in {{MetaStorageManagerImpl}} which
aren't used. Moreover they aren't even declared in the {{MetaStorageManager}}
interface. Worth mentioning, that their support will require additional efforts
due to idempotency issue.
All in all, It's better to remove them.
h3. Definition of Done
* Unused {{getAnd<>}} are removed from {{MetaStorageManagerImpl,
}}{{MetastorageService }}along with corresponding tests etc.{{{}{}}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22112) [SQL] TPC-H q9 query with sc=0.1 takes long time
[
https://issues.apache.org/jira/browse/IGNITE-22112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-22112:
---
Description:
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time in about the same time as
other requests.
h1. Actual result
The
[Q9|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q9.java]
query has significantly longer execution time. For example, it may take 10
minutes, while the rest queries take ~1-15 seconds.
{noformat}
SELECT
nation,
o_year,
SUM(amount) AS sum_profit
FROM
(
SELECT
n_name AS nation,
EXTRACT(YEAR
FROM
o_orderdate) AS o_year,
l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity AS
amount
FROM
part,
supplier,
lineitem,
partsupp,
orders,
nation
WHERE
s_suppkey = l_suppkey
AND ps_suppkey = l_suppkey
AND ps_partkey = l_partkey
AND p_partkey = l_partkey
AND o_orderkey = l_orderkey
AND s_nationkey = n_nationkey
AND p_name LIKE ?
)
AS profit
GROUP BY
nation,
o_year
ORDER BY
nation,
o_year DESC{noformat}
was:
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time
h1. Actual result
The benchmark hangs for hours on
[Q21|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q21.java]
query:
{noformat}
SELECT
s_name,
COUNT(*) AS numwait
FROM
supplier,
lineitem l1,
orders,
nation
WHERE
s_suppkey = l1.l_suppkey
AND o_orderkey = l1.l_orderkey
AND o_orderstatus = 'F'
AND l1.l_receiptdate > l1.l_commitdate
AND EXISTS
(
SELECT
*
FROM
lineitem l2
WHERE
l2.l_orderkey = l1.l_orderkey
AND l2.l_suppkey <> l1.l_suppkey
)
AND NOT EXISTS
(
SELECT
*
FROM
lineitem l3
WHERE
l3.l_orderkey = l1.l_orderkey
AND l3.l_suppkey <> l1.l_suppkey
AND l3.l_receiptdate > l3.l_commitdate
)
AND s_nationkey = n_nationkey
AND n_name = ?
GROUP BY
s_name
ORDER BY
numwait DESC,
s_name LIMIT 100{noformat}
> [SQL] TPC-H q9 query with sc=0.1 takes long time
>
>
> Key: IGNITE-22112
> URL: https://issues.apache.org/jira/browse/IGNITE-22112
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3, ignite3_performance
>
> Benchmark:
> [https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
>
> h1. Setup
> * 1 server node
> * TPC-H with scale factor = 0.1
> h1. Steps
> # Start an Ignite node
> # Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
> preload data
> # Observe via the benchbase log that the data was successfully loaded
> # Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
> run the benchmark
> h1. Expected result
> The benchmark finishes after warmup + duration time in about the same time as
> other requests.
> h1. Actual result
> The
> [Q9|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q9.java]
> query has significantly longer execution time. For example, it may take 10
> minutes, while the rest queries take ~1-15 seconds.
> {noformat}
> SELECT
> nation,
> o_year,
> SUM(amount) AS sum_profit
> FROM
> (
> SELECT
> n_name AS nation,
> EXTRACT(YEAR
> FROM
> o_orderdate) AS o_year,
> l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity AS
> amount
> FROM
> part,
> supplier,
> lineitem,
> partsupp,
>
[jira] [Created] (IGNITE-22112) [SQL] TPC-H q9 query with sc=0.1 takes long time
Nikita Sivkov created IGNITE-22112:
--
Summary: [SQL] TPC-H q9 query with sc=0.1 takes long time
Key: IGNITE-22112
URL: https://issues.apache.org/jira/browse/IGNITE-22112
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Nikita Sivkov
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time
h1. Actual result
The benchmark hangs for hours on
[Q21|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q21.java]
query:
{noformat}
SELECT
s_name,
COUNT(*) AS numwait
FROM
supplier,
lineitem l1,
orders,
nation
WHERE
s_suppkey = l1.l_suppkey
AND o_orderkey = l1.l_orderkey
AND o_orderstatus = 'F'
AND l1.l_receiptdate > l1.l_commitdate
AND EXISTS
(
SELECT
*
FROM
lineitem l2
WHERE
l2.l_orderkey = l1.l_orderkey
AND l2.l_suppkey <> l1.l_suppkey
)
AND NOT EXISTS
(
SELECT
*
FROM
lineitem l3
WHERE
l3.l_orderkey = l1.l_orderkey
AND l3.l_suppkey <> l1.l_suppkey
AND l3.l_receiptdate > l3.l_commitdate
)
AND s_nationkey = n_nationkey
AND n_name = ?
GROUP BY
s_name
ORDER BY
numwait DESC,
s_name LIMIT 100{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22111) [SQL] TPC-H q21 query hangs with sc=0.1
[
https://issues.apache.org/jira/browse/IGNITE-22111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-22111:
---
Description:
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time
h1. Actual result
The benchmark hangs for hours on
[Q21|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q21.java]
query:
{noformat}
SELECT
s_name,
COUNT(*) AS numwait
FROM
supplier,
lineitem l1,
orders,
nation
WHERE
s_suppkey = l1.l_suppkey
AND o_orderkey = l1.l_orderkey
AND o_orderstatus = 'F'
AND l1.l_receiptdate > l1.l_commitdate
AND EXISTS
(
SELECT
*
FROM
lineitem l2
WHERE
l2.l_orderkey = l1.l_orderkey
AND l2.l_suppkey <> l1.l_suppkey
)
AND NOT EXISTS
(
SELECT
*
FROM
lineitem l3
WHERE
l3.l_orderkey = l1.l_orderkey
AND l3.l_suppkey <> l1.l_suppkey
AND l3.l_receiptdate > l3.l_commitdate
)
AND s_nationkey = n_nationkey
AND n_name = ?
GROUP BY
s_name
ORDER BY
numwait DESC,
s_name LIMIT 100{noformat}
was:
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time
h1. Actual result
The benchmark hangs for hours on
[Q16|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q16.java]
query:
{noformat}
SELECT
p_brand,
p_type,
p_size,
COUNT(DISTINCT ps_suppkey) AS supplier_cnt
FROM
partsupp,
part
WHERE
p_partkey = ps_partkey
AND p_brand <> ?
AND p_type NOT LIKE ?
AND p_size IN (?, ?, ?, ?, ?, ?, ?, ?)
AND ps_suppkey NOT IN
(
SELECT
s_suppkey
FROM
supplier
WHERE
s_comment LIKE '%Customer%Complaints%'
)
GROUP BY
p_brand,
p_type,
p_size
ORDER BY
supplier_cnt DESC,
p_brand,
p_type,
p_size{noformat}
> [SQL] TPC-H q21 query hangs with sc=0.1
> ---
>
> Key: IGNITE-22111
> URL: https://issues.apache.org/jira/browse/IGNITE-22111
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3, ignite3_performance
>
> Benchmark:
> [https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
>
> h1. Setup
> * 1 server node
> * TPC-H with scale factor = 0.1
> h1. Steps
> # Start an Ignite node
> # Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
> preload data
> # Observe via the benchbase log that the data was successfully loaded
> # Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
> run the benchmark
> h1. Expected result
> The benchmark finishes after warmup + duration time
> h1. Actual result
> The benchmark hangs for hours on
> [Q21|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q21.java]
> query:
>
> {noformat}
> SELECT
> s_name,
> COUNT(*) AS numwait
> FROM
> supplier,
> lineitem l1,
> orders,
> nation
> WHERE
> s_suppkey = l1.l_suppkey
> AND o_orderkey = l1.l_orderkey
> AND o_orderstatus = 'F'
> AND l1.l_receiptdate > l1.l_commitdate
> AND EXISTS
> (
> SELECT
> *
> FROM
> lineitem l2
> WHERE
> l2.l_orderkey = l1.l_orderkey
> AND l2.l_suppkey <> l1.l_suppkey
> )
> AND NOT EXISTS
> (
> SELECT
> *
> FROM
> lineitem l3
> WHERE
> l3.l_orderkey = l1.l_orderkey
> AND l3.l_suppkey <> l1.l_suppkey
> AND l3.l_receiptdate > l3.l_commitdate
> )
> AND s_nationkey = n_nationkey
> AND n_name = ?
> GROUP BY
> s_name
> ORDER BY
> numwait DESC,
> s_name LIMIT 100{noformat}
--
This message was sent by
[jira] [Updated] (IGNITE-22110) [SQL] TPC-H q16 query hangs with sc=0.1
[
https://issues.apache.org/jira/browse/IGNITE-22110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-22110:
---
Summary: [SQL] TPC-H q16 query hangs with sc=0.1 (was: CLONE - [SQL] TPC-H
q16 query hangs with sc=0.1)
> [SQL] TPC-H q16 query hangs with sc=0.1
> ---
>
> Key: IGNITE-22110
> URL: https://issues.apache.org/jira/browse/IGNITE-22110
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3, ignite3_performance
>
> Benchmark:
> [https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
>
> h1. Setup
> * 1 server node
> * TPC-H with scale factor = 0.1
> h1. Steps
> # Start an Ignite node
> # Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
> preload data
> # Observe via the benchbase log that the data was successfully loaded
> # Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
> run the benchmark
> h1. Expected result
> The benchmark finishes after warmup + duration time
> h1. Actual result
> The benchmark hangs for hours on
> [Q16|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q16.java]
> query:
>
> {noformat}
> SELECT
> p_brand,
> p_type,
> p_size,
> COUNT(DISTINCT ps_suppkey) AS supplier_cnt
> FROM
> partsupp,
> part
> WHERE
> p_partkey = ps_partkey
> AND p_brand <> ?
> AND p_type NOT LIKE ?
> AND p_size IN (?, ?, ?, ?, ?, ?, ?, ?)
> AND ps_suppkey NOT IN
> (
> SELECT
> s_suppkey
> FROM
> supplier
> WHERE
> s_comment LIKE '%Customer%Complaints%'
> )
> GROUP BY
> p_brand,
> p_type,
> p_size
> ORDER BY
> supplier_cnt DESC,
> p_brand,
> p_type,
> p_size{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22110) CLONE - [SQL] TPC-H q16 query hangs with sc=0.1
[
https://issues.apache.org/jira/browse/IGNITE-22110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov updated IGNITE-22110:
---
Description:
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time
h1. Actual result
The benchmark hangs for hours on
[Q16|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q16.java]
query:
{noformat}
SELECT
p_brand,
p_type,
p_size,
COUNT(DISTINCT ps_suppkey) AS supplier_cnt
FROM
partsupp,
part
WHERE
p_partkey = ps_partkey
AND p_brand <> ?
AND p_type NOT LIKE ?
AND p_size IN (?, ?, ?, ?, ?, ?, ?, ?)
AND ps_suppkey NOT IN
(
SELECT
s_suppkey
FROM
supplier
WHERE
s_comment LIKE '%Customer%Complaints%'
)
GROUP BY
p_brand,
p_type,
p_size
ORDER BY
supplier_cnt DESC,
p_brand,
p_type,
p_size{noformat}
was:
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time
h1. Actual result
The benchmark hangs for hours on
[Q4|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q4.java]
query:
{noformat}
SELECT
o_orderpriority,
COUNT(*) AS order_count
FROM
orders
WHERE
o_orderdate >= DATE ?
AND o_orderdate < DATE ? + INTERVAL '3' MONTH
AND EXISTS
(
SELECT
*
FROM
lineitem
WHERE
l_orderkey = o_orderkey
AND l_commitdate < l_receiptdate
)
GROUP BY
o_orderpriority
ORDER BY
o_orderpriority {noformat}
> CLONE - [SQL] TPC-H q16 query hangs with sc=0.1
> ---
>
> Key: IGNITE-22110
> URL: https://issues.apache.org/jira/browse/IGNITE-22110
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3, ignite3_performance
>
> Benchmark:
> [https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
>
> h1. Setup
> * 1 server node
> * TPC-H with scale factor = 0.1
> h1. Steps
> # Start an Ignite node
> # Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
> preload data
> # Observe via the benchbase log that the data was successfully loaded
> # Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
> run the benchmark
> h1. Expected result
> The benchmark finishes after warmup + duration time
> h1. Actual result
> The benchmark hangs for hours on
> [Q16|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q16.java]
> query:
>
> {noformat}
> SELECT
> p_brand,
> p_type,
> p_size,
> COUNT(DISTINCT ps_suppkey) AS supplier_cnt
> FROM
> partsupp,
> part
> WHERE
> p_partkey = ps_partkey
> AND p_brand <> ?
> AND p_type NOT LIKE ?
> AND p_size IN (?, ?, ?, ?, ?, ?, ?, ?)
> AND ps_suppkey NOT IN
> (
> SELECT
> s_suppkey
> FROM
> supplier
> WHERE
> s_comment LIKE '%Customer%Complaints%'
> )
> GROUP BY
> p_brand,
> p_type,
> p_size
> ORDER BY
> supplier_cnt DESC,
> p_brand,
> p_type,
> p_size{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22111) [SQL] TPC-H q21 query hangs with sc=0.1
Nikita Sivkov created IGNITE-22111:
--
Summary: [SQL] TPC-H q21 query hangs with sc=0.1
Key: IGNITE-22111
URL: https://issues.apache.org/jira/browse/IGNITE-22111
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Nikita Sivkov
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time
h1. Actual result
The benchmark hangs for hours on
[Q16|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q16.java]
query:
{noformat}
SELECT
p_brand,
p_type,
p_size,
COUNT(DISTINCT ps_suppkey) AS supplier_cnt
FROM
partsupp,
part
WHERE
p_partkey = ps_partkey
AND p_brand <> ?
AND p_type NOT LIKE ?
AND p_size IN (?, ?, ?, ?, ?, ?, ?, ?)
AND ps_suppkey NOT IN
(
SELECT
s_suppkey
FROM
supplier
WHERE
s_comment LIKE '%Customer%Complaints%'
)
GROUP BY
p_brand,
p_type,
p_size
ORDER BY
supplier_cnt DESC,
p_brand,
p_type,
p_size{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22110) CLONE - [SQL] TPC-H q16 query hangs with sc=0.1
Nikita Sivkov created IGNITE-22110:
--
Summary: CLONE - [SQL] TPC-H q16 query hangs with sc=0.1
Key: IGNITE-22110
URL: https://issues.apache.org/jira/browse/IGNITE-22110
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Nikita Sivkov
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time
h1. Actual result
The benchmark hangs for hours on
[Q4|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q4.java]
query:
{noformat}
SELECT
o_orderpriority,
COUNT(*) AS order_count
FROM
orders
WHERE
o_orderdate >= DATE ?
AND o_orderdate < DATE ? + INTERVAL '3' MONTH
AND EXISTS
(
SELECT
*
FROM
lineitem
WHERE
l_orderkey = o_orderkey
AND l_commitdate < l_receiptdate
)
GROUP BY
o_orderpriority
ORDER BY
o_orderpriority {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22109) [SQL] TPC-H q4 query hangs with sc=0.1
Nikita Sivkov created IGNITE-22109:
--
Summary: [SQL] TPC-H q4 query hangs with sc=0.1
Key: IGNITE-22109
URL: https://issues.apache.org/jira/browse/IGNITE-22109
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Nikita Sivkov
Benchmark:
[https://github.com/cmu-db/benchbase/tree/main/src/main/java/com/oltpbenchmark/benchmarks/tpch]
h1. Setup
* 1 server node
* TPC-H with scale factor = 0.1
h1. Steps
# Start an Ignite node
# Run benchbase with {{-s 1 --create=true --load=true --execute=false}} to
preload data
# Observe via the benchbase log that the data was successfully loaded
# Run {{benchbase with -s 1 --create=false --load=false --execute=true}} to
run the benchmark
h1. Expected result
The benchmark finishes after warmup + duration time
h1. Actual result
The benchmark hangs for hours on
[Q4|https://github.com/cmu-db/benchbase/blob/main/src/main/java/com/oltpbenchmark/benchmarks/tpch/procedures/Q4.java]
query:
{noformat}
SELECT
o_orderpriority,
COUNT(*) AS order_count
FROM
orders
WHERE
o_orderdate >= DATE ?
AND o_orderdate < DATE ? + INTERVAL '3' MONTH
AND EXISTS
(
SELECT
*
FROM
lineitem
WHERE
l_orderkey = o_orderkey
AND l_commitdate < l_receiptdate
)
GROUP BY
o_orderpriority
ORDER BY
o_orderpriority {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-18379) Sql. Insertions failed with "Replication is timed out".
[
https://issues.apache.org/jira/browse/IGNITE-18379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich resolved IGNITE-18379.
-
Resolution: Cannot Reproduce
> Sql. Insertions failed with "Replication is timed out".
> ---
>
> Key: IGNITE-18379
> URL: https://issues.apache.org/jira/browse/IGNITE-18379
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Near sql will fail with :
> {noformat}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:2768796b-10d7-4c8f-8faf-b86ae9779660 Error at:
> (test_order_same_value.test_slow_ignore:72). Statement: Statement
> [queries=[INSERT INTO integers SELECT * FROM integers], expected=OK]
> at
> org.apache.ignite.internal.sqllogic.SqlScriptRunner$Statement.execute(SqlScriptRunner.java:460)
> at
> org.apache.ignite.internal.sqllogic.SqlScriptRunner.run(SqlScriptRunner.java:153)
> at
> org.junit.jupiter.api.AssertTimeout.lambda$assertTimeoutPreemptively$2(AssertTimeout.java:102)
> at
> org.junit.jupiter.api.AssertTimeout.lambda$assertTimeoutPreemptively$4(AssertTimeout.java:138)
> 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:829)
> Caused by: org.apache.ignite.tx.TransactionException: IGN-REP-3
> TraceId:c3fb1ef4-14cd-4943-8f97-eb035d9f2ed6 IGN-REP-3
> TraceId:c3fb1ef4-14cd-4943-8f97-eb035d9f2ed6 Replication is timed out
> [replicaGrpId=6debc582-3ad7-4350-856d-f6bfb379c3ee_part_0]
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:277)
> at org.apache.ignite.sql.Session.execute(Session.java:59)
> at
> org.apache.ignite.internal.sqllogic.SqlScriptRunner.sql(SqlScriptRunner.java:171)
> at
> org.apache.ignite.internal.sqllogic.SqlScriptRunner$Statement.execute(SqlScriptRunner.java:453)
> ... 7 more
> Caused by: org.apache.ignite.tx.TransactionException: IGN-REP-3
> TraceId:c3fb1ef4-14cd-4943-8f97-eb035d9f2ed6 Replication is timed out
> [replicaGrpId=6debc582-3ad7-4350-856d-f6bfb379c3ee_part_0]
> at
> org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$0(ExceptionUtils.java:346)
> at
> org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:429)
> at
> org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:346)
> at
> org.apache.ignite.internal.tx.impl.IgniteAbstractTransactionImpl.commit(IgniteAbstractTransactionImpl.java:74)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:82)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.flush(AsyncRootNode.java:224)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.end(AsyncRootNode.java:134)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:196)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:154)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode.push(TableScanNode.java:200)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode$SubscriberImpl.lambda$onComplete$2(TableScanNode.java:271)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:306)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
> ... 3 more
> Caused by: java.util.concurrent.ExecutionException:
>
[jira] [Updated] (IGNITE-22096) Spring 6 support for ignite spring extensions
[ https://issues.apache.org/jira/browse/IGNITE-22096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-22096: - Description: This epic is about spring 6 support for ignite extensions. Spring Boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications because extensions are based on Spring 5. Most of them should work fine in Spring 6 apps, but we may find ourselves on thin ice. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring-based ignite extensions to spring 6. The upgrade will affect modules which currently don't work in the spring 6 environment(basically, where the API is broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. The project will support both options, spring 6 modules will be enabled only when JDK 17 is used. The main build will be with JDK 17 because it covers all modules. # Use maven.compiler.release=8 for parent pom. We should use the lowest target possible. # If the spring module don't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to the compatibility test, the module should be built only with JDK 17, otherwise, tests will fail. But maven.compiler.release can be 8. # For updated modules use a new versioning approach. Use the same major and minor for spring extension as the corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, the spring-session-ext version should be 3.2.x, where x is the revision number. # If we update the module to spring 6 and we need a fix for the previous module version(which is based on spring 5), we can apply the fix to the master first, create a release branch(checkout from the previous spring 5 release) and cherry-pick fix. was: This epic is about spring 6 support for ignite extensions. Spring Boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications because extensions are based on Spring 5. Most of them should work fine in Spring 6 apps, but we may find ourselves on thin ice. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring-based ignite extensions to spring 6. The upgrade will affect modules which currently don't work in the spring 6 environment(basically, where the API is broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. The project will support both options, spring 6 modules will be enabled only when JDK 17 is used. The main build will be with JDK 17 because it covers all modules. # Use maven.compiler.release=8 for parent pom. We should use the lowest target possible. # If the spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to the compatibility test, the module should be built only with JDK 17, otherwise, tests will fail. But maven.compiler.release can be 8. # For updated modules use a new versioning approach. Use the same major and minor for spring extension as the corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, the spring-session-ext version should be 3.2.x, where x is the revision number. # If we update the module to spring 6 and we need a fix for the previous module version(which is based on spring 5), we can apply the fix to the master first, create a release branch(checkout from the previous spring 5 release) and cherry-pick fix. > Spring 6 support for ignite spring extensions > - > > Key: IGNITE-22096 > URL: https://issues.apache.org/jira/browse/IGNITE-22096 > Project: Ignite > Issue Type: Epic >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > > This epic is about spring 6 support for ignite extensions. > Spring Boot 3 and Spring 6 users may have difficulties using ignite spring > extensions in their applications because extensions are based on Spring 5. > Most of them
[jira] [Updated] (IGNITE-22096) Spring 6 support for ignite spring extensions
[ https://issues.apache.org/jira/browse/IGNITE-22096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-22096: - Description: This epic is about spring 6 support for ignite extensions. Spring Boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications because extensions are based on Spring 5. Most of them should work fine in Spring 6 apps, but we may find ourselves on thin ice. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring-based ignite extensions to spring 6. The upgrade will affect modules which currently don't work in the spring 6 environment(basically, where the API is broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. The project will support both options, spring 6 modules will be enabled only when JDK 17 is used. The main build will be with JDK 17 because it covers all modules. # Use maven.compiler.release=8 for parent pom. We should use the lowest target possible. # If the spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to the compatibility test, the module should be built only with JDK 17, otherwise, tests will fail. But maven.compiler.release can be 8. # For updated modules use a new versioning approach. Use the same major and minor for spring extension as the corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, the spring-session-ext version should be 3.2.x, where x is the revision number. # If we update the module to spring 6 and we need a fix for the previous module version(which is based on spring 5), we can apply the fix to the master first, create a release branch(checkout from the previous spring 5 release) and cherry-pick fix. was: This epic is about spring 6 support for ignite extensions. Spring Boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications because extensions are based on Spring 5. Most of them should work fine in Spring 6 apps, but we may find ourselves on thin ice. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring-based ignite extensions to spring 6. The upgrade will affect modules which currently don't work in the spring 6 environment(basically, where the API is broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. The project will support both options, spring 6 modules will be enabled only when JDK 17 is used. The main build will be with JDK 17 because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If the spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to the compatibility test, the module should be built only with JDK 17, otherwise, tests will fail. But maven.compiler.release can be 8. # For updated modules use a new versioning approach. Use the same major and minor for spring extension as the corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, the spring-session-ext version should be 3.2.x, where x is the revision number. # If we update the module to spring 6 and we need a fix for the previous module version(which is based on spring 5), we can apply the fix to the master first, create a release branch(checkout from the previous spring 5 release) and cherry-pick fix. > Spring 6 support for ignite spring extensions > - > > Key: IGNITE-22096 > URL: https://issues.apache.org/jira/browse/IGNITE-22096 > Project: Ignite > Issue Type: Epic >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > > This epic is about spring 6 support for ignite extensions. > Spring Boot 3 and Spring 6 users may have difficulties using ignite spring > extensions in their applications because extensions are based on Spring 5. > Most of them should work fine in Spring 6 apps, but we may
[jira] [Updated] (IGNITE-22096) Spring 6 support for ignite spring extensions
[ https://issues.apache.org/jira/browse/IGNITE-22096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-22096: - Description: This epic is about spring 6 support for ignite extensions. Spring Boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications because extensions are based on Spring 5. Most of them should work fine in Spring 6 apps, but we may find ourselves on thin ice. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring-based ignite extensions to spring 6. The upgrade will affect modules which won't work in the spring 6 environment(basically, where the API was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. The project will support both options, spring 6 modules will be enabled only when JDK 17 is used. The main build will be with JDK 17 because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If the spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to the compatibility test, the module should be built only with JDK 17, otherwise, tests will fail. But maven.compiler.release can be 8. # For updated modules use a new versioning approach. Use the same major and minor for spring extension as the corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, the spring-session-ext version should be 3.2.x, where x is the revision number. # If we update the module to spring 6 and we need a fix for the previous module version(which is based on spring 5), we can apply the fix to the master first, create a release branch(checkout from the previous spring 5 release) and cherry-pick fix. was: This epic is about spring 6 support for ignite extensions. Spring Boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications because extensions are based on Spring 5. Most of them should work fine in Spring 6 apps, but we may find ourselves on thin ice with this approach. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring-based ignite extensions to spring 6. The upgrade will affect modules which won't work in the spring 6 environment(basically, where the API was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. The project will support both options, spring 6 modules will be enabled only when JDK 17 is used. The main build will be with JDK 17 because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If the spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to the compatibility test, the module should be built only with JDK 17, otherwise, tests will fail. But maven.compiler.release can be 8. # For updated modules use a new versioning approach. Use the same major and minor for spring extension as the corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, the spring-session-ext version should be 3.2.x, where x is the revision number. # If we update the module to spring 6 and we need a fix for the previous module version(which is based on spring 5), we can apply the fix to the master first, create a release branch(checkout from the previous spring 5 release) and cherry-pick fix. > Spring 6 support for ignite spring extensions > - > > Key: IGNITE-22096 > URL: https://issues.apache.org/jira/browse/IGNITE-22096 > Project: Ignite > Issue Type: Epic >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > > This epic is about spring 6 support for ignite extensions. > Spring Boot 3 and Spring 6 users may have difficulties using ignite spring > extensions in their applications because extensions are based on Spring 5. > Most of them should work fine in Spring 6 apps, but we may find ourselves on > thin ice. > For some
[jira] [Updated] (IGNITE-22096) Spring 6 support for ignite spring extensions
[ https://issues.apache.org/jira/browse/IGNITE-22096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-22096: - Description: This epic is about spring 6 support for ignite extensions. Spring Boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications because extensions are based on Spring 5. Most of them should work fine in Spring 6 apps, but we may find ourselves on thin ice. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring-based ignite extensions to spring 6. The upgrade will affect modules which currently don't work in the spring 6 environment(basically, where the API is broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. The project will support both options, spring 6 modules will be enabled only when JDK 17 is used. The main build will be with JDK 17 because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If the spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to the compatibility test, the module should be built only with JDK 17, otherwise, tests will fail. But maven.compiler.release can be 8. # For updated modules use a new versioning approach. Use the same major and minor for spring extension as the corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, the spring-session-ext version should be 3.2.x, where x is the revision number. # If we update the module to spring 6 and we need a fix for the previous module version(which is based on spring 5), we can apply the fix to the master first, create a release branch(checkout from the previous spring 5 release) and cherry-pick fix. was: This epic is about spring 6 support for ignite extensions. Spring Boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications because extensions are based on Spring 5. Most of them should work fine in Spring 6 apps, but we may find ourselves on thin ice. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring-based ignite extensions to spring 6. The upgrade will affect modules which won't work in the spring 6 environment(basically, where the API was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. The project will support both options, spring 6 modules will be enabled only when JDK 17 is used. The main build will be with JDK 17 because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If the spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to the compatibility test, the module should be built only with JDK 17, otherwise, tests will fail. But maven.compiler.release can be 8. # For updated modules use a new versioning approach. Use the same major and minor for spring extension as the corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, the spring-session-ext version should be 3.2.x, where x is the revision number. # If we update the module to spring 6 and we need a fix for the previous module version(which is based on spring 5), we can apply the fix to the master first, create a release branch(checkout from the previous spring 5 release) and cherry-pick fix. > Spring 6 support for ignite spring extensions > - > > Key: IGNITE-22096 > URL: https://issues.apache.org/jira/browse/IGNITE-22096 > Project: Ignite > Issue Type: Epic >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > > This epic is about spring 6 support for ignite extensions. > Spring Boot 3 and Spring 6 users may have difficulties using ignite spring > extensions in their applications because extensions are based on Spring 5. > Most of them should work fine in Spring 6 apps, but we may find ourselves on > thin ice. > For some spring
[jira] [Updated] (IGNITE-22096) Spring 6 support for ignite spring extensions
[ https://issues.apache.org/jira/browse/IGNITE-22096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-22096: - Description: This epic is about spring 6 support for ignite extensions. Spring Boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications because extensions are based on Spring 5. Most of them should work fine in Spring 6 apps, but we may find ourselves on thin ice with this approach. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring-based ignite extensions to spring 6. The upgrade will affect modules which won't work in the spring 6 environment(basically, where the API was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. The project will support both options, spring 6 modules will be enabled only when JDK 17 is used. The main build will be with JDK 17 because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If the spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to the compatibility test, the module should be built only with JDK 17, otherwise, tests will fail. But maven.compiler.release can be 8. # For updated modules use a new versioning approach. Use the same major and minor for spring extension as the corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, the spring-session-ext version should be 3.2.x, where x is the revision number. # If we update the module to spring 6 and we need a fix for the previous module version(which is based on spring 5), we can apply the fix to the master first, create a release branch(checkout from the previous spring 5 release) and cherry-pick fix. was: This epic is about spring 6 support for ignite extensions. Spring boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications, because extensions based on spring 5. Actually, most of them should work fine in spring 6 apps, but we may find ourselves on thin ice with this approach. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring based ignite extensions to spring 6. The upgrade will affect modules which won't work in spring 6 environment(basically, where api was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. Project will support both options, sprint 6 modules will be enabled only when jdk 17 is used. The main build will be with jdk 17, because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to compatibility test, the module should be build only with JDK 17, otherwise tests will fail. But maven.compiler.release can be 8. # For updated modules use new versioning approach. Use the same major and minor for spring extension as corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, spring-session-ext version should be 3.2.x, where x is revision number. # If we update module to spring 6 and we need fix for previous module version(which is based on spring 5), we can apply fix to master first, create release branch(checkout from previous spring 5 release) and cherry pick fix. > Spring 6 support for ignite spring extensions > - > > Key: IGNITE-22096 > URL: https://issues.apache.org/jira/browse/IGNITE-22096 > Project: Ignite > Issue Type: Epic >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > > This epic is about spring 6 support for ignite extensions. > Spring Boot 3 and Spring 6 users may have difficulties using ignite spring > extensions in their applications because extensions are based on Spring 5. > Most of them should work fine in Spring 6 apps, but we may find ourselves on > thin ice with this approach. > For some spring modules
[jira] [Updated] (IGNITE-22096) Spring 6 support for ignite spring extensions
[ https://issues.apache.org/jira/browse/IGNITE-22096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-22096: - Description: This epic is about spring 6 support for ignite extensions. Spring boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications, because extensions based on spring 5. Actually, most of them should work fine in spring 6 apps, but we may find ourselves on thin ice with this approach. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring based ignite extensions to spring 6. The upgrade will affect modules which won't work in spring 6 environment(basically, where api was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. Project will support both options, sprint 6 modules will be enabled only when jdk 17 is used. The main build will be with jdk 17, because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to compatibility test, the module should be build only with JDK 17, otherwise tests will fail. But maven.compiler.release can be 8. # For updated modules use new versioning approach. Use the same major and minor for spring extension as corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, spring-session-ext version should be 3.2.x, where x is revision number. # If we update module to spring 6 and we need fix for previous module version(which is based on spring 5), we can apply fix to master first, create release branch(checkout from previous spring 5 release) and cherry pick fix. was: This epic is about spring 6 support for ignite extensions. Spring boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications, because extensions based on spring 5. Actually, most of them should work fine in spring 6 apps, but we may find ourselves on thin ice with this approach. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring based ignite extensions to spring 6. The upgrade will affect modules which won't work in spring 6 environment(basically, where api was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. Project will support both options, sprint 6 modules will be enabled only when jdk 17 is used. The main build will be with jdk 17, because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to compatibility test, this module should be build only with JDK 17, otherwise tests will fail. But maven.compiler.release can be 8. # For updated modules use new versioning approach. Use the same major and minor for spring extension as corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, spring-session-ext version should be 3.2.x, where x is revision number. > Spring 6 support for ignite spring extensions > - > > Key: IGNITE-22096 > URL: https://issues.apache.org/jira/browse/IGNITE-22096 > Project: Ignite > Issue Type: Epic >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > > This epic is about spring 6 support for ignite extensions. > Spring boot 3 and Spring 6 users may have difficulties using ignite spring > extensions in their applications, because extensions based on spring 5. > Actually, most of them should work fine in spring 6 apps, but we may find > ourselves on thin ice with this approach. > For some spring modules like spring-data-commons and spring-session-core, > Spring has finished spring 5 support in Nov 2023. For other modules(and > spring-core) support ends in Aug 2024. > The proposal is to upgrade spring based ignite extensions to spring 6. The > upgrade will affect modules
[jira] [Updated] (IGNITE-22105) Add busy lock to ClusterStateStorage
[
https://issues.apache.org/jira/browse/IGNITE-22105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtsev updated IGNITE-22105:
-
Description: {{ClusterStateStorage}} is a full-blown IgniteComponent, but
doesn't have a busy lock that will signal the users that the component has been
stopped.
> Add busy lock to ClusterStateStorage
>
>
> Key: IGNITE-22105
> URL: https://issues.apache.org/jira/browse/IGNITE-22105
> 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
>
> {{ClusterStateStorage}} is a full-blown IgniteComponent, but doesn't have a
> busy lock that will signal the users that the component has been stopped.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22105) Add busy lock to ClusterStateStorage
[ https://issues.apache.org/jira/browse/IGNITE-22105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtsev updated IGNITE-22105: - Summary: Add busy lock to ClusterStateStorage (was: Add logging for CMG state access) > Add busy lock to ClusterStateStorage > > > Key: IGNITE-22105 > URL: https://issues.apache.org/jira/browse/IGNITE-22105 > 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 message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22091) CLI for disaster recovery: partition states
[
https://issues.apache.org/jira/browse/IGNITE-22091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Shergalis updated IGNITE-22091:
---
Description:
{code:java}
ignite cluster partition-states --cluster-url [--local [--nodes
] | --global] [--zones ] [--partitions ]
[--plain]
{code}
Output for local:
|Node name|Table name|Partition ID|State|
|node_name|TABLE_NAME|1|HEALTHY|
For global:
|Table name|Partition ID|State|
|TABLE_NAME|1|HEALTHY|
was:
{code:java}
ignite cluster partition-states [--local [--nodes ] | --global]
[--zones ] [--partitions ] [--plain]
{code}
Output for local:
|Node name|Table name|Partition ID|State|
|node_name|TABLE_NAME|1|HEALTHY|
For global:
|Table name|Partition ID|State|
|TABLE_NAME|1|HEALTHY|
> CLI for disaster recovery: partition states
> ---
>
> Key: IGNITE-22091
> URL: https://issues.apache.org/jira/browse/IGNITE-22091
> Project: Ignite
> Issue Type: Task
>Reporter: Philipp Shergalis
>Assignee: Philipp Shergalis
>Priority: Major
> Labels: ignite-3
>
>
> {code:java}
> ignite cluster partition-states --cluster-url [--local [--nodes
> ] | --global] [--zones ] [--partitions ]
> [--plain]
> {code}
>
> Output for local:
> |Node name|Table name|Partition ID|State|
> |node_name|TABLE_NAME|1|HEALTHY|
>
> For global:
> |Table name|Partition ID|State|
> |TABLE_NAME|1|HEALTHY|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21881) Deal with retry send metastorage raft commands after a timeout
[ https://issues.apache.org/jira/browse/IGNITE-21881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21881: - Description: As a result of the analysis and reproduction of IGNITE-21142, it was found that the metastorage raft command can be re-sent if it does not time out, which may not be good and lead to hidden negative consequences, such as in IGNITE-21142. Here we need to find out the reasons for this decision (with re-try by timeout) and understand what to do next. I think we should use an infinite timeout. As a result of the analysis and reproduction of IGNITE-21142, it was found that the metastorage raft command can be re-sent if it does not time out, which may not be good and lead to hidden negative consequences, such as in IGNITE-21142. Here we need to find out the reasons for this decision (with re-try by timeout) and understand what to do next. I think we should use an infinite timeout. h3. Upd#1 As discussed, it's required to detect whether InvokeCommand was already processed on a server and resend original response if true instead of reprocessing. First of all it's not only about invoke but about all non-idempotent commands like getAndPut, getAndPutAll, getAndRemove, etc. Worth mentioning though that it relates only to MS and maybe CMG but not Partitions: within partitions, tx protocol along with returning result from indexes instead of returning result from raft, protects us from non-idempotent command processing. All in all following solution is expected to be implemented: * New interface NonIdempotentCommand is introduced with an id field. * All MS non-idempotent commands like InvokeCommand, GetAndRemoveCommand, etc implement aforementioned interface. * On the client side, an identifier is added to the command. Two options are possible here: ** It's possible to set id to the the command on command creation. Easiest way, but it will required extra effort on the server side to track command time. In that case it's possible to use LongCounter + nodeId as an id. ** Or it's possible to adjust command with an id within retry loop, in that case we may use id as a "command time", of course, it also means that clock or System.currentTime<> should be used as id. I strongly believe that first option is better for now. * On the server side, precisely, within MS state machine new nonIdempotentCommandCache is introduced commandId -> (commandResult, commandStartTime) * On each NonIdempotentCommand following logic should be implemented: ** As an initial step it's required to check whether there's a command with given id in the cache, if true just return cached result, without command reprocessing. ** If there's no given command in the cache, process it and populate the cache with the result. Basically that's all. Both cache persistence and recovery on group restart and cache cleanup will be covered within separate tickets. was: As a result of the analysis and reproduction of IGNITE-21142, it was found that the metastorage raft command can be re-sent if it does not time out, which may not be good and lead to hidden negative consequences, such as in IGNITE-21142. Here we need to find out the reasons for this decision (with re-try by timeout) and understand what to do next. I think we should use an infinite timeout. As a result of the analysis and reproduction of IGNITE-21142, it was found that the metastorage raft command can be re-sent if it does not time out, which may not be good and lead to hidden negative consequences, such as in IGNITE-21142. Here we need to find out the reasons for this decision (with re-try by timeout) and understand what to do next. I think we should use an infinite timeout. h3. Upd#1 As discussed, it's required to detect whether InvokeCommand was already processed on a server and resend original response if true instead of reprocessing. First of all it's not only about invoke but about all non-idempotent commands like getAndPut, getAndPutAll, getAndRemove, etc. Worth mentioning though that it relates only to MS and maybe CMG but not Partitions: within partitions, tx protocol along with returning result from indexes instead of returning result from raft, protects us from non-idempotent command processing. All in all following solution is expected to be implemented: * New interface NonIdempotentCommand is introduced with an id field. * All MS non-idempotent commands like InvokeCommand, GetAndRemoveCommand, etc implement aforementioned interface NonIdempotentCommand. * On the client side, an identifier is added to the command. Two options are possible here: ** It's possible to set id to the the command on command creation. Easiest way, but it will required extra effort on the server side to track command time. In that case it's possible to use LongCounter + nodeId as an id. ** Or it's possible to adjust command
[jira] [Updated] (IGNITE-21881) Deal with retry send metastorage raft commands after a timeout
[ https://issues.apache.org/jira/browse/IGNITE-21881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21881: - Description: As a result of the analysis and reproduction of IGNITE-21142, it was found that the metastorage raft command can be re-sent if it does not time out, which may not be good and lead to hidden negative consequences, such as in IGNITE-21142. Here we need to find out the reasons for this decision (with re-try by timeout) and understand what to do next. I think we should use an infinite timeout. As a result of the analysis and reproduction of IGNITE-21142, it was found that the metastorage raft command can be re-sent if it does not time out, which may not be good and lead to hidden negative consequences, such as in IGNITE-21142. Here we need to find out the reasons for this decision (with re-try by timeout) and understand what to do next. I think we should use an infinite timeout. h3. Upd#1 As discussed, it's required to detect whether InvokeCommand was already processed on a server and resend original response if true instead of reprocessing. First of all it's not only about invoke but about all non-idempotent commands like getAndPut, getAndPutAll, getAndRemove, etc. Worth mentioning though that it relates only to MS and maybe CMG but not Partitions: within partitions, tx protocol along with returning result from indexes instead of returning result from raft, protects us from non-idempotent command processing. All in all following solution is expected to be implemented: * New interface NonIdempotentCommand is introduced with an id field. * All MS non-idempotent commands like InvokeCommand, GetAndRemoveCommand, etc implement aforementioned interface NonIdempotentCommand. * On the client side, an identifier is added to the command. Two options are possible here: ** It's possible to set id to the the command on command creation. Easiest way, but it will required extra effort on the server side to track command time. In that case it's possible to use LongCounter + nodeId as an id. ** Or it's possible to adjust command with an id within retry loop, in that case we may use id as a "command time", of course it also means that clock or System.currentTime<> should be used as id identifier. I strongly believe that first option is better for now. * On the server side, precisely, within MS state machine new nonIdempotentCommandCache is introduced commandId -> (commandResult, commandStartTime) * On each NonIdempotentCommand following logic should be implemented: ** As an initial step it's required to check whether there's command with given id in the cache, if true just return cached result, without command reprocessing. ** If there's no given command in the cache, process it and populate the cache with the result. Basically that's all. Both cache persistence and recovery on group restart and cache cleanup will be covered within separate tickets. was: As a result of the analysis and reproduction of IGNITE-21142, it was found that the metastorage raft command can be re-sent if it does not time out, which may not be good and lead to hidden negative consequences, such as in IGNITE-21142. Here we need to find out the reasons for this decision (with re-try by timeout) and understand what to do next. I think we should use an infinite timeout. As a result of the analysis and reproduction of IGNITE-21142, it was found that the metastorage raft command can be re-sent if it does not time out, which may not be good and lead to hidden negative consequences, such as in IGNITE-21142. Here we need to find out the reasons for this decision (with re-try by timeout) and understand what to do next. I think we should use an infinite timeout. h3. Upd#1 As discussed, it's required to detect whether InvokeCommand was already processed on a server and resend original response if true instead of reprocessing. First of all it's not only about invoke but about all non-idempotent commands like getAndPut, getAndPutAll, getAndRemove, etc. Worth mentioning though that it relates only to MS and maybe CMG but not Partitions: within partitions, tx protocol along with returning result from indexes instead of returning result from raft, protects us from non-idempotent command processing. All in all following solution is expected to be implemented. * New interface NonIdempotentCommand is introduced with an id field. * All MS non-idempotent commands like InvokeCommand, GetAndRemoveCommand, etc implement aforementioned interface NonIdempotentCommand. * On the client side, an identifier is added to the command. Two options are possible here: ** It's possible to set id to the the command on command creation. Easiest way, but it will required extra effort on the server side to track command time. In that case it's possible to use LongCounter + nodeId as an id. ** Or it's
[jira] [Commented] (IGNITE-21321) Review short options in CLI
[ https://issues.apache.org/jira/browse/IGNITE-21321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840711#comment-17840711 ] Aleksandr commented on IGNITE-21321: https://issues.apache.org/jira/browse/IGNITE-22108 > Review short options in CLI > --- > > Key: IGNITE-21321 > URL: https://issues.apache.org/jira/browse/IGNITE-21321 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > As the CLI grows we see that sometimes there are some clashes in short > options. We have to review all our short options and define the list of these > options. For example, -u means "user" or "url" depending on the context. This > is confusing. > As a result, I would expect the refactoring of short options and dropping > clashes. Also, the command descriptions should be reviewed and improved. The > CLI should be self-descriptive and there should be no need to open a web doc > in most cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22108) Rename options in CLI
[ https://issues.apache.org/jira/browse/IGNITE-22108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-22108: -- Assignee: Aleksandr > Rename options in CLI > - > > Key: IGNITE-22108 > URL: https://issues.apache.org/jira/browse/IGNITE-22108 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > The original CLI IEP offers both long and short options for some commands, > for example > --cluster-endpoint-url localhost:8080 and > -u localhost:8080 > The CLI is becoming more complex than it was before. We add new commands and > new options constantly. Now we can observe some confusions in short options > across some commands. > The proposal for CLI short options is to define the following conventions: > - Use exactly one letter for the short options. > - Do not overwrite the one if it is already defined for some command. > - Use short options only for commands that will probably be used frequently. > Proposed short options: > -n for node-name > -h for help > -v for verbose > -u for user > -p for password > All other short options should be dropped. > Also some common options might be shorten: > - cluster-endpoint-url, node-url → url > - cluster-config → config > - cluster-config-file → config-file > - script-file → file > - cluster-name, node-name → name > - meta-storage-node → ms-node -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22091) CLI for disaster recovery: partition states
[
https://issues.apache.org/jira/browse/IGNITE-22091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Shergalis updated IGNITE-22091:
---
Epic Link: IGNITE-21140
> CLI for disaster recovery: partition states
> ---
>
> Key: IGNITE-22091
> URL: https://issues.apache.org/jira/browse/IGNITE-22091
> Project: Ignite
> Issue Type: Task
>Reporter: Philipp Shergalis
>Assignee: Philipp Shergalis
>Priority: Major
> Labels: ignite-3
>
>
> {code:java}
> ignite cluster partition-states [--local [--nodes ] | --global]
> [--zones ] [--partitions ] [--plain]
> {code}
>
> Output for local:
> |Node name|Table name|Partition ID|State|
> |node_name|TABLE_NAME|1|HEALTHY|
>
> For global:
> |Table name|Partition ID|State|
> |TABLE_NAME|1|HEALTHY|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22091) CLI for disaster recovery: partition states
[
https://issues.apache.org/jira/browse/IGNITE-22091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Shergalis updated IGNITE-22091:
---
Parent: (was: IGNITE-21298)
Issue Type: Task (was: Sub-task)
> CLI for disaster recovery: partition states
> ---
>
> Key: IGNITE-22091
> URL: https://issues.apache.org/jira/browse/IGNITE-22091
> Project: Ignite
> Issue Type: Task
>Reporter: Philipp Shergalis
>Assignee: Philipp Shergalis
>Priority: Major
> Labels: ignite-3
>
>
> {code:java}
> ignite cluster partition-states [--local [--nodes ] | --global]
> [--zones ] [--partitions ] [--plain]
> {code}
>
> Output for local:
> |Node name|Table name|Partition ID|State|
> |node_name|TABLE_NAME|1|HEALTHY|
>
> For global:
> |Table name|Partition ID|State|
> |TABLE_NAME|1|HEALTHY|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22108) Rename options in CLI
Aleksandr created IGNITE-22108: -- Summary: Rename options in CLI Key: IGNITE-22108 URL: https://issues.apache.org/jira/browse/IGNITE-22108 Project: Ignite Issue Type: Task Components: cli Reporter: Aleksandr The original CLI IEP offers both long and short options for some commands, for example --cluster-endpoint-url localhost:8080 and -u localhost:8080 The CLI is becoming more complex than it was before. We add new commands and new options constantly. Now we can observe some confusions in short options across some commands. The proposal for CLI short options is to define the following conventions: - Use exactly one letter for the short options. - Do not overwrite the one if it is already defined for some command. - Use short options only for commands that will probably be used frequently. Proposed short options: -n for node-name -h for help -v for verbose -u for user -p for password All other short options should be dropped. Also some common options might be shorten: - cluster-endpoint-url, node-url → url - cluster-config → config - cluster-config-file → config-file - script-file → file - cluster-name, node-name → name - meta-storage-node → ms-node -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22091) CLI for disaster recovery: partition states
[
https://issues.apache.org/jira/browse/IGNITE-22091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Shergalis updated IGNITE-22091:
---
Description:
{code:java}
ignite cluster partition-states [--local [--nodes ] | --global]
[--zones ] [--partitions ] [--plain]
{code}
Output for local:
|Node name|Table name|Partition ID|State|
|node_name|TABLE_NAME|1|HEALTHY|
For global:
|Table name|Partition ID|State|
|TABLE_NAME|1|HEALTHY|
was:
{code:java}
ignite cluster partition-states [--local [--nodes ] | --global]
[--zones ] [--partitions ] [--plain]
{code}
Output for local:
| |Node name|Table name|Partition ID|State| | |
| |node_name|TABLE_NAME|1|HEALTHY| | |
For global:
| |Table name|Partition ID|State| | |
| |TABLE_NAME|1|HEALTHY| | |
> CLI for disaster recovery: partition states
> ---
>
> Key: IGNITE-22091
> URL: https://issues.apache.org/jira/browse/IGNITE-22091
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Philipp Shergalis
>Assignee: Philipp Shergalis
>Priority: Major
> Labels: ignite-3
>
>
> {code:java}
> ignite cluster partition-states [--local [--nodes ] | --global]
> [--zones ] [--partitions ] [--plain]
> {code}
>
> Output for local:
> |Node name|Table name|Partition ID|State|
> |node_name|TABLE_NAME|1|HEALTHY|
>
> For global:
> |Table name|Partition ID|State|
> |TABLE_NAME|1|HEALTHY|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22091) CLI for disaster recovery: partition states
[
https://issues.apache.org/jira/browse/IGNITE-22091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Shergalis updated IGNITE-22091:
---
Description:
{code:java}
ignite cluster partition-states [--local [--nodes ] | --global]
[--zones ] [--partitions ] [--plain]
{code}
Output for local:
| |Node name|Table name|Partition ID|State| | |
| |node_name|TABLE_NAME|1|HEALTHY| | |
For global:
| |Table name|Partition ID|State| | |
| |TABLE_NAME|1|HEALTHY| | |
was:ignite partition-states [--local [--nodes ] | --global] [--zones
] [--partitions ]
> CLI for disaster recovery: partition states
> ---
>
> Key: IGNITE-22091
> URL: https://issues.apache.org/jira/browse/IGNITE-22091
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Philipp Shergalis
>Assignee: Philipp Shergalis
>Priority: Major
> Labels: ignite-3
>
>
> {code:java}
> ignite cluster partition-states [--local [--nodes ] | --global]
> [--zones ] [--partitions ] [--plain]
> {code}
>
> Output for local:
> | |Node name|Table name|Partition ID|State| | |
> | |node_name|TABLE_NAME|1|HEALTHY| | |
>
> For global:
> | |Table name|Partition ID|State| | |
> | |TABLE_NAME|1|HEALTHY| | |
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21661) Test scenario where all stable nodes are lost during a partially completed rebalance
[ https://issues.apache.org/jira/browse/IGNITE-21661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-21661: -- Assignee: Ivan Bessonov > Test scenario where all stable nodes are lost during a partially completed > rebalance > > > Key: IGNITE-21661 > URL: https://issues.apache.org/jira/browse/IGNITE-21661 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > Following case is possible: > * Nodes A, B and C for a partition > * B and C go offline > * new distribution is A, D and E > * full state transfer from A to D is completed > * full state transfer from A to E is not > * A goes offline > * we perform "resetPartitions" > Ideally, we should use D as a new leader somehow, but the bare minimum should > be a partition that is functional, maybe an empty one. We should test the case > > This might be a good place to add more tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21661) Test scenario where all stable nodes are lost during a partially completed rebalance
[ https://issues.apache.org/jira/browse/IGNITE-21661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-21661: --- Description: Following case is possible: * Nodes A, B and C for a partition * B and C go offline * new distribution is A, D and E * full state transfer from A to D is completed * full state transfer from A to E is not * A goes offline * we perform "resetPartitions" Ideally, we should use D as a new leader somehow, but the bare minimum should be a partition that is functional, maybe an empty one. We should test the case This might be a good place to add more tests. was: Following case is possible: * Nodes A, B and C for a partition * B and C go offline * new distribution is A, D and E * full state transfer from A to D is completed * full state transfer from A to E is not * A goes offline * we perform "resetPartitions" Ideally, we should use D as a new leader somehow, but the bare minimum should be a partition that is functional, maybe an empty one. We should test the case > Test scenario where all stable nodes are lost during a partially completed > rebalance > > > Key: IGNITE-21661 > URL: https://issues.apache.org/jira/browse/IGNITE-21661 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > Following case is possible: > * Nodes A, B and C for a partition > * B and C go offline > * new distribution is A, D and E > * full state transfer from A to D is completed > * full state transfer from A to E is not > * A goes offline > * we perform "resetPartitions" > Ideally, we should use D as a new leader somehow, but the bare minimum should > be a partition that is functional, maybe an empty one. We should test the case > > This might be a good place to add more tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21881) Deal with retry send metastorage raft commands after a timeout
[ https://issues.apache.org/jira/browse/IGNITE-21881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21881: - Description: As a result of the analysis and reproduction of IGNITE-21142, it was found that the metastorage raft command can be re-sent if it does not time out, which may not be good and lead to hidden negative consequences, such as in IGNITE-21142. Here we need to find out the reasons for this decision (with re-try by timeout) and understand what to do next. I think we should use an infinite timeout. As a result of the analysis and reproduction of IGNITE-21142, it was found that the metastorage raft command can be re-sent if it does not time out, which may not be good and lead to hidden negative consequences, such as in IGNITE-21142. Here we need to find out the reasons for this decision (with re-try by timeout) and understand what to do next. I think we should use an infinite timeout. h3. Upd#1 As discussed, it's required to detect whether InvokeCommand was already processed on a server and resend original response if true instead of reprocessing. First of all it's not only about invoke but about all non-idempotent commands like getAndPut, getAndPutAll, getAndRemove, etc. Worth mentioning though that it relates only to MS and maybe CMG but not Partitions: within partitions, tx protocol along with returning result from indexes instead of returning result from raft, protects us from non-idempotent command processing. All in all following solution is expected to be implemented. * New interface NonIdempotentCommand is introduced with an id field. * All MS non-idempotent commands like InvokeCommand, GetAndRemoveCommand, etc implement aforementioned interface NonIdempotentCommand. * On the client side, an identifier is added to the command. Two options are possible here: ** It's possible to set id to the the command on command creation. Easiest way, but it will required extra effort on the server side to track command time. In that case it's possible to use LongCounter + nodeId as an id. ** Or it's possible to adjust command with an id within retry loop, in that case we may use id as a "command time", of course it also means that clock or System.currentTime<> should be used as id identifier. I strongly believe that first option is better for now. * On the server side, precisely, within MS state machine new nonIdempotentCommandCache is introduced commandId -> (commandResult, commandStartTime) * On each NonIdempotentCommand following logic should be implemented: ** As an initial step it's required to check whether there's command with given id in the cache, if true just return cached result, without command reprocessing. ** If there's no given command in the cache, process it and populate the cache with the result. Basically that's all. Both cache persistence and recovery on group restart and cache cleanup will be covered within separate tickets. was: As a result of the analysis and reproduction of IGNITE-21142, it was found that the metastorage raft command can be re-sent if it does not time out, which may not be good and lead to hidden negative consequences, such as in IGNITE-21142. Here we need to find out the reasons for this decision (with re-try by timeout) and understand what to do next. I think we should use an infinite timeout. > Deal with retry send metastorage raft commands after a timeout > -- > > Key: IGNITE-21881 > URL: https://issues.apache.org/jira/browse/IGNITE-21881 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > As a result of the analysis and reproduction of IGNITE-21142, it was found > that the metastorage raft command can be re-sent if it does not time out, > which may not be good and lead to hidden negative consequences, such as in > IGNITE-21142. > Here we need to find out the reasons for this decision (with re-try by > timeout) and understand what to do next. I think we should use an infinite > timeout. > As a result of the analysis and reproduction of IGNITE-21142, it was found > that the metastorage raft command can be re-sent if it does not time out, > which may not be good and lead to hidden negative consequences, such as in > IGNITE-21142. > Here we need to find out the reasons for this decision (with re-try by > timeout) and understand what to do next. I think we should use an infinite > timeout. > h3. Upd#1 > As discussed, it's required to detect whether InvokeCommand was already > processed on a server and resend original response if true instead of > reprocessing. First of all it's not only about invoke but about all > non-idempotent commands like getAndPut,
[jira] [Updated] (IGNITE-22096) Spring 6 support for ignite spring extensions
[ https://issues.apache.org/jira/browse/IGNITE-22096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-22096: - Description: This epic is about spring 6 support for ignite extensions. Spring boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications, because extensions based on spring 5. Actually, most of them should work fine in spring 6 apps, but we may find ourselves on thin ice with this approach. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring based ignite extensions to spring 6. The upgrade will affect modules which won't work in spring 6 environment(basically, where api was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build still will be available. Project will support both options, sprint 6 modules will be enabled only when jdk 17 is used. The main build will be with jdk 17, because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to compatibility test, this module should be build only with JDK 17, otherwise tests will fail. But maven.compiler.release can be 8. # For updated modules use new versioning approach. Use the same major and minor for spring extension as corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, spring-session-ext version should be 3.2.x, where x is revision number. was: This epic is about spring 6 support for ignite extensions. Spring boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications, because extensions based on spring 5. Actually, most of them should work fine in spring 6 apps, but we may find ourselves on thin ice with this approach. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring based ignite extensions to spring 6. The upgrade will affect modules which won't work in spring 6 environment(basically, where api was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build option still will be available. Project will support both options, sprint 6 modules will be enabled only when jdk 17 is used, so in the end the main build will be with jdk 17, because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to compatibility test, this module should be build only with JDK 17, otherwise tests will fail. But maven.compiler.release can be 8. # For updated modules use new versioning approach. Use the same major and minor for spring extension as corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, spring-session-ext version should be 3.2.x, where x is revision number. > Spring 6 support for ignite spring extensions > - > > Key: IGNITE-22096 > URL: https://issues.apache.org/jira/browse/IGNITE-22096 > Project: Ignite > Issue Type: Epic >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > > This epic is about spring 6 support for ignite extensions. > Spring boot 3 and Spring 6 users may have difficulties using ignite spring > extensions in their applications, because extensions based on spring 5. > Actually, most of them should work fine in spring 6 apps, but we may find > ourselves on thin ice with this approach. > For some spring modules like spring-data-commons and spring-session-core, > Spring has finished spring 5 support in Nov 2023. For other modules(and > spring-core) support ends in Aug 2024. > The proposal is to upgrade spring based ignite extensions to spring 6. The > upgrade will affect modules which won't work in spring 6 > environment(basically, where api was broken). > Taking into consideration that spring 6 comes with JDK 17+ baseline the plan > is the following: > # Add ignite extensions
[jira] [Updated] (IGNITE-22096) Spring 6 support for ignite spring extensions
[ https://issues.apache.org/jira/browse/IGNITE-22096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-22096: - Description: This epic is about spring 6 support for ignite extensions. Spring boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications, because extensions based on spring 5. Actually, most of them should work fine in spring 6 apps, but we may find ourselves on thin ice with this approach. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring based ignite extensions to spring 6. The upgrade will affect modules which won't work in spring 6 environment(basically, where api was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build option still will be available. Project will support both options, sprint 6 modules will be enabled only when jdk 17 is used, so in the end the main build will be with jdk 17, because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to compatibility test, this module should be build only with JDK 17, otherwise tests will fail. But maven.compiler.release can be 8. # For updated modules use new versioning approach. Use the same major and minor for spring extension as corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, spring-session-ext version should be 3.2.x, where x is revision number. was: This is epic about spring 6 support for ignite extensions. Spring boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications, because extensions based on spring 5. Actually, most of them should work fine in spring 6 apps, but we may find ourselves on thin ice with this approach. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring based ignite extensions to spring 6. The upgrade will affect modules which won't work in spring 6 environment(basically, where api was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build option still will be available. Project will support both options, sprint 6 modules will be enabled only when jdk 17 is used, so in the end the main build will be with jdk 17, because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to compatibility test, this module should be build only with JDK 17, otherwise tests will fail. But maven.compiler.release can be 8. # For updated modules use new versioning approach. Use the same major and minor for spring extension as corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, spring-session-ext version should be 3.2.x, where x is revision number. > Spring 6 support for ignite spring extensions > - > > Key: IGNITE-22096 > URL: https://issues.apache.org/jira/browse/IGNITE-22096 > Project: Ignite > Issue Type: Epic >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > > This epic is about spring 6 support for ignite extensions. > Spring boot 3 and Spring 6 users may have difficulties using ignite spring > extensions in their applications, because extensions based on spring 5. > Actually, most of them should work fine in spring 6 apps, but we may find > ourselves on thin ice with this approach. > For some spring modules like spring-data-commons and spring-session-core, > Spring has finished spring 5 support in Nov 2023. For other modules(and > spring-core) support ends in Aug 2024. > The proposal is to upgrade spring based ignite extensions to spring 6. The > upgrade will affect modules which won't work in spring 6 > environment(basically, where api was broken). > Taking into consideration that spring 6 comes with JDK 17+ baseline the plan > is the following: > #
[jira] [Updated] (IGNITE-22096) Spring 6 support for ignite spring extensions
[ https://issues.apache.org/jira/browse/IGNITE-22096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nusrat Shakarov updated IGNITE-22096: - Description: This is epic about spring 6 support for ignite extensions. Spring boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications, because extensions based on spring 5. Actually, most of them should work fine in spring 6 apps, but we may find ourselves on thin ice with this approach. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring based ignite extensions to spring 6. The upgrade will affect modules which won't work in spring 6 environment(basically, where api was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build option still will be available. Project will support both options, sprint 6 modules will be enabled only when jdk 17 is used, so in the end the main build will be with jdk 17, because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to compatibility test, this module should be build only with JDK 17, otherwise tests will fail. But maven.compiler.release can be 8. # For updated modules use new versioning approach. Use the same major and minor for spring extension as corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, spring-session-ext version should be 3.2.x, where x is revision number. was: This is epic about spring 6 support in ignite extensions. Spring boot 3 and Spring 6 users may have difficulties using ignite spring extensions in their applications, because extensions based on spring 5. Actually, most of them should work fine in spring 6 apps, but we may find ourselves on thin ice with this approach. For some spring modules like spring-data-commons and spring-session-core, Spring has finished spring 5 support in Nov 2023. For other modules(and spring-core) support ends in Aug 2024. The proposal is to upgrade spring based ignite extensions to spring 6. The upgrade will affect modules which won't work in spring 6 environment(basically, where api was broken). Taking into consideration that spring 6 comes with JDK 17+ baseline the plan is the following: # Add ignite extensions build on TC with JDK 17. JDK 8 build option still will be available. Project will support both options, sprint 6 modules will be enabled only when jdk 17 is used, so in the end the main build will be with jdk 17, because it covers all modules. # Use maven.compiler.release=8 for parent pom. # If spring module won't work in spring 6 env, upgrade it with spring 6 dependencies and set maven.compiler.release=17. # Otherwise, make sure that spring 6 is covered with compatibility tests(we have such at least for cache-ext and tx-ext). If spring 6 is added to compatibility test, this module should be build only with JDK 17, otherwise tests will fail. But maven.compiler.release can be 8. # For updated modules use new versioning approach. Use the same major and minor for spring extension as corresponding spring module uses. For example, If spring-session-core is updated to 3.2.2, spring-session-ext version should be 3.2.x, where x is revision number. > Spring 6 support for ignite spring extensions > - > > Key: IGNITE-22096 > URL: https://issues.apache.org/jira/browse/IGNITE-22096 > Project: Ignite > Issue Type: Epic >Reporter: Nusrat Shakarov >Assignee: Nusrat Shakarov >Priority: Major > > This is epic about spring 6 support for ignite extensions. > Spring boot 3 and Spring 6 users may have difficulties using ignite spring > extensions in their applications, because extensions based on spring 5. > Actually, most of them should work fine in spring 6 apps, but we may find > ourselves on thin ice with this approach. > For some spring modules like spring-data-commons and spring-session-core, > Spring has finished spring 5 support in Nov 2023. For other modules(and > spring-core) support ends in Aug 2024. > The proposal is to upgrade spring based ignite extensions to spring 6. The > upgrade will affect modules which won't work in spring 6 > environment(basically, where api was broken). > Taking into consideration that spring 6 comes with JDK 17+ baseline the plan > is the following: > #
[jira] [Updated] (IGNITE-21953) Cover SQL E021-01(Character string types. CHARACTER data type) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-21953: Description: We don't have at all any tests for E021-01(Character string types. CHARACTER data type) SQL feature. Let's cover it and create tickets to fix them in case find any issues related to the covered area. was: We don't have at all any tests for E021-01(Character string types. CHARACTER data type) SQL feature. Let's cover it and create tickets to fix them in case find any issues related to the covered area > Cover SQL E021-01(Character string types. CHARACTER data type) feature by > tests > --- > > Key: IGNITE-21953 > URL: https://issues.apache.org/jira/browse/IGNITE-21953 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for E021-01(Character string types. CHARACTER > data type) 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-22107) Properly encapsulate partition meta
[
https://issues.apache.org/jira/browse/IGNITE-22107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-22107:
---
Description:
{{PartitionMeta}} and {{PartitionMetaIo}} leak specific implementation details,
specifically - all fields except for {{{}pageCount{}}}. This breaks
encapsulation and makes {{page-memory}} module code non-reusable.
I propose splitting meta into 2 parts - abstract meta, that would only hold
page count, and specific meta that will be located in a different module, close
to the implementation.
In this case, we would have to pass meta IO as parameters into methods like
{{{}PartitionMetaManager#readOrCreateMeta{}}}, and create a getter for IO in
{{AbstractPartitionMeta}} class itself, but that's a necessary sacrifice. Some
other places will be affected as well, mostly tests.
was:
`PartitionMeta` and `PartitionMetaIo` leak specific implementation details,
specifically - all fields except for `pageCount`. This breaks encapsulation and
makes `page-memory` module code non-reusable.
I propose splitting meta into 2 parts - abstract meta, that would only hold
page count, and specific meta that will be located in a different module, close
to the implementation.
In this case, we would have to pass meta IO as parameters into methods like
`PartitionMetaManager#readOrCreateMeta`, and create a getter for IO in
`AbstractPartitionMeta` class itself, but that's a necessary sacrifice.
> Properly encapsulate partition meta
> ---
>
> Key: IGNITE-22107
> URL: https://issues.apache.org/jira/browse/IGNITE-22107
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {{PartitionMeta}} and {{PartitionMetaIo}} leak specific implementation
> details, specifically - all fields except for {{{}pageCount{}}}. This breaks
> encapsulation and makes {{page-memory}} module code non-reusable.
> I propose splitting meta into 2 parts - abstract meta, that would only hold
> page count, and specific meta that will be located in a different module,
> close to the implementation.
> In this case, we would have to pass meta IO as parameters into methods like
> {{{}PartitionMetaManager#readOrCreateMeta{}}}, and create a getter for IO in
> {{AbstractPartitionMeta}} class itself, but that's a necessary sacrifice.
> Some other places will be affected as well, mostly tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22107) Properly encapsulate partition meta
Ivan Bessonov created IGNITE-22107: -- Summary: Properly encapsulate partition meta Key: IGNITE-22107 URL: https://issues.apache.org/jira/browse/IGNITE-22107 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Fix For: 3.0.0-beta2 `PartitionMeta` and `PartitionMetaIo` leak specific implementation details, specifically - all fields except for `pageCount`. This breaks encapsulation and makes `page-memory` module code non-reusable. I propose splitting meta into 2 parts - abstract meta, that would only hold page count, and specific meta that will be located in a different module, close to the implementation. In this case, we would have to pass meta IO as parameters into methods like `PartitionMetaManager#readOrCreateMeta`, and create a getter for IO in `AbstractPartitionMeta` class itself, but that's a necessary sacrifice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21434) Fail user write requests for non-available partitions
[
https://issues.apache.org/jira/browse/IGNITE-21434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov resolved IGNITE-21434.
Resolution: Won't Fix
This insert doesn't hang indefinitely anymore, it fails with primary replica
awaiting. I'm closing the issue as "Won't Fix"
> Fail user write requests for non-available partitions
> -
>
> Key: IGNITE-21434
> URL: https://issues.apache.org/jira/browse/IGNITE-21434
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
>
> Currently, {{INSERT INTO test VALUES(%d, %d);}} just hands indefinitely,
> which is not what you would expect. We should either fail the request
> immediately if there's no majority, or return a replication timeout
> exception, for example.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22100) Sql. Incorrect support of character set for CHAR data type
[
https://issues.apache.org/jira/browse/IGNITE-22100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22100:
Description:
Seems the character set doesn't apply to column type.
Need to investigate the reason and fix it
For example:
{code:java}
// create table with LATIN-1 charset column
CREATE TABLE t_latin1 (c1 CHARACTER(3) CHARACTER SET LATIN1);
// try to insert Unicode symbol into he table
INSERT INTO t_latin1 VALUES(''); -- no any error
// select from the table also return the value
SELECT * from t_latin1;
{code}
was:
Seems the character set doesn't apply to column type.
Need to investigate the reason and fix it
For example:
{code:java}
// create table with LATIN-1 charset column
CREATE TABLE t_latin1 (c1 CHARACTER(3) CHARACTER SET LATIN1);
// try to insert Unicode symbol into he table
INSERT INTO t_latin1 VALUES(''); -- no any error
// select from the table also return the value
SELECT * from t_latin1;
{code}
> Sql. Incorrect support of character set for CHAR data type
> --
>
> Key: IGNITE-22100
> URL: https://issues.apache.org/jira/browse/IGNITE-22100
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> Seems the character set doesn't apply to column type.
> Need to investigate the reason and fix it
> For example:
> {code:java}
> // create table with LATIN-1 charset column
> CREATE TABLE t_latin1 (c1 CHARACTER(3) CHARACTER SET LATIN1);
> // try to insert Unicode symbol into he table
> INSERT INTO t_latin1 VALUES(''); -- no any error
> // select from the table also return the value
> SELECT * from t_latin1;
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22098) Sql. Internal error (NPE) during provide incorrect charset
[
https://issues.apache.org/jira/browse/IGNITE-22098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22098:
Labels: ignite-3 (was: )
> Sql. Internal error (NPE) during provide incorrect charset
> --
>
> Key: IGNITE-22098
> URL: https://issues.apache.org/jira/browse/IGNITE-22098
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> In the case provided incorrect charset name for type will be thrown internal
> error which NPE causes.
> Let's provide user-friendly errors for such cases.
> Use incorrect charset name:
> {code:java}
> CREATE TABLE test (c1 CHAR CHARACTER SET UTF_8);{code}
> Result:
> {code:java}
> Caused by: org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:382210fe-335d-4df2-b8fc-149c13b7f5e5 UTF_8
> at
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:732)
> at
> org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
> at
> org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:634)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
> at
> org.apache.ignite.internal.sql.api.IgniteSqlImpl.execute(IgniteSqlImpl.java:206)
> at
> org.apache.ignite.internal.sql.api.PublicApiThreadingIgniteSql.lambda$execute$1(PublicApiThreadingIgniteSql.java:65)
> at
> org.apache.ignite.internal.thread.PublicApiThreading.executeWithRole(PublicApiThreading.java:144)
> at
> org.apache.ignite.internal.thread.PublicApiThreading.execUserSyncOperation(PublicApiThreading.java:102)
> at
> org.apache.ignite.internal.sql.api.PublicApiThreadingIgniteSql.execute(PublicApiThreadingIgniteSql.java:65)
> at
> org.apache.ignite.internal.sql.sqllogic.ScriptContext.executeQuery(ScriptContext.java:85)
> at
> org.apache.ignite.internal.sql.sqllogic.Statement.execute(Statement.java:110)
> ... 5 more
> Caused by: java.util.concurrent.CompletionException:
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:382210fe-335d-4df2-b8fc-149c13b7f5e5 UTF_8
> at
> org.apache.ignite.internal.sql.api.IgniteSqlImpl.lambda$executeAsyncInternal$5(IgniteSqlImpl.java:379)
> at
> java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:990)
> at
> java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:974)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:83)
> ... 3 more
> Caused by: org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:382210fe-335d-4df2-b8fc-149c13b7f5e5 UTF_8
> at
> org.apache.ignite.internal.lang.SqlExceptionMapperUtil.mapToPublicSqlException(SqlExceptionMapperUtil.java:61)
> ... 9 more
> Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:382210fe-335d-4df2-b8fc-149c13b7f5e5 UTF_8
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:118)
> at
> org.apache.ignite.internal.lang.SqlExceptionMapperUtil.mapToPublicSqlException(SqlExceptionMapperUtil.java:51)
> ... 9 more
> Caused by: java.lang.NullPointerException: UTF_8
> at java.base/java.util.Objects.requireNonNull(Objects.java:233)
> at
> org.apache.calcite.sql.SqlBasicTypeNameSpec.deriveType(SqlBasicTypeNameSpec.java:220)
> at
> org.apache.calcite.sql.SqlDataTypeSpec.deriveType(SqlDataTypeSpec.java:234)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.convert(IgnitePlanner.java:229)
> at
> org.apache.ignite.internal.sql.engine.prepare.ddl.DdlSqlToCommandConverter.convertCreateTable(DdlSqlToCommandConverter.java:334)
> at
> org.apache.ignite.internal.sql.engine.prepare.ddl.DdlSqlToCommandConverter.convert(DdlSqlToCommandConverter.java:182)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.prepareDdl(PrepareServiceImpl.java:245)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.prepareAsync0(PrepareServiceImpl.java:230)
> at
>
[jira] [Updated] (IGNITE-22100) Sql. Incorrect support of character set for CHAR data type
[
https://issues.apache.org/jira/browse/IGNITE-22100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22100:
Labels: ignite-3 (was: )
> Sql. Incorrect support of character set for CHAR data type
> --
>
> Key: IGNITE-22100
> URL: https://issues.apache.org/jira/browse/IGNITE-22100
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> Seems the character set doesn't apply to column type.
> Need to investigate the reason and fix it
> For example:
>
> {code:java}
> // create table with LATIN-1 charset column
> CREATE TABLE t_latin1 (c1 CHARACTER(3) CHARACTER SET LATIN1);
> // try to insert Unicode symbol into he table
> INSERT INTO t_latin1 VALUES(''); -- no any error
> // select from the table also return the value
> SELECT * from t_latin1;
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22098) Sql. Internal error (NPE) during provide incorrect charset
[
https://issues.apache.org/jira/browse/IGNITE-22098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22098:
Description:
In the case provided incorrect charset name for type will be thrown internal
error which NPE causes.
Let's provide user-friendly errors for such cases.
Use incorrect charset name:
{code:java}
CREATE TABLE test (c1 CHAR CHARACTER SET UTF_8);{code}
Result:
{code:java}
Caused by: org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:382210fe-335d-4df2-b8fc-149c13b7f5e5 UTF_8
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:732)
at
org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
at
org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:634)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
at
org.apache.ignite.internal.sql.api.IgniteSqlImpl.execute(IgniteSqlImpl.java:206)
at
org.apache.ignite.internal.sql.api.PublicApiThreadingIgniteSql.lambda$execute$1(PublicApiThreadingIgniteSql.java:65)
at
org.apache.ignite.internal.thread.PublicApiThreading.executeWithRole(PublicApiThreading.java:144)
at
org.apache.ignite.internal.thread.PublicApiThreading.execUserSyncOperation(PublicApiThreading.java:102)
at
org.apache.ignite.internal.sql.api.PublicApiThreadingIgniteSql.execute(PublicApiThreadingIgniteSql.java:65)
at
org.apache.ignite.internal.sql.sqllogic.ScriptContext.executeQuery(ScriptContext.java:85)
at
org.apache.ignite.internal.sql.sqllogic.Statement.execute(Statement.java:110)
... 5 more
Caused by: java.util.concurrent.CompletionException:
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:382210fe-335d-4df2-b8fc-149c13b7f5e5 UTF_8
at
org.apache.ignite.internal.sql.api.IgniteSqlImpl.lambda$executeAsyncInternal$5(IgniteSqlImpl.java:379)
at
java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:990)
at
java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:974)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773)
at
org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:83)
... 3 more
Caused by: org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:382210fe-335d-4df2-b8fc-149c13b7f5e5 UTF_8
at
org.apache.ignite.internal.lang.SqlExceptionMapperUtil.mapToPublicSqlException(SqlExceptionMapperUtil.java:61)
... 9 more
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:382210fe-335d-4df2-b8fc-149c13b7f5e5 UTF_8
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:118)
at
org.apache.ignite.internal.lang.SqlExceptionMapperUtil.mapToPublicSqlException(SqlExceptionMapperUtil.java:51)
... 9 more
Caused by: java.lang.NullPointerException: UTF_8
at java.base/java.util.Objects.requireNonNull(Objects.java:233)
at
org.apache.calcite.sql.SqlBasicTypeNameSpec.deriveType(SqlBasicTypeNameSpec.java:220)
at
org.apache.calcite.sql.SqlDataTypeSpec.deriveType(SqlDataTypeSpec.java:234)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.convert(IgnitePlanner.java:229)
at
org.apache.ignite.internal.sql.engine.prepare.ddl.DdlSqlToCommandConverter.convertCreateTable(DdlSqlToCommandConverter.java:334)
at
org.apache.ignite.internal.sql.engine.prepare.ddl.DdlSqlToCommandConverter.convert(DdlSqlToCommandConverter.java:182)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.prepareDdl(PrepareServiceImpl.java:245)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.prepareAsync0(PrepareServiceImpl.java:230)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.prepareAsync(PrepareServiceImpl.java:210)
at
org.apache.ignite.internal.sql.engine.SqlQueryProcessor.lambda$executeParsedStatement$16(SqlQueryProcessor.java:648)
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2309)
at
org.apache.ignite.internal.sql.engine.SqlQueryProcessor.executeParsedStatement(SqlQueryProcessor.java:636)
at
org.apache.ignite.internal.sql.engine.SqlQueryProcessor.lambda$querySingle$10(SqlQueryProcessor.java:567)
at
[jira] [Created] (IGNITE-22106) Sql. Incorrect comparison CHAR data type in our own execution algorithms
Iurii Gerzhedovich created IGNITE-22106:
---
Summary: Sql. Incorrect comparison CHAR data type in our own
execution algorithms
Key: IGNITE-22106
URL: https://issues.apache.org/jira/browse/IGNITE-22106
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Iurii Gerzhedovich
SQL standard says:
{code:java}
The comparison of two character string expressions depends on the collation
used for the comparison (see
Subclause 9.15, “Collation determination”). When values of unequal length are
compared, if the collation for
the comparison has the NO PAD characteristic and the shorter value is equal to
some prefix of the longer value,
then the shorter value is considered less than the longer value. If the
collation for the comparison has the PAD
SPACE characteristic, for the purposes of the comparison, the shorter value is
effectively extended to the length
of the longer by concatenation of s on the right.{code}
The rule works for simple cases like
{code:java}
SELECT 'a' = 'a' AS t1, 'a' = 'b' AS t2, 'a' = 'a ' AS t3, 'a' = ' a' AS
t4;{code}
But doesn't work for internal algorithms that uses comparison, for example in
JOIN
{code:java}
CREATE TABLE t2(c1 CHAR(3));
INSERT INTO t2 VALUES ('123'),('2'),('1');
CREATE TABLE t1(c1 CHAR(5));
INSERT INTO t1 VALUES('1 '), (' 2');
SELECT t1.c1 || t2.c1 FROM t1 join t2 ON (t1.c1=t2.c1);
-- no rows return right now
-- expected result is one row - 11{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22100) Sql. Incorrect support of character set for CHAR data type
[
https://issues.apache.org/jira/browse/IGNITE-22100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-22100:
Component/s: sql
> Sql. Incorrect support of character set for CHAR data type
> --
>
> Key: IGNITE-22100
> URL: https://issues.apache.org/jira/browse/IGNITE-22100
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
>
> Seems the character set doesn't apply to column type.
> Need to investigate the reason and fix it
> For example:
>
> {code:java}
> // create table with LATIN-1 charset column
> CREATE TABLE t_latin1 (c1 CHARACTER(3) CHARACTER SET LATIN1);
> // try to insert Unicode symbol into he table
> INSERT INTO t_latin1 VALUES(''); -- no any error
> // select from the table also return the value
> SELECT * from t_latin1;
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22105) Add logging for CMG state access
[ https://issues.apache.org/jira/browse/IGNITE-22105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtsev updated IGNITE-22105: - Fix Version/s: 3.0.0-beta2 > Add logging for CMG state access > > > Key: IGNITE-22105 > URL: https://issues.apache.org/jira/browse/IGNITE-22105 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtsev >Assignee: Aleksandr Polovtsev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22105) Add logging for CMG state access
Aleksandr Polovtsev created IGNITE-22105: Summary: Add logging for CMG state access Key: IGNITE-22105 URL: https://issues.apache.org/jira/browse/IGNITE-22105 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtsev Assignee: Aleksandr Polovtsev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21859) Causality token stays 0 for default zone
[
https://issues.apache.org/jira/browse/IGNITE-21859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840661#comment-17840661
]
Konstantin Orlov edited comment on IGNITE-21859 at 4/25/24 6:13 AM:
Gave it a second thought, and it looks like we can address the issue on
catalog's side.
[~amashenkov], [~maliev], folks, do a review please
was (Author: korlov):
Gave it a second thought, and it looks like we can address the issue on
catalogs side.
[~amashenkov], [~maliev], folks, do a review please
> Causality token stays 0 for default zone
>
>
> Key: IGNITE-21859
> URL: https://issues.apache.org/jira/browse/IGNITE-21859
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Zlenko
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a problem where if no alter or other action was performed on default
> zone causality token in CatalogZoneDescriptor will remain 0.
> It will cause an error on any attempt of rebalacing any tables in that zone:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-18][DistributionZoneRebalanceEngine]
> Failed to update stable keys for tables [[TESTTABLE]]
> {code}
> If we will add stacktrace to output we will get following:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-13][DistributionZoneRebalanceEngine]
> CATCH,
> java.lang.IllegalArgumentException: causalityToken must be greater then zero
> [causalityToken=0"
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine.dataNodes(CausalityDataNodesEngine.java:139)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.dataNodes(DistributionZoneManager.java:324)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine.calculateAssignments(DistributionZoneRebalanceEngine.java:346)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.doStableKeySwitch(RebalanceRaftGroupEventsListener.java:408)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$0(DistributionZoneRebalanceEngine.java:294)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at java.base/java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$1(DistributionZoneRebalanceEngine.java:293)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> 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:829) [?:?]
> {code}
> The workaround is creating a zone and specifying this zone to table.
> Also wouldn't be a bad idea to print stacktrace for "Failed to update stable
> keys for tables" at least on DEBUG log level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
