[jira] [Updated] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-15568:
---
Attachment: MyInsertBenchmarkWithMetrics.java
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java, MyInsertBenchmarkWithMetrics.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
> to dhow increasing in case with high parallelism in one partition.
> There is [an example of the
> benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-15568:
---
Attachment: (was: MyInsertBenchmarkWithMetrics.java)
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java, MyInsertBenchmarkWithMetrics.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
> to dhow increasing in case with high parallelism in one partition.
> There is [an example of the
> benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847377#comment-17847377
]
Vladislav Pyatkov edited comment on IGNITE-15568 at 5/17/24 5:04 PM:
-
{code}
New
Raft metrics:
raft.logmanager.disruptor.Batch: [
0_10:2487232,
10_20:5693,
20_30:2096,
30_40:574,
40_50:295,
50_inf:4]
raft.nodeimpl.disruptor.Batch: [
0_10:3387423,
10_20:660,
20_30:44,
30_40:3,
40_50:0,
50_inf:0]
raft.readonlyservice.disruptor.Batch: [
0_10:2,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
raft.fsmcaller.disruptor.Batch: [
0_10:29651,
10_20:96043,
20_30:67743,
30_40:350,
40_50:0,
50_inf:0]
Benchmark (clusterSize) (fsync) (partitionCount)
Mode Cnt Score Error Units
MyInsertBenchmarkWithMetrics.kvInsert 1false 2
avgt 200 6723,882 ± 639,991 us/op
MyInsertBenchmarkWithMetrics.kvInsert 1 true 2
avgt 200 7722,169 ± 504,716 us/op
Old
raft.logmanager.disruptor.Batch: [
0_10:2788769,
10_20:8218,
20_30:4532,
30_40:1579,
40_50:782,
50_inf:61]
Benchmark (clusterSize) (fsync) (partitionCount)
Mode Cnt Score Error Units
MyInsertBenchmarkWithMetrics.kvInsert 1false 2
avgt 200 7611,808 ± 695,469 us/op
MyInsertBenchmarkWithMetrics.kvInsert 1 true 2
avgt 200 7681,789 ± 433,490 us/op
{code}
was (Author: v.pyatkov):
{code}
New
Raft metrics:
raft.logmanager.disruptor.Batch: [
0_10:2487232,
10_20:5693,
20_30:2096,
30_40:574,
40_50:295,
50_inf:4]
raft.nodeimpl.disruptor.Batch: [
0_10:3387423,
10_20:660,
20_30:44,
30_40:3,
40_50:0,
50_inf:0]
raft.readonlyservice.disruptor.Batch: [
0_10:2,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
raft.fsmcaller.disruptor.Batch: [
0_10:29651,
10_20:96043,
20_30:67743,
30_40:350,
40_50:0,
50_inf:0]
Benchmark (clusterSize) (fsync) (partitionCount)
Mode Cnt Score Error Units
MyInsertBenchmarkWithMetrics.kvInsert 1false 2
avgt 200 6723,882 ± 639,991 us/op
MyInsertBenchmarkWithMetrics.kvInsert 1 true 2
avgt 200 7722,169 ± 504,716 us/op
Old
raft.logmanager.disruptor.Batch: [
0_10:2788769,
10_20:8218,
20_30:4532,
30_40:1579,
40_50:782,
50_inf:61]
raft.nodeimpl.disruptor.Batch: [
0_10:3274036,
10_20:2066,
20_30:446,
30_40:128,
40_50:35,
50_inf:8]
raft.readonlyservice.disruptor.Batch: [
0_10:2,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
raft.fsmcaller.disruptor.Batch: [
0_10:9135,
10_20:6197,
20_30:4795,
30_40:6800,
40_50:80328,
50_inf:73]
Benchmark (clusterSize) (fsync) (partitionCount)
Mode Cnt Score Error Units
MyInsertBenchmarkWithMetrics.kvInsert 1false 2
avgt 200 7611,808 ± 695,469 us/op
MyInsertBenchmarkWithMetrics.kvInsert 1 true 2
avgt 200 7681,789 ± 433,490 us/op
{code}
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java, MyInsertBenchmarkWithMetrics.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
[jira] [Comment Edited] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847377#comment-17847377
]
Vladislav Pyatkov edited comment on IGNITE-15568 at 5/17/24 5:03 PM:
-
{code}
New
Raft metrics:
raft.logmanager.disruptor.Batch: [
0_10:2487232,
10_20:5693,
20_30:2096,
30_40:574,
40_50:295,
50_inf:4]
raft.nodeimpl.disruptor.Batch: [
0_10:3387423,
10_20:660,
20_30:44,
30_40:3,
40_50:0,
50_inf:0]
raft.readonlyservice.disruptor.Batch: [
0_10:2,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
raft.fsmcaller.disruptor.Batch: [
0_10:29651,
10_20:96043,
20_30:67743,
30_40:350,
40_50:0,
50_inf:0]
Benchmark (clusterSize) (fsync) (partitionCount)
Mode Cnt Score Error Units
MyInsertBenchmarkWithMetrics.kvInsert 1false 2
avgt 200 6723,882 ± 639,991 us/op
MyInsertBenchmarkWithMetrics.kvInsert 1 true 2
avgt 200 7722,169 ± 504,716 us/op
Old
raft.logmanager.disruptor.Batch: [
0_10:2788769,
10_20:8218,
20_30:4532,
30_40:1579,
40_50:782,
50_inf:61]
raft.nodeimpl.disruptor.Batch: [
0_10:3274036,
10_20:2066,
20_30:446,
30_40:128,
40_50:35,
50_inf:8]
raft.readonlyservice.disruptor.Batch: [
0_10:2,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
raft.fsmcaller.disruptor.Batch: [
0_10:9135,
10_20:6197,
20_30:4795,
30_40:6800,
40_50:80328,
50_inf:73]
Benchmark (clusterSize) (fsync) (partitionCount)
Mode Cnt Score Error Units
MyInsertBenchmarkWithMetrics.kvInsert 1false 2
avgt 200 7611,808 ± 695,469 us/op
MyInsertBenchmarkWithMetrics.kvInsert 1 true 2
avgt 200 7681,789 ± 433,490 us/op
{code}
was (Author: v.pyatkov):
{code}
New
Raft metrics:
raft.logmanager.disruptor.Batch: [
0_10:2487232,
10_20:5693,
20_30:2096,
30_40:574,
40_50:295,
50_inf:4]
Benchmark (clusterSize) (fsync) (partitionCount)
Mode Cnt Score Error Units
MyInsertBenchmarkWithMetrics.kvInsert 1false 2
avgt 200 6723,882 ± 639,991 us/op
MyInsertBenchmarkWithMetrics.kvInsert 1 true 2
avgt 200 7722,169 ± 504,716 us/op
Old
raft.logmanager.disruptor.Batch: [
0_10:2788769,
10_20:8218,
20_30:4532,
30_40:1579,
40_50:782,
50_inf:61]
raft.nodeimpl.disruptor.Batch: [
0_10:3274036,
10_20:2066,
20_30:446,
30_40:128,
40_50:35,
50_inf:8]
raft.readonlyservice.disruptor.Batch: [
0_10:2,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
raft.fsmcaller.disruptor.Batch: [
0_10:9135,
10_20:6197,
20_30:4795,
30_40:6800,
40_50:80328,
50_inf:73]
Benchmark (clusterSize) (fsync) (partitionCount)
Mode Cnt Score Error Units
MyInsertBenchmarkWithMetrics.kvInsert 1false 2
avgt 200 7611,808 ± 695,469 us/op
MyInsertBenchmarkWithMetrics.kvInsert 1 true 2
avgt 200 7681,789 ± 433,490 us/op
{code}
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java, MyInsertBenchmarkWithMetrics.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation
[jira] [Commented] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847377#comment-17847377
]
Vladislav Pyatkov commented on IGNITE-15568:
{code}
New
Raft metrics:
raft.logmanager.disruptor.Batch: [
0_10:2487232,
10_20:5693,
20_30:2096,
30_40:574,
40_50:295,
50_inf:4]
Benchmark (clusterSize) (fsync) (partitionCount)
Mode Cnt Score Error Units
MyInsertBenchmarkWithMetrics.kvInsert 1false 2
avgt 200 6723,882 ± 639,991 us/op
MyInsertBenchmarkWithMetrics.kvInsert 1 true 2
avgt 200 7722,169 ± 504,716 us/op
Old
raft.logmanager.disruptor.Batch: [
0_10:2788769,
10_20:8218,
20_30:4532,
30_40:1579,
40_50:782,
50_inf:61]
raft.nodeimpl.disruptor.Batch: [
0_10:3274036,
10_20:2066,
20_30:446,
30_40:128,
40_50:35,
50_inf:8]
raft.readonlyservice.disruptor.Batch: [
0_10:2,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
raft.fsmcaller.disruptor.Batch: [
0_10:9135,
10_20:6197,
20_30:4795,
30_40:6800,
40_50:80328,
50_inf:73]
Benchmark (clusterSize) (fsync) (partitionCount)
Mode Cnt Score Error Units
MyInsertBenchmarkWithMetrics.kvInsert 1false 2
avgt 200 7611,808 ± 695,469 us/op
MyInsertBenchmarkWithMetrics.kvInsert 1 true 2
avgt 200 7681,789 ± 433,490 us/op
{code}
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java, MyInsertBenchmarkWithMetrics.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
> to dhow increasing in case with high parallelism in one partition.
> There is [an example of the
> benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22280) Error "A critical thread is blocked" on restart
[
https://issues.apache.org/jira/browse/IGNITE-22280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor updated IGNITE-22280:
--
Attachment: image-2024-05-17-18-06-23-594.png
> Error "A critical thread is blocked" on restart
> ---
>
> Key: IGNITE-22280
> URL: https://issues.apache.org/jira/browse/IGNITE-22280
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 3.0.0-beta2
> Environment: 2 nodes (with arguments "-Xms4096m", "-Xmx4096m" ) on *1
> host*
> cpuCount=10
> memorySizeMb=15360
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
> Attachments: ignite3db-0-1.log, ignite3db-0.log,
> image-2024-05-17-17-57-18-759.png, image-2024-05-17-17-57-32-913.png,
> image-2024-05-17-17-58-12-428.png, image-2024-05-17-18-06-04-081.png,
> image-2024-05-17-18-06-23-594.png
>
>
> *Steps to reproduce:*
> # Start cluster of 2 nodes on single host.
> # Create 5 tables and insert 1000 rows into each.
> # Kill 1 server.
> # Start the killed server.
> # Check logs for errors.
> *Expected:*
> No errors in logs.
> *Actual:*
> Errors in logs
> {code:java}
> 2024-05-17 04:26:37:808 +
> [ERROR][%ClusterFailover2NodesTest_cluster_0%common-scheduler-0][CriticalWorkerWatchdog]
> A critical thread is blocked for 688 ms that is more than the allowed 500
> ms, it is "ClusterFailover2NodesTest_cluster_0-srv-worker-3" prio=10 Id=41
> RUNNABLE
> at
> app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:25)
> at
> app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:11)
> at
> app//org.apache.ignite.internal.network.netty.InboundDecoder.decode(InboundDecoder.java:136)
> at
> app//io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)
> at
> app//io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)
> at
> app//io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
> at
> app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
> at
> app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
> at
> app//io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
> at
> app//io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
> at
> app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
> at
> app//io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> app//io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at
> app//io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
> at
> app//io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
> at
> app//io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
> at app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
> at
> app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at
> app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base@17.0.6/java.lang.Thread.run(Thread.java:833) {code}
> GC calls of node ClusterFailover2NodesTest_cluster_0 (LOG: [^ignite3db-0.log])
> !image-2024-05-17-17-57-32-913.png! GC calls of node
> ClusterFailover2NodesTest_cluster_1 (LOG: [^ignite3db-0.log])
> !image-2024-05-17-17-58-12-428.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22280) Error "A critical thread is blocked" on restart
[
https://issues.apache.org/jira/browse/IGNITE-22280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor updated IGNITE-22280:
--
Description:
*Steps to reproduce:*
# Start cluster of 2 nodes on single host.
# Create 5 tables and insert 1000 rows into each.
# Kill 1 server.
# Start the killed server.
# Check logs for errors.
*Expected:*
No errors in logs.
*Actual:*
Errors in logs
{code:java}
2024-05-17 04:26:37:808 +
[ERROR][%ClusterFailover2NodesTest_cluster_0%common-scheduler-0][CriticalWorkerWatchdog]
A critical thread is blocked for 688 ms that is more than the allowed 500 ms,
it is "ClusterFailover2NodesTest_cluster_0-srv-worker-3" prio=10 Id=41 RUNNABLE
at
app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:25)
at
app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:11)
at
app//org.apache.ignite.internal.network.netty.InboundDecoder.decode(InboundDecoder.java:136)
at
app//io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)
at
app//io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)
at
app//io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
app//io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
app//io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
app//io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
app//io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
app//io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
at
app//io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at
app//io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
at app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at
app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at
app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base@17.0.6/java.lang.Thread.run(Thread.java:833) {code}
GC calls of node ClusterFailover2NodesTest_cluster_0 (LOG: [^ignite3db-0.log])
!image-2024-05-17-18-06-23-594.png! GC calls of node
ClusterFailover2NodesTest_cluster_1 (LOG: [^ignite3db-0.log])
!image-2024-05-17-18-06-04-081.png!
was:
*Steps to reproduce:*
# Start cluster of 2 nodes on single host.
# Create 5 tables and insert 1000 rows into each.
# Kill 1 server.
# Start the killed server.
# Check logs for errors.
*Expected:*
No errors in logs.
*Actual:*
Errors in logs
{code:java}
2024-05-17 04:26:37:808 +
[ERROR][%ClusterFailover2NodesTest_cluster_0%common-scheduler-0][CriticalWorkerWatchdog]
A critical thread is blocked for 688 ms that is more than the allowed 500 ms,
it is "ClusterFailover2NodesTest_cluster_0-srv-worker-3" prio=10 Id=41 RUNNABLE
at
app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:25)
at
app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:11)
at
app//org.apache.ignite.internal.network.netty.InboundDecoder.decode(InboundDecoder.java:136)
at
app//io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)
at
app//io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)
at
app//io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
app//io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
app//io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
app//io.netty.channel.Abst
[jira] [Updated] (IGNITE-22280) Error "A critical thread is blocked" on restart
[
https://issues.apache.org/jira/browse/IGNITE-22280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor updated IGNITE-22280:
--
Attachment: image-2024-05-17-18-06-04-081.png
> Error "A critical thread is blocked" on restart
> ---
>
> Key: IGNITE-22280
> URL: https://issues.apache.org/jira/browse/IGNITE-22280
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 3.0.0-beta2
> Environment: 2 nodes (with arguments "-Xms4096m", "-Xmx4096m" ) on *1
> host*
> cpuCount=10
> memorySizeMb=15360
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
> Attachments: ignite3db-0-1.log, ignite3db-0.log,
> image-2024-05-17-17-57-18-759.png, image-2024-05-17-17-57-32-913.png,
> image-2024-05-17-17-58-12-428.png, image-2024-05-17-18-06-04-081.png,
> image-2024-05-17-18-06-23-594.png
>
>
> *Steps to reproduce:*
> # Start cluster of 2 nodes on single host.
> # Create 5 tables and insert 1000 rows into each.
> # Kill 1 server.
> # Start the killed server.
> # Check logs for errors.
> *Expected:*
> No errors in logs.
> *Actual:*
> Errors in logs
> {code:java}
> 2024-05-17 04:26:37:808 +
> [ERROR][%ClusterFailover2NodesTest_cluster_0%common-scheduler-0][CriticalWorkerWatchdog]
> A critical thread is blocked for 688 ms that is more than the allowed 500
> ms, it is "ClusterFailover2NodesTest_cluster_0-srv-worker-3" prio=10 Id=41
> RUNNABLE
> at
> app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:25)
> at
> app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:11)
> at
> app//org.apache.ignite.internal.network.netty.InboundDecoder.decode(InboundDecoder.java:136)
> at
> app//io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)
> at
> app//io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)
> at
> app//io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
> at
> app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
> at
> app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
> at
> app//io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
> at
> app//io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
> at
> app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
> at
> app//io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> app//io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at
> app//io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
> at
> app//io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
> at
> app//io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
> at app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
> at
> app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at
> app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base@17.0.6/java.lang.Thread.run(Thread.java:833) {code}
> GC calls of node ClusterFailover2NodesTest_cluster_0 (LOG: [^ignite3db-0.log])
> !image-2024-05-17-17-57-32-913.png! GC calls of node
> ClusterFailover2NodesTest_cluster_1 (LOG: [^ignite3db-0.log])
> !image-2024-05-17-17-58-12-428.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22280) Error "A critical thread is blocked" on restart
[
https://issues.apache.org/jira/browse/IGNITE-22280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor updated IGNITE-22280:
--
Description:
*Steps to reproduce:*
# Start cluster of 2 nodes on single host.
# Create 5 tables and insert 1000 rows into each.
# Kill 1 server.
# Start the killed server.
# Check logs for errors.
*Expected:*
No errors in logs.
*Actual:*
Errors in logs
{code:java}
2024-05-17 04:26:37:808 +
[ERROR][%ClusterFailover2NodesTest_cluster_0%common-scheduler-0][CriticalWorkerWatchdog]
A critical thread is blocked for 688 ms that is more than the allowed 500 ms,
it is "ClusterFailover2NodesTest_cluster_0-srv-worker-3" prio=10 Id=41 RUNNABLE
at
app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:25)
at
app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:11)
at
app//org.apache.ignite.internal.network.netty.InboundDecoder.decode(InboundDecoder.java:136)
at
app//io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)
at
app//io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)
at
app//io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
app//io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
app//io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
app//io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
app//io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
app//io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
at
app//io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at
app//io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
at app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at
app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at
app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base@17.0.6/java.lang.Thread.run(Thread.java:833) {code}
GC calls of node ClusterFailover2NodesTest_cluster_0 (LOG: [^ignite3db-0.log])
!image-2024-05-17-17-57-32-913.png! GC calls of node
ClusterFailover2NodesTest_cluster_1 (LOG: [^ignite3db-0.log])
!image-2024-05-17-17-58-12-428.png!
was:
*Steps to reproduce:*
# Start cluster of 2 nodes on single host.
# Insert create 5 tables and insert 1000 rows into each.
# Kill 1 server.
# Start the killed server.
# Check logs for errors.
*Expected:*
No errors in logs.
*Actual:*
Errors in logs
{code:java}
2024-05-17 04:26:37:808 +
[ERROR][%ClusterFailover2NodesTest_cluster_0%common-scheduler-0][CriticalWorkerWatchdog]
A critical thread is blocked for 688 ms that is more than the allowed 500 ms,
it is "ClusterFailover2NodesTest_cluster_0-srv-worker-3" prio=10 Id=41 RUNNABLE
at
app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:25)
at
app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:11)
at
app//org.apache.ignite.internal.network.netty.InboundDecoder.decode(InboundDecoder.java:136)
at
app//io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)
at
app//io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)
at
app//io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
app//io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
app//io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
app//io.netty.chann
[jira] [Created] (IGNITE-22280) Error "A critical thread is blocked" on restart
Igor created IGNITE-22280:
-
Summary: Error "A critical thread is blocked" on restart
Key: IGNITE-22280
URL: https://issues.apache.org/jira/browse/IGNITE-22280
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 3.0.0-beta2
Environment: 2 nodes (with arguments "-Xms4096m", "-Xmx4096m" ) on *1
host*
cpuCount=10
memorySizeMb=15360
Reporter: Igor
Attachments: ignite3db-0-1.log, ignite3db-0.log,
image-2024-05-17-17-57-18-759.png, image-2024-05-17-17-57-32-913.png,
image-2024-05-17-17-58-12-428.png
*Steps to reproduce:*
# Start cluster of 2 nodes on single host.
# Insert create 5 tables and insert 1000 rows into each.
# Kill 1 server.
# Start the killed server.
# Check logs for errors.
*Expected:*
No errors in logs.
*Actual:*
Errors in logs
{code:java}
2024-05-17 04:26:37:808 +
[ERROR][%ClusterFailover2NodesTest_cluster_0%common-scheduler-0][CriticalWorkerWatchdog]
A critical thread is blocked for 688 ms that is more than the allowed 500 ms,
it is "ClusterFailover2NodesTest_cluster_0-srv-worker-3" prio=10 Id=41 RUNNABLE
at
app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:25)
at
app//org.apache.ignite.internal.network.message.InvokeResponseDeserializer.getMessage(InvokeResponseDeserializer.java:11)
at
app//org.apache.ignite.internal.network.netty.InboundDecoder.decode(InboundDecoder.java:136)
at
app//io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)
at
app//io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)
at
app//io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
app//io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
app//io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at
app//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
app//io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
app//io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
app//io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
at
app//io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
at
app//io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
at app//io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at
app//io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at
app//io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
app//io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base@17.0.6/java.lang.Thread.run(Thread.java:833) {code}
GC calls of node ClusterFailover2NodesTest_cluster_0 (LOG: [^ignite3db-0.log])
!image-2024-05-17-17-57-32-913.png! GC calls of node
ClusterFailover2NodesTest_cluster_1 (LOG: [^ignite3db-0.log])
!image-2024-05-17-17-58-12-428.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22275) Avoid partition number change
[
https://issues.apache.org/jira/browse/IGNITE-22275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov updated IGNITE-22275:
Description:
*Motivation*
In fact, due to many reasons (for example we can't rebalance data between
different RAFT groups and etc.) we can't support the partitions number change
in the zone.
Earlier, when the alter zone was the configuration change - we used the
{{@Immutable}} configuration validation around the partition filed. But now,
after migration to the catalog approach - we loose this guard.
So, we need to implement the any kind of guard to prohibit partitions number
changes.
*Definition of done*
- There is no any public API (DDLs and etc.), where we can change the number
of partitions
*Implementation notes*
- Avoid partitions change in the command and check if the error will be user
friendly
[https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/catalog/src/main/java/org/apache/ignite/internal/catalog/commands/AlterZoneCommand.java#L146]
- Also, if the previous error will be ugly, we can remove the {{partitions}}
option from the alterZoneOptions
[here|https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/prepare/ddl/DdlSqlToCommandConverter.java#L189]
was:
*Motivation*
In fact, due to many reasons (for example we can't rebalance data between
different RAFT groups and etc.) we can't support the partitions number change
in the zone.
Earlier, when the alter zone was the configuration change - we used the
{{@Immutable}} configuration validation around the partition filed. But now,
after migration to the catalog approach - we loose this guard.
So, we need to implement the any kind of guard to prohibit partitions number
changes.
*Definition of done*
- There is no any public API (DDLs and etc.), where we can change the number
of partitions
*Implementation notes*
- Avoid partitions change in the command and check if the error will be user
friendly
https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/catalog/src/main/java/org/apache/ignite/internal/catalog/commands/AlterZoneCommand.java#L146
- We can remove the {{partitions}} option from the alterZoneOptions
[here|https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/prepare/ddl/DdlSqlToCommandConverter.java#L189]
> Avoid partition number change
> -
>
> Key: IGNITE-22275
> URL: https://issues.apache.org/jira/browse/IGNITE-22275
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Priority: Major
>
> *Motivation*
> In fact, due to many reasons (for example we can't rebalance data between
> different RAFT groups and etc.) we can't support the partitions number change
> in the zone.
> Earlier, when the alter zone was the configuration change - we used the
> {{@Immutable}} configuration validation around the partition filed. But now,
> after migration to the catalog approach - we loose this guard.
> So, we need to implement the any kind of guard to prohibit partitions number
> changes.
> *Definition of done*
> - There is no any public API (DDLs and etc.), where we can change the number
> of partitions
> *Implementation notes*
> - Avoid partitions change in the command and check if the error will be user
> friendly
> [https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/catalog/src/main/java/org/apache/ignite/internal/catalog/commands/AlterZoneCommand.java#L146]
> - Also, if the previous error will be ugly, we can remove the {{partitions}}
> option from the alterZoneOptions
> [here|https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/prepare/ddl/DdlSqlToCommandConverter.java#L189]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22275) Avoid partition number change
[
https://issues.apache.org/jira/browse/IGNITE-22275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov updated IGNITE-22275:
Description:
*Motivation*
In fact, due to many reasons (for example we can't rebalance data between
different RAFT groups and etc.) we can't support the partitions number change
in the zone.
Earlier, when the alter zone was the configuration change - we used the
{{@Immutable}} configuration validation around the partition filed. But now,
after migration to the catalog approach - we loose this guard.
So, we need to implement the any kind of guard to prohibit partitions number
changes.
*Definition of done*
- There is no any public API (DDLs and etc.), where we can change the number
of partitions
*Implementation notes*
- Avoid partitions change in the command and check if the error will be user
friendly
https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/catalog/src/main/java/org/apache/ignite/internal/catalog/commands/AlterZoneCommand.java#L146
- We can remove the {{partitions}} option from the alterZoneOptions
[here|https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/prepare/ddl/DdlSqlToCommandConverter.java#L189]
was:
*Motivation*
In fact, due to many reasons (for example we can't rebalance data between
different RAFT groups and etc.) we can't support the partitions number change
in the zone.
Earlier, when the alter zone was the configuration change - we used the
\{{@Immutable}} configuration validation around the partition filed. But now,
after migration to the catalog approach - we loose this guard.
So, we need to implement the any kind of guard to prohibit partitions number
changes.
*Definition of done*
- There is no any public API (DDLs and etc.), where we can change the number of
partitions
*Implementation notes*
We can remove the {{partitions}} option from the alterZoneOptions
[here|https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/prepare/ddl/DdlSqlToCommandConverter.java#L189]
> Avoid partition number change
> -
>
> Key: IGNITE-22275
> URL: https://issues.apache.org/jira/browse/IGNITE-22275
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Priority: Major
>
> *Motivation*
> In fact, due to many reasons (for example we can't rebalance data between
> different RAFT groups and etc.) we can't support the partitions number change
> in the zone.
> Earlier, when the alter zone was the configuration change - we used the
> {{@Immutable}} configuration validation around the partition filed. But now,
> after migration to the catalog approach - we loose this guard.
> So, we need to implement the any kind of guard to prohibit partitions number
> changes.
> *Definition of done*
> - There is no any public API (DDLs and etc.), where we can change the number
> of partitions
> *Implementation notes*
> - Avoid partitions change in the command and check if the error will be user
> friendly
> https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/catalog/src/main/java/org/apache/ignite/internal/catalog/commands/AlterZoneCommand.java#L146
> - We can remove the {{partitions}} option from the alterZoneOptions
> [here|https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/prepare/ddl/DdlSqlToCommandConverter.java#L189]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19544) Thin 3.0: Data Streamer with Receiver
[ https://issues.apache.org/jira/browse/IGNITE-19544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19544: Description: Implement data streamer with receiver in Java client - see [IEP-121|https://cwiki.apache.org/confluence/display/IGNITE/IEP-121%3A+Data+Streamer+with+Receiver] (was: Implement data streamer with receiver in Java client - see Use Case 2 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer].) > Thin 3.0: Data Streamer with Receiver > - > > Key: IGNITE-19544 > URL: https://issues.apache.org/jira/browse/IGNITE-19544 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, iep-121, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement data streamer with receiver in Java client - see > [IEP-121|https://cwiki.apache.org/confluence/display/IGNITE/IEP-121%3A+Data+Streamer+with+Receiver] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22279) Missed comments in PR IGNITE-22130
[
https://issues.apache.org/jira/browse/IGNITE-22279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-22279:
---
Description:
https://github.com/apache/ignite-3/pull/3704
Motivation
{code}
if (retryExecutor != null && matchAny(unwrapCause(errResp.throwable()),
ACQUIRE_LOCK_ERR, REPLICA_MISS_ERR)) {
retryExecutor.schedule(
// Need to resubmit again to pool which is
valid for synchronous IO execution.
() ->
partitionOperationsExecutor.execute(() ->
res.completeExceptionally(errResp.throwable())),
RETRY_TIMEOUT_MILLIS, MILLISECONDS);
}
{code}
was:https://github.com/apache/ignite-3/pull/3704
> Missed comments in PR IGNITE-22130
> --
>
> Key: IGNITE-22279
> URL: https://issues.apache.org/jira/browse/IGNITE-22279
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> https://github.com/apache/ignite-3/pull/3704
> Motivation
> {code}
> if (retryExecutor != null && matchAny(unwrapCause(errResp.throwable()),
> ACQUIRE_LOCK_ERR, REPLICA_MISS_ERR)) {
> retryExecutor.schedule(
> // Need to resubmit again to pool which
> is valid for synchronous IO execution.
> () ->
> partitionOperationsExecutor.execute(() ->
> res.completeExceptionally(errResp.throwable())),
> RETRY_TIMEOUT_MILLIS, MILLISECONDS);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22279) Missed comments in PR IGNITE-22130
[
https://issues.apache.org/jira/browse/IGNITE-22279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-22279:
---
Description:
https://github.com/apache/ignite-3/pull/3704
h3. Motivation
{code}
if (retryExecutor != null && matchAny(unwrapCause(errResp.throwable()),
ACQUIRE_LOCK_ERR, REPLICA_MISS_ERR)) {
retryExecutor.schedule(
// Need to resubmit again to pool which is
valid for synchronous IO execution.
() ->
partitionOperationsExecutor.execute(() ->
res.completeExceptionally(errResp.throwable())),
RETRY_TIMEOUT_MILLIS, MILLISECONDS);
}
{code}
was:
https://github.com/apache/ignite-3/pull/3704
Motivation
{code}
if (retryExecutor != null && matchAny(unwrapCause(errResp.throwable()),
ACQUIRE_LOCK_ERR, REPLICA_MISS_ERR)) {
retryExecutor.schedule(
// Need to resubmit again to pool which is
valid for synchronous IO execution.
() ->
partitionOperationsExecutor.execute(() ->
res.completeExceptionally(errResp.throwable())),
RETRY_TIMEOUT_MILLIS, MILLISECONDS);
}
{code}
> Missed comments in PR IGNITE-22130
> --
>
> Key: IGNITE-22279
> URL: https://issues.apache.org/jira/browse/IGNITE-22279
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> https://github.com/apache/ignite-3/pull/3704
> h3. Motivation
> {code}
> if (retryExecutor != null && matchAny(unwrapCause(errResp.throwable()),
> ACQUIRE_LOCK_ERR, REPLICA_MISS_ERR)) {
> retryExecutor.schedule(
> // Need to resubmit again to pool which
> is valid for synchronous IO execution.
> () ->
> partitionOperationsExecutor.execute(() ->
> res.completeExceptionally(errResp.throwable())),
> RETRY_TIMEOUT_MILLIS, MILLISECONDS);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22279) Missed comments in PR IGNITE-22130
Vladislav Pyatkov created IGNITE-22279: -- Summary: Missed comments in PR IGNITE-22130 Key: IGNITE-22279 URL: https://issues.apache.org/jira/browse/IGNITE-22279 Project: Ignite Issue Type: Bug Reporter: Vladislav Pyatkov https://github.com/apache/ignite-3/pull/3704 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847319#comment-17847319
]
Vladislav Pyatkov edited comment on IGNITE-15568 at 5/17/24 1:56 PM:
-
It was just like it was. I did not edit the old code before the benchmark run.
was (Author: v.pyatkov):
It was just like it was. I do not edit the old code.
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java, MyInsertBenchmarkWithMetrics.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
> to dhow increasing in case with high parallelism in one partition.
> There is [an example of the
> benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847319#comment-17847319
]
Vladislav Pyatkov commented on IGNITE-15568:
It was just like it was. I do not edit the old code.
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java, MyInsertBenchmarkWithMetrics.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
> to dhow increasing in case with high parallelism in one partition.
> There is [an example of the
> benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22278) Sql. Refactor base and planning context
Konstantin Orlov created IGNITE-22278: - Summary: Sql. Refactor base and planning context Key: IGNITE-22278 URL: https://issues.apache.org/jira/browse/IGNITE-22278 Project: Ignite Issue Type: Improvement Components: sql Reporter: Konstantin Orlov Purpose of the BaseQueryContext is not clear. On the one hand, it contains meta required to kick start the query execution, on the other -- it contains framework configuration which is specific only for planning phase. Let's remove BasicContext and introduce OperationContext instead. All planning related part should be moved to PlanningContext. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22278) Sql. Refactor base and planning context
[ https://issues.apache.org/jira/browse/IGNITE-22278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-22278: -- Fix Version/s: 3.0.0-beta2 > Sql. Refactor base and planning context > --- > > Key: IGNITE-22278 > URL: https://issues.apache.org/jira/browse/IGNITE-22278 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Purpose of the BaseQueryContext is not clear. On the one hand, it contains > meta required to kick start the query execution, on the other -- it contains > framework configuration which is specific only for planning phase. Let's > remove BasicContext and introduce OperationContext instead. All planning > related part should be moved to PlanningContext. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22278) Sql. Refactor base and planning context
[ https://issues.apache.org/jira/browse/IGNITE-22278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-22278: - Assignee: Konstantin Orlov > Sql. Refactor base and planning context > --- > > Key: IGNITE-22278 > URL: https://issues.apache.org/jira/browse/IGNITE-22278 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Purpose of the BaseQueryContext is not clear. On the one hand, it contains > meta required to kick start the query execution, on the other -- it contains > framework configuration which is specific only for planning phase. Let's > remove BasicContext and introduce OperationContext instead. All planning > related part should be moved to PlanningContext. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22207) Handling of AwaitPrimaryReplica request maight lead to the dedalock
[
https://issues.apache.org/jira/browse/IGNITE-22207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847310#comment-17847310
]
Kirill Sizov edited comment on IGNITE-22207 at 5/17/24 1:45 PM:
-
The solution would be to avoid any activity inside
{{ReplicaService.pendingInvokes}}, in that case we will never have a case when
one holds a pendingInvokes monitor and tries to take another one.
In other words we need to take network invoke method out of computeIfAbsent.
was (Author: JIRAUSER301198):
The solution would be to avoid any activity inside
{{ReplicaService.pendingInvokes}}, in that case we will never have a case when
one holds a pendingInvokes monitor and tries to take another one.
In other words we need to take network invoke out of computeIfAbsent.
> Handling of AwaitPrimaryReplica request maight lead to the dedalock
> ---
>
> Key: IGNITE-22207
> URL: https://issues.apache.org/jira/browse/IGNITE-22207
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> We handle ReplicaUnavailableException in ReplicaService to handle request
> transparency even if the replica had not been read at the time the request
> was sent. To do this, we send AwaitReplicaRequest as a handling of the
> exception and then process the origin request when the replica is guaranteed
> ready.
> In the event that the AwaitReplicaRequest is handled locally, we will do it
> synchronously in pendingInvokes.computeIfAbsent:
> {code}
> CompletableFuture awaitReplicaFut =
> pendingInvokes.computeIfAbsent(
> targetNodeConsistentId,
> consistentId -> {
> AwaitReplicaRequest awaitReplicaReq =
> REPLICA_MESSAGES_FACTORY.awaitReplicaRequest()
> .groupId(req.groupId())
> .build();
> return messagingService.invoke(
> targetNodeConsistentId,
> awaitReplicaReq,
> replicationConfiguration.rpcTimeout().value()
> );
> }
> );
> {code}
> and then hands on handling of AwaitReplicaRequest, due to removing from
> pendingInvokes:
> {code}
> awaitReplicaFut.handle((response0, throwable0) -> {
> pendingInvokes.remove(targetNodeConsistentId, awaitReplicaFut);
> ...
> {code}
> h3. Definition of doe
> Take out of the network invokation from the map compute closure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22207) Handling of AwaitPrimaryReplica request maight lead to the dedalock
[
https://issues.apache.org/jira/browse/IGNITE-22207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847310#comment-17847310
]
Kirill Sizov commented on IGNITE-22207:
The solution would be to avoid any activity inside
{{ReplicaService.pendingInvokes}}, in that case we will never have a case when
one holds a pendingInvokes monitor and tries to take another one.
In other words we need to take network invoke out of computeIfAbsent.
> Handling of AwaitPrimaryReplica request maight lead to the dedalock
> ---
>
> Key: IGNITE-22207
> URL: https://issues.apache.org/jira/browse/IGNITE-22207
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> We handle ReplicaUnavailableException in ReplicaService to handle request
> transparency even if the replica had not been read at the time the request
> was sent. To do this, we send AwaitReplicaRequest as a handling of the
> exception and then process the origin request when the replica is guaranteed
> ready.
> In the event that the AwaitReplicaRequest is handled locally, we will do it
> synchronously in pendingInvokes.computeIfAbsent:
> {code}
> CompletableFuture awaitReplicaFut =
> pendingInvokes.computeIfAbsent(
> targetNodeConsistentId,
> consistentId -> {
> AwaitReplicaRequest awaitReplicaReq =
> REPLICA_MESSAGES_FACTORY.awaitReplicaRequest()
> .groupId(req.groupId())
> .build();
> return messagingService.invoke(
> targetNodeConsistentId,
> awaitReplicaReq,
> replicationConfiguration.rpcTimeout().value()
> );
> }
> );
> {code}
> and then hands on handling of AwaitReplicaRequest, due to removing from
> pendingInvokes:
> {code}
> awaitReplicaFut.handle((response0, throwable0) -> {
> pendingInvokes.remove(targetNodeConsistentId, awaitReplicaFut);
> ...
> {code}
> h3. Definition of doe
> Take out of the network invokation from the map compute closure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22275) Avoid partition number change
[
https://issues.apache.org/jira/browse/IGNITE-22275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov updated IGNITE-22275:
Description:
*Motivation*
In fact, due to many reasons (for example we can't rebalance data between
different RAFT groups and etc.) we can't support the partitions number change
in the zone.
Earlier, when the alter zone was the configuration change - we used the
\{{@Immutable}} configuration validation around the partition filed. But now,
after migration to the catalog approach - we loose this guard.
So, we need to implement the any kind of guard to prohibit partitions number
changes.
*Definition of done*
- There is no any public API (DDLs and etc.), where we can change the number of
partitions
*Implementation notes*
We can remove the {{partitions}} option from the alterZoneOptions
[here|https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/prepare/ddl/DdlSqlToCommandConverter.java#L189]
> Avoid partition number change
> -
>
> Key: IGNITE-22275
> URL: https://issues.apache.org/jira/browse/IGNITE-22275
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Priority: Major
>
> *Motivation*
> In fact, due to many reasons (for example we can't rebalance data between
> different RAFT groups and etc.) we can't support the partitions number change
> in the zone.
> Earlier, when the alter zone was the configuration change - we used the
> \{{@Immutable}} configuration validation around the partition filed. But now,
> after migration to the catalog approach - we loose this guard.
> So, we need to implement the any kind of guard to prohibit partitions number
> changes.
> *Definition of done*
> - There is no any public API (DDLs and etc.), where we can change the number
> of partitions
> *Implementation notes*
> We can remove the {{partitions}} option from the alterZoneOptions
> [here|https://github.com/apache/ignite-3/blob/c41d3e2d46bd2f717fda4f9fe02b18abca08e98a/modules/sql-engine/src/main/java/org/apache/ignite/internal/sql/engine/prepare/ddl/DdlSqlToCommandConverter.java#L189]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22207) Handling of AwaitPrimaryReplica request maight lead to the dedalock
[
https://issues.apache.org/jira/browse/IGNITE-22207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847308#comment-17847308
]
Kirill Sizov commented on IGNITE-22207:
There is a deadlock between {{ReplicaService.pendingInvokes}} and
{{ReplicaManager.replicas}}
See threaddump:
{noformat}
"%sqllogic0%low-watermark-updater-0" #273 prio=5 os_prio=0 cpu=1503.23ms
elapsed=2391.82s tid=0x7fd3492b1000 nid=0x2527f6 waiting for monitor entry
[0x7fd28987]
java.lang.Thread.State: BLOCKED (on object monitor)
at
java.util.concurrent.ConcurrentHashMap.replaceNode(java.base@11.0.17/ConcurrentHashMap.java:1122)
- waiting to lock <0x00071ab00178> (a
java.util.concurrent.ConcurrentHashMap$ReservationNode)
at
java.util.concurrent.ConcurrentHashMap.remove(java.base@11.0.17/ConcurrentHashMap.java:1552)
at
org.apache.ignite.internal.replicator.ReplicaService.lambda$sendToReplica$3(ReplicaService.java:167)
at
org.apache.ignite.internal.replicator.ReplicaService$$Lambda$3914/0x00080117c840.apply(Unknown
Source)
at
java.util.concurrent.CompletableFuture.uniHandle(java.base@11.0.17/CompletableFuture.java:930)
at
java.util.concurrent.CompletableFuture$UniHandle.tryFire(java.base@11.0.17/CompletableFuture.java:907)
at
java.util.concurrent.CompletableFuture.postComplete(java.base@11.0.17/CompletableFuture.java:506)
at
java.util.concurrent.CompletableFuture.complete(java.base@11.0.17/CompletableFuture.java:2073)
at
org.apache.ignite.internal.network.DefaultMessagingService.onInvokeResponse(DefaultMessagingService.java:524)
at
org.apache.ignite.internal.network.DefaultMessagingService.send0(DefaultMessagingService.java:240)
at
org.apache.ignite.internal.network.DefaultMessagingService.respond(DefaultMessagingService.java:183)
at
org.apache.ignite.internal.network.DefaultMessagingService.respond(DefaultMessagingService.java:196)
at
org.apache.ignite.internal.network.MessagingService.respond(MessagingService.java:142)
at
org.apache.ignite.internal.replicator.ReplicaManager.lambda$handleReplicaRequest$2(ReplicaManager.java:301)
at
org.apache.ignite.internal.replicator.ReplicaManager$$Lambda$3898/0x000801179040.accept(Unknown
Source)
at
java.util.concurrent.CompletableFuture.uniWhenComplete(java.base@11.0.17/CompletableFuture.java:859)
at
java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(java.base@11.0.17/CompletableFuture.java:837)
at
java.util.concurrent.CompletableFuture.postComplete(java.base@11.0.17/CompletableFuture.java:506)
at
java.util.concurrent.CompletableFuture.completeExceptionally(java.base@11.0.17/CompletableFuture.java:2088)
at
org.apache.ignite.internal.replicator.ReplicaManager.lambda$stopReplicaInternal$17(ReplicaManager.java:630)
at
org.apache.ignite.internal.replicator.ReplicaManager$$Lambda$4502/0x000801292040.apply(Unknown
Source)
at
java.util.concurrent.ConcurrentHashMap.compute(java.base@11.0.17/ConcurrentHashMap.java:1932)
- locked <0x000719f589f8> (a
java.util.concurrent.ConcurrentHashMap$Node)
at
org.apache.ignite.internal.replicator.ReplicaManager.lambda$stopReplicaInternal$18(ReplicaManager.java:624)
at
org.apache.ignite.internal.replicator.ReplicaManager$$Lambda$4501/0x000801291c40.accept(Unknown
Source)
at
java.util.concurrent.CompletableFuture.uniWhenComplete(java.base@11.0.17/CompletableFuture.java:859)
at
java.util.concurrent.CompletableFuture.uniWhenCompleteStage(java.base@11.0.17/CompletableFuture.java:883)
at
java.util.concurrent.CompletableFuture.whenComplete(java.base@11.0.17/CompletableFuture.java:2251)
at
org.apache.ignite.internal.replicator.ReplicaManager.stopReplicaInternal(ReplicaManager.java:612)
at
org.apache.ignite.internal.replicator.ReplicaManager.stopReplica(ReplicaManager.java:595)
at
org.apache.ignite.internal.table.distributed.TableManager.stopPartition(TableManager.java:2413)
at
org.apache.ignite.internal.table.distributed.TableManager.destroyTableLocally(TableManager.java:1519)
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$onLwmChanged$22(TableManager.java:807)
at
org.apache.ignite.internal.table.distributed.TableManager$$Lambda$3174/0x000800ffc040.apply(Unknown
Source)
at
java.util.stream.ReferencePipeline$3$1.accept(java.base@11.0.17/ReferencePipeline.java:195)
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(java.base@11.0.17/ArrayList.java:1655)
at
java.util.stream.AbstractPipeline.copyInto(java.base@11.0.17/AbstractPipeline.java:484)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(java.base@11.0.17/AbstractPipeline.java:474)
at
java
[jira] [Updated] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-22089: Description: To remove MVCC code from Yardstick. Classes to delete: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark - NativeJavaApiPutRemoveBenchmark was: To remove MVCC code from Yardstick. To delete classes: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark - NativeJavaApiPutRemoveBenchmark > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > To remove MVCC code from Yardstick. Classes to delete: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark > - NativeJavaApiPutRemoveBenchmark -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22277) Remove Zone annotation from Catalog API
Pavel Tupitsyn created IGNITE-22277: --- Summary: Remove Zone annotation from Catalog API Key: IGNITE-22277 URL: https://issues.apache.org/jira/browse/IGNITE-22277 Project: Ignite Issue Type: Improvement Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 Zone annotation does not make much sense - it goes on an empty class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22276) Catalog API allows an index without columns
Pavel Tupitsyn created IGNITE-22276: --- Summary: Catalog API allows an index without columns Key: IGNITE-22276 URL: https://issues.apache.org/jira/browse/IGNITE-22276 Project: Ignite Issue Type: Bug Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22276) Catalog API allows an index without columns
[
https://issues.apache.org/jira/browse/IGNITE-22276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22276:
Description:
This code produces a SQL parse error:
{code:java}
var person2Table = ignite.catalog().createTable(
TableDefinition.builder("Person2")
.key(PersonKey.class)
.value(PersonValue.class)
.index("height", IndexType.DEFAULT)
.zone("Zone2")
.build()
).execute();
{code}
> Catalog API allows an index without columns
> ---
>
> Key: IGNITE-22276
> URL: https://issues.apache.org/jira/browse/IGNITE-22276
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> This code produces a SQL parse error:
> {code:java}
>var person2Table = ignite.catalog().createTable(
>TableDefinition.builder("Person2")
>.key(PersonKey.class)
>.value(PersonValue.class)
>.index("height", IndexType.DEFAULT)
>.zone("Zone2")
>.build()
>).execute();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22275) Avoid partition number change
Kirill Gusakov created IGNITE-22275: --- Summary: Avoid partition number change Key: IGNITE-22275 URL: https://issues.apache.org/jira/browse/IGNITE-22275 Project: Ignite Issue Type: Improvement Reporter: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22274) Remove o.a.i.catalog.Options
[ https://issues.apache.org/jira/browse/IGNITE-22274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22274: Description: *org.apache.ignite.catalog.Options* affects generated SQL, but it provides no value to the user. SQL is an implementation detail of Catalog API. > Remove o.a.i.catalog.Options > > > Key: IGNITE-22274 > URL: https://issues.apache.org/jira/browse/IGNITE-22274 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *org.apache.ignite.catalog.Options* affects generated SQL, but it provides no > value to the user. SQL is an implementation detail of Catalog API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22274) Remove o.a.i.catalog.Options
Pavel Tupitsyn created IGNITE-22274: --- Summary: Remove o.a.i.catalog.Options Key: IGNITE-22274 URL: https://issues.apache.org/jira/browse/IGNITE-22274 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22273) Use PUBLIC as default schema in catalog API
Pavel Tupitsyn created IGNITE-22273: --- Summary: Use PUBLIC as default schema in catalog API Key: IGNITE-22273 URL: https://issues.apache.org/jira/browse/IGNITE-22273 Project: Ignite Issue Type: Improvement Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22272) Rework Catalog API
[ https://issues.apache.org/jira/browse/IGNITE-22272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22272: Description: * Do not return a Query that has to be executed, run it immediately. For example: *Table table = catalog.createTable(Pojo.class)* * All methods should be async-first * Rename *create* to *createTable* (recordClass and KV methods) * all *createTable* methods should return a *Table*. Especially important for record and KV cases, where the resulting name is not obvious was: * All methods should be async-first * Rename *create* to *createTable* (recordClass and KV methods) * all *createTable* methods should return a *Table*. Especially important for record and KV cases, where the resulting name is not obvious > Rework Catalog API > -- > > Key: IGNITE-22272 > URL: https://issues.apache.org/jira/browse/IGNITE-22272 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > * Do not return a Query that has to be executed, run it immediately. For > example: *Table table = catalog.createTable(Pojo.class)* > * All methods should be async-first > * Rename *create* to *createTable* (recordClass and KV methods) > * all *createTable* methods should return a *Table*. Especially important for > record and KV cases, where the resulting name is not obvious -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22272) Rework Catalog API
[ https://issues.apache.org/jira/browse/IGNITE-22272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22272: Description: * All methods should be async-first * Rename *create* to *createTable* (recordClass and KV methods) * all *createTable* methods should return a *Table*. Especially important for record and KV cases, where the resulting name is not obvious > Rework Catalog API > -- > > Key: IGNITE-22272 > URL: https://issues.apache.org/jira/browse/IGNITE-22272 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > * All methods should be async-first > * Rename *create* to *createTable* (recordClass and KV methods) > * all *createTable* methods should return a *Table*. Especially important for > record and KV cases, where the resulting name is not obvious -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22272) Rework Catalog API
Pavel Tupitsyn created IGNITE-22272: --- Summary: Rework Catalog API Key: IGNITE-22272 URL: https://issues.apache.org/jira/browse/IGNITE-22272 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847276#comment-17847276
]
Alexey Scherbakov commented on IGNITE-15568:
This result doesn't make sense to me as well.
"Old distruptor' (without optimization) should have batches only of size=1
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java, MyInsertBenchmarkWithMetrics.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
> to dhow increasing in case with high parallelism in one partition.
> There is [an example of the
> benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847263#comment-17847263
]
Vladislav Pyatkov edited comment on IGNITE-15568 at 5/17/24 12:27 PM:
--
I think the previous one also has a sense, because it shows we do not degrade
performance.
I have attached a new one: [^MyInsertBenchmarkWithMetrics.java]
Here is the result from my laptop:
{code}
Old disruptor
Benchmark (clusterSize) (fsync) (partitionCount) Mode Cnt
Score Error Units
InsertBenchmark.kvInsert 1false 2 avgt 200
6821,523 ± 1190,279 us/op
InsertBenchmark.kvInsert 1 true 2 avgt 200
8172,433 ± 294,077 us/op
raft.fsmcaller.disruptor.Batch:[
0_10:29890,
10_20:71825,
20_30:37548,
30_40:9062,
40_50:1428,
50_inf:2]
raft.logmanager.disruptor.Batch:[
0_10:32324,
10_20:48196,
20_30:53466,
30_40:8831,
40_50:1081,
50_inf:26]
raft.nodeimpl.disruptor.Batch:[
0_10:1804447,
10_20:1205,
20_30:122,
30_40:27,
40_50:14,
50_inf:0]
raft.readonlyservice.disruptor.Batch:[
0_10:6,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
New disruptor
Benchmark (clusterSize) (fsync) (partitionCount) Mode Cnt
Score Error Units
InsertBenchmark.kvInsert 1false 2 avgt 200
7357,067 ± 640,983 us/op
InsertBenchmark.kvInsert 1 true 2 avgt 200
8015,733 ± 469,096 us/op
raft:
raft.fsmcaller.disruptor.Batch:[
0_10:177419,
10_20:78244,
20_30:2549,
30_40:8,
40_50:0,
50_inf:0]
raft.logmanager.disruptor.Batch:[
0_10:71704,
10_20:76075,
20_30:26090,
30_40:1540,
40_50:44,
50_inf:0]
raft.nodeimpl.disruptor.Batch:[
0_10:2283394,
10_20:516,
20_30:52,
30_40:4,
40_50:0,
50_inf:0]
raft.readonlyservice.disruptor.Batch:[
0_10:6,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
{code}
was (Author: v.pyatkov):
I think the previous one also has a sense, because it shows we do not degrade
performance.
I have attached a new one: [^MyInsertBenchmarkWithMetrics.java]
Here is the result from my laptop:
{code}
Old
Benchmark (clusterSize) (fsync) (partitionCount) Mode Cnt
Score Error Units
InsertBenchmark.kvInsert 1false 2 avgt 200
6821,523 ± 1190,279 us/op
InsertBenchmark.kvInsert 1 true 2 avgt 200
8172,433 ± 294,077 us/op
raft.fsmcaller.disruptor.Batch:[
0_10:29890,
10_20:71825,
20_30:37548,
30_40:9062,
40_50:1428,
50_inf:2]
raft.logmanager.disruptor.Batch:[
0_10:32324,
10_20:48196,
20_30:53466,
30_40:8831,
40_50:1081,
50_inf:26]
raft.nodeimpl.disruptor.Batch:[
0_10:1804447,
10_20:1205,
20_30:122,
30_40:27,
40_50:14,
50_inf:0]
raft.readonlyservice.disruptor.Batch:[
0_10:6,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
New
Benchmark (clusterSize) (fsync) (partitionCount) Mode Cnt
Score Error Units
InsertBenchmark.kvInsert 1false 2 avgt 200
7357,067 ± 640,983 us/op
InsertBenchmark.kvInsert 1 true 2 avgt 200
8015,733 ± 469,096 us/op
raft:
raft.fsmcaller.disruptor.Batch:[
0_10:177419,
10_20:78244,
20_30:2549,
30_40:8,
40_50:0,
50_inf:0]
raft.logmanager.disruptor.Batch:[
0_10:71704,
10_20:76075,
20_30:26090,
30_40:1540,
40_50:44,
50_inf:0]
raft.nodeimpl.disruptor.Batch:[
0_10:2283394,
10_20:516,
20_30:52,
30_40:4,
40_50:0,
50_inf:0]
raft.readonlyservice.disruptor.Batch:[
0_10:6,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
{code}
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java, MyInsertBenchmarkWithMetrics.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> an
[jira] [Commented] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847263#comment-17847263
]
Vladislav Pyatkov commented on IGNITE-15568:
I think the previous one also has a sense, because it shows we do not degrade
performance.
I have attached a new one: [^MyInsertBenchmarkWithMetrics.java]
Here is the result from my laptop:
{code}
Old
Benchmark (clusterSize) (fsync) (partitionCount) Mode Cnt
Score Error Units
InsertBenchmark.kvInsert 1false 2 avgt 200
6821,523 ± 1190,279 us/op
InsertBenchmark.kvInsert 1 true 2 avgt 200
8172,433 ± 294,077 us/op
raft.fsmcaller.disruptor.Batch:[
0_10:29890,
10_20:71825,
20_30:37548,
30_40:9062,
40_50:1428,
50_inf:2]
raft.logmanager.disruptor.Batch:[
0_10:32324,
10_20:48196,
20_30:53466,
30_40:8831,
40_50:1081,
50_inf:26]
raft.nodeimpl.disruptor.Batch:[
0_10:1804447,
10_20:1205,
20_30:122,
30_40:27,
40_50:14,
50_inf:0]
raft.readonlyservice.disruptor.Batch:[
0_10:6,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
New
Benchmark (clusterSize) (fsync) (partitionCount) Mode Cnt
Score Error Units
InsertBenchmark.kvInsert 1false 2 avgt 200
7357,067 ± 640,983 us/op
InsertBenchmark.kvInsert 1 true 2 avgt 200
8015,733 ± 469,096 us/op
raft:
raft.fsmcaller.disruptor.Batch:[
0_10:177419,
10_20:78244,
20_30:2549,
30_40:8,
40_50:0,
50_inf:0]
raft.logmanager.disruptor.Batch:[
0_10:71704,
10_20:76075,
20_30:26090,
30_40:1540,
40_50:44,
50_inf:0]
raft.nodeimpl.disruptor.Batch:[
0_10:2283394,
10_20:516,
20_30:52,
30_40:4,
40_50:0,
50_inf:0]
raft.readonlyservice.disruptor.Batch:[
0_10:6,
10_20:0,
20_30:0,
30_40:0,
40_50:0,
50_inf:0]
{code}
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java, MyInsertBenchmarkWithMetrics.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
>
[jira] [Updated] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-15568:
---
Attachment: MyInsertBenchmarkWithMetrics.java
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java, MyInsertBenchmarkWithMetrics.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
> to dhow increasing in case with high parallelism in one partition.
> There is [an example of the
> benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847257#comment-17847257
]
Alexey Scherbakov commented on IGNITE-15568:
Proposed test scenario doesn't make sense to me.
We need at least 2 partitions and one stripe to see benefits from patch
improvement.
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key: IGNITE-15568
> URL: https://issues.apache.org/jira/browse/IGNITE-15568
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, performance
> Fix For: 3.0.0-beta2
>
> Attachments: InsertBenchmark.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> # Two raft groups are started and mapped to the same stripe.
> # Two LogEntryAndClosure events are added in quick succession so they form
> distruptor batch: first for group 1, second for group 2.
> First event is delivered to group 1 with endOfBatch=false, so it's cached in
> org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks
> and is not processed.
> Second event is delivered to group 2 with endOfBatch=true and processed, but
> first event will remain in queue unprocessed forever, because
> LogEntryAndClosureHandler are different instances per raft group.
> The possible WA for this is to set
> org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
> Reproducible by
> org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
> applyBatch=32 in ignite-15085 branch
> *Implementation notes*
> My proposal goes bound Disruptor. The striped disruptor implementation has an
> interceptor that proposes an event to a specific interceptor. Only the last
> event in the batch has a completion batch flag. For the other RAFT groups,
> which has been notified in the striped disruptor, required to create an event
> to fix a batch into the specific group. The new event will be created in the
> common striped disruptor interceptor, and it will send to a specific
> interceptor with flag about batch completion.
> The rule of handling the new event is differenced for various interceptor:
> {code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
> if (maxCommittedIndex >= 0) {
> doCommitted(maxCommittedIndex);
> return -1;
> }
> {code}
> {code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
> if (this.tasks.size() > 0) {
> executeApplyingTasks(this.tasks);
> this.tasks.clear();
> }
> {code}
> {code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
> if (this.events.size() > 0) {
> executeReadIndexEvents(this.events);
> this.events.clear();
> }
> {code}
> {code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
> if (this.ab.size > 0) {
> this.lastId = this.ab.flush();
> setDiskId(this.lastId);
> }
> {code}
> Also in bound of this issue, required to rerun benchmarks. Those are expected
> to dhow increasing in case with high parallelism in one partition.
> There is [an example of the
> benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19103) Sql. Change implicit primary key column's type to UUID.
[ https://issues.apache.org/jira/browse/IGNITE-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-19103: - Assignee: Maksim Zhuravkov > Sql. Change implicit primary key column's type to UUID. > --- > > Key: IGNITE-19103 > URL: https://issues.apache.org/jira/browse/IGNITE-19103 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: calcite3-required, ignite-3 > > Change implicit primary key column's type to UUID. Replace calls to > gen_random_uuid with calls to rand_uuid,`gen_random_uuid` function should be > removed. > As a part of this ticket update SQL grammar to make it possible to specify > function calls (without arguments) in for DEFAULT column values. Because at > the moment it looks like some functions that have no arguments can be called > with omitted parentheses and that is not the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21830) Add logging of connection check for each address
[
https://issues.apache.org/jira/browse/IGNITE-21830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847225#comment-17847225
]
Ignite TC Bot commented on IGNITE-21830:
{panel:title=Branch: [pull/11327/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11327/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}SPI (Discovery){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7871363]]
* {color:#013220}IgniteSpiDiscoverySelfTestSuite:
TcpDiscoveryNetworkIssuesTest.testBackwardConnectionCheckFailedLogMessage -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7871382&buildTypeId=IgniteTests24Java8_RunAll]
> Add logging of connection check for each address
>
>
> Key: IGNITE-21830
> URL: https://issues.apache.org/jira/browse/IGNITE-21830
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ilya Shishkov
>Assignee: Maksim Davydov
>Priority: Trivial
> Labels: ise, newbie
> Time Spent: 13h 20m
> Remaining Estimate: 0h
>
> Currently, exception thrown during checking of address is ignored [1]. It
> would be useful to print message with connection check summary including each
> address checking state and error message (if any).
> #
> https://github.com/apache/ignite/blob/7cd0c7a7d1150bbf6be6aae5efe80627a73757c0/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L7293
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22271) Rename copying overload of Tuple.create to copy
[ https://issues.apache.org/jira/browse/IGNITE-22271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22271: Description: *copy* is a more suitable name for *static Tuple create(Tuple tuple)* https://github.com/apache/ignite-3/blob/f6ce1ac450f5597582697adbcd967a7f702252ea/modules/api/src/main/java/org/apache/ignite/table/Tuple.java#L82 > Rename copying overload of Tuple.create to copy > --- > > Key: IGNITE-22271 > URL: https://issues.apache.org/jira/browse/IGNITE-22271 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *copy* is a more suitable name for *static Tuple create(Tuple tuple)* > https://github.com/apache/ignite-3/blob/f6ce1ac450f5597582697adbcd967a7f702252ea/modules/api/src/main/java/org/apache/ignite/table/Tuple.java#L82 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22271) Rename copying overload of Tuple.create to copy
Pavel Tupitsyn created IGNITE-22271: --- Summary: Rename copying overload of Tuple.create to copy Key: IGNITE-22271 URL: https://issues.apache.org/jira/browse/IGNITE-22271 Project: Ignite Issue Type: Improvement Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22269) UnexpectedNullValueException uses INTERNAL_ERR code
[ https://issues.apache.org/jira/browse/IGNITE-22269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22269: Description: *INTERNAL_ERR* does not make sense for *UnexpectedNullValueException* (was: INTERNAL_ERR does not make sense for UnexpectedNullValueException) > UnexpectedNullValueException uses INTERNAL_ERR code > --- > > Key: IGNITE-22269 > URL: https://issues.apache.org/jira/browse/IGNITE-22269 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *INTERNAL_ERR* does not make sense for *UnexpectedNullValueException* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22270) MarshallerException uses INTERNAL_ERR code
[ https://issues.apache.org/jira/browse/IGNITE-22270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22270: Description: *INTERNAL_ERR* does not make sense for *MarshallerException* (was: INTERNAL_ERR does not make sense for MarshallerException) > MarshallerException uses INTERNAL_ERR code > -- > > Key: IGNITE-22270 > URL: https://issues.apache.org/jira/browse/IGNITE-22270 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *INTERNAL_ERR* does not make sense for *MarshallerException* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22269) UnexpectedNullValueException uses INTERNAL_ERR code
[ https://issues.apache.org/jira/browse/IGNITE-22269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22269: Ignite Flags: (was: Docs Required,Release Notes Required) > UnexpectedNullValueException uses INTERNAL_ERR code > --- > > Key: IGNITE-22269 > URL: https://issues.apache.org/jira/browse/IGNITE-22269 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *INTERNAL_ERR* does not make sense for *UnexpectedNullValueException* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22270) MarshallerException uses INTERNAL_ERR code
Pavel Tupitsyn created IGNITE-22270: --- Summary: MarshallerException uses INTERNAL_ERR code Key: IGNITE-22270 URL: https://issues.apache.org/jira/browse/IGNITE-22270 Project: Ignite Issue Type: Bug Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 INTERNAL_ERR does not make sense for UnexpectedNullValueException -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22269) UnexpectedNullValueException uses INTERNAL_ERR code
[ https://issues.apache.org/jira/browse/IGNITE-22269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22269: Description: INTERNAL_ERR does not make sense for > UnexpectedNullValueException uses INTERNAL_ERR code > --- > > Key: IGNITE-22269 > URL: https://issues.apache.org/jira/browse/IGNITE-22269 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > INTERNAL_ERR does not make sense for -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22270) MarshallerException uses INTERNAL_ERR code
[ https://issues.apache.org/jira/browse/IGNITE-22270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22270: Description: INTERNAL_ERR does not make sense for MarshallerException (was: INTERNAL_ERR does not make sense for UnexpectedNullValueException) > MarshallerException uses INTERNAL_ERR code > -- > > Key: IGNITE-22270 > URL: https://issues.apache.org/jira/browse/IGNITE-22270 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > INTERNAL_ERR does not make sense for MarshallerException -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22270) MarshallerException uses INTERNAL_ERR code
[ https://issues.apache.org/jira/browse/IGNITE-22270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22270: Ignite Flags: (was: Docs Required,Release Notes Required) > MarshallerException uses INTERNAL_ERR code > -- > > Key: IGNITE-22270 > URL: https://issues.apache.org/jira/browse/IGNITE-22270 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > INTERNAL_ERR does not make sense for UnexpectedNullValueException -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22269) UnexpectedNullValueException uses INTERNAL_ERR code
Pavel Tupitsyn created IGNITE-22269: --- Summary: UnexpectedNullValueException uses INTERNAL_ERR code Key: IGNITE-22269 URL: https://issues.apache.org/jira/browse/IGNITE-22269 Project: Ignite Issue Type: Bug Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22269) UnexpectedNullValueException uses INTERNAL_ERR code
[ https://issues.apache.org/jira/browse/IGNITE-22269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22269: Description: INTERNAL_ERR does not make sense for UnexpectedNullValueException (was: INTERNAL_ERR does not make sense for ) > UnexpectedNullValueException uses INTERNAL_ERR code > --- > > Key: IGNITE-22269 > URL: https://issues.apache.org/jira/browse/IGNITE-22269 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > INTERNAL_ERR does not make sense for UnexpectedNullValueException -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22267) Improve Table API javadocs
[ https://issues.apache.org/jira/browse/IGNITE-22267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22267: Description: 1. Remove "started table" term, "table" is enough 2. Remove "binary object" mentions 3. Explain how KV view "splits" row data in two parts. It does not actually operate on separate keys and values. 4. Replace "Transaction or null to auto-commit" with "Transaction or null for implicit transaction" 5. Remove "@throws IgniteException If an unspecified platform exception has occurred internally", it is not useful was: 1. Remove "started table" term, "table" is enough 2. Remove "binary object" mentions 3. Explain how KV view "splits" row data in two parts. It does not actually operate on separate keys and values. 4. Replace "Transaction or null to auto-commit" with "Transaction or null for implicit transaction" > Improve Table API javadocs > -- > > Key: IGNITE-22267 > URL: https://issues.apache.org/jira/browse/IGNITE-22267 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > 1. Remove "started table" term, "table" is enough > 2. Remove "binary object" mentions > 3. Explain how KV view "splits" row data in two parts. It does not actually > operate on separate keys and values. > 4. Replace "Transaction or null to auto-commit" with "Transaction or null for > implicit transaction" > 5. Remove "@throws IgniteException If an unspecified platform exception has > occurred internally", it is not useful -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22268) Add checkstyle rule for package names
Vadim Pakhnushev created IGNITE-22268: - Summary: Add checkstyle rule for package names Key: IGNITE-22268 URL: https://issues.apache.org/jira/browse/IGNITE-22268 Project: Ignite Issue Type: Bug Reporter: Vadim Pakhnushev Assignee: Vadim Pakhnushev We should check that the package name corresponds to the directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22267) Improve Table API javadocs
[ https://issues.apache.org/jira/browse/IGNITE-22267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22267: Description: 1. Remove "started table" term, "table" is enough 2. Remove "binary object" mentions 3. Explain how KV view "splits" row data in two parts. It does not actually operate on separate keys and values. 4. Replace "Transaction or null to auto-commit" with "Transaction or null for implicit transaction" 5. Remove "@throws IgniteException If an unspecified platform exception has occurred internally", it is not useful 6. Declare order of tables in *tables()* and *tablesAsync()* was: 1. Remove "started table" term, "table" is enough 2. Remove "binary object" mentions 3. Explain how KV view "splits" row data in two parts. It does not actually operate on separate keys and values. 4. Replace "Transaction or null to auto-commit" with "Transaction or null for implicit transaction" 5. Remove "@throws IgniteException If an unspecified platform exception has occurred internally", it is not useful > Improve Table API javadocs > -- > > Key: IGNITE-22267 > URL: https://issues.apache.org/jira/browse/IGNITE-22267 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > 1. Remove "started table" term, "table" is enough > 2. Remove "binary object" mentions > 3. Explain how KV view "splits" row data in two parts. It does not actually > operate on separate keys and values. > 4. Replace "Transaction or null to auto-commit" with "Transaction or null for > implicit transaction" > 5. Remove "@throws IgniteException If an unspecified platform exception has > occurred internally", it is not useful > 6. Declare order of tables in *tables()* and *tablesAsync()* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22267) Improve Table API javadocs
[
https://issues.apache.org/jira/browse/IGNITE-22267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22267:
Description:
1. Remove "started table" term, "table" is enough
2. Remove "binary object" mentions
3. Explain how KV view "splits" row data in two parts. It does not actually
operate on separate keys and values.
4. Replace "Transaction or null to auto-commit" with "Transaction or null for
implicit transaction"
was:
1. Remove "started table" term, "table" is enough
2. Remove "binary object" mentions
3. Explain how KV view "splits" row data in two parts. It does not actually
operate on separate keys and values.
4. Replace "Transaction or {@code null} to auto-commit" with "Transaction or
{@code null} for implicit transaction"
> Improve Table API javadocs
> --
>
> Key: IGNITE-22267
> URL: https://issues.apache.org/jira/browse/IGNITE-22267
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> 1. Remove "started table" term, "table" is enough
> 2. Remove "binary object" mentions
> 3. Explain how KV view "splits" row data in two parts. It does not actually
> operate on separate keys and values.
> 4. Replace "Transaction or null to auto-commit" with "Transaction or null for
> implicit transaction"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22267) Improve Table API javadocs
[
https://issues.apache.org/jira/browse/IGNITE-22267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22267:
Description:
1. Remove "started table" term, "table" is enough
2. Remove "binary object" mentions
3. Explain how KV view "splits" row data in two parts. It does not actually
operate on separate keys and values.
4. Replace "Transaction or {@code null} to auto-commit" with "Transaction or
{@code null} for implicit transaction"
was:
1. Remove "started table" term, "table" is enough
2. Remove "binary object" mentions
3. Explain how KV view "splits" row data in two parts. It does not actually
operate on separate keys and values.
> Improve Table API javadocs
> --
>
> Key: IGNITE-22267
> URL: https://issues.apache.org/jira/browse/IGNITE-22267
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> 1. Remove "started table" term, "table" is enough
> 2. Remove "binary object" mentions
> 3. Explain how KV view "splits" row data in two parts. It does not actually
> operate on separate keys and values.
> 4. Replace "Transaction or {@code null} to auto-commit" with "Transaction or
> {@code null} for implicit transaction"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22267) Improve Table API javadocs
[ https://issues.apache.org/jira/browse/IGNITE-22267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22267: Description: 1. Remove "started table" term, "table" is enough 2. Remove "binary object" mentions 3. Explain how KV view "splits" row data in two parts. It does not actually operate on separate keys and values. > Improve Table API javadocs > -- > > Key: IGNITE-22267 > URL: https://issues.apache.org/jira/browse/IGNITE-22267 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > 1. Remove "started table" term, "table" is enough > 2. Remove "binary object" mentions > 3. Explain how KV view "splits" row data in two parts. It does not actually > operate on separate keys and values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22267) Improve Table API javadocs
Pavel Tupitsyn created IGNITE-22267: --- Summary: Improve Table API javadocs Key: IGNITE-22267 URL: https://issues.apache.org/jira/browse/IGNITE-22267 Project: Ignite Issue Type: Improvement Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22266) Move IgniteTables to org.apache.ignite.table package
[ https://issues.apache.org/jira/browse/IGNITE-22266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22266: Description: IgniteTables is in it's own *manager* package which is weird and inconsistent with other top-level APIs (compute, sql, tx, ...). Move it up to *o.a.i.table*. (was: IgniteTables is in it's own *manager* package which is weird and inconsistent with other top-level APIs (compute, tx, etc)) > Move IgniteTables to org.apache.ignite.table package > > > Key: IGNITE-22266 > URL: https://issues.apache.org/jira/browse/IGNITE-22266 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > IgniteTables is in it's own *manager* package which is weird and inconsistent > with other top-level APIs (compute, sql, tx, ...). Move it up to > *o.a.i.table*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22266) Move IgniteTables to org.apache.ignite.table package
[ https://issues.apache.org/jira/browse/IGNITE-22266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22266: Description: IgniteTables is in it's own *manager* package which is weird and inconsistent with other top-level APIs (compute, tx, etc) > Move IgniteTables to org.apache.ignite.table package > > > Key: IGNITE-22266 > URL: https://issues.apache.org/jira/browse/IGNITE-22266 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > IgniteTables is in it's own *manager* package which is weird and inconsistent > with other top-level APIs (compute, tx, etc) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22266) Move IgniteTables to org.apache.ignite.table package
Pavel Tupitsyn created IGNITE-22266: --- Summary: Move IgniteTables to org.apache.ignite.table package Key: IGNITE-22266 URL: https://issues.apache.org/jira/browse/IGNITE-22266 Project: Ignite Issue Type: Improvement Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22265) Improve IgniteTransactions javadoc
[
https://issues.apache.org/jira/browse/IGNITE-22265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22265:
Description:
1. "Begins an asynchronous transaction." -> "Begins a transaction
asynchronously"
2. "Take care then using the asynchronous operations inside the closure..."
uses an incorrect example first.
* Show the correct one first
* Make it very clear that the incorrect one is not to be used
3. Document isolation level and behavior
4. Document optimistic/pessimistic behavior, deadlocks, conflicts
5. javadoc for {{ T runInTransaction}} is copypasted
was:
1. "Begins an asynchronous transaction." -> "Begins a transaction
asynchronously"
2. "Take care then using the asynchronous operations inside the closure..."
uses an incorrect example first.
* Show the correct one first
* Make it very clear that the incorrect one is not to be used
3. Document isolation level and behavior
4. Document optimistic/pessimistic behavior
5. javadoc for {{ T runInTransaction}} is copypasted
> Improve IgniteTransactions javadoc
> --
>
> Key: IGNITE-22265
> URL: https://issues.apache.org/jira/browse/IGNITE-22265
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> 1. "Begins an asynchronous transaction." -> "Begins a transaction
> asynchronously"
> 2. "Take care then using the asynchronous operations inside the closure..."
> uses an incorrect example first.
> * Show the correct one first
> * Make it very clear that the incorrect one is not to be used
> 3. Document isolation level and behavior
> 4. Document optimistic/pessimistic behavior, deadlocks, conflicts
> 5. javadoc for {{ T runInTransaction}} is copypasted
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22265) Improve IgniteTransactions javadoc
[
https://issues.apache.org/jira/browse/IGNITE-22265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22265:
Description:
1. "Begins an asynchronous transaction." -> "Begins a transaction
asynchronously"
2. "Take care then using the asynchronous operations inside the closure..."
uses an incorrect example first.
* Show the correct one first
* Make it very clear that the incorrect one is not to be used
3. Document isolation level and behavior
4. Document optimistic/pessimistic behavior, deadlocks, conflicts
5. javadoc for * T runInTransaction* is copypasted
was:
1. "Begins an asynchronous transaction." -> "Begins a transaction
asynchronously"
2. "Take care then using the asynchronous operations inside the closure..."
uses an incorrect example first.
* Show the correct one first
* Make it very clear that the incorrect one is not to be used
3. Document isolation level and behavior
4. Document optimistic/pessimistic behavior, deadlocks, conflicts
5. javadoc for {{ T runInTransaction}} is copypasted
> Improve IgniteTransactions javadoc
> --
>
> Key: IGNITE-22265
> URL: https://issues.apache.org/jira/browse/IGNITE-22265
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> 1. "Begins an asynchronous transaction." -> "Begins a transaction
> asynchronously"
> 2. "Take care then using the asynchronous operations inside the closure..."
> uses an incorrect example first.
> * Show the correct one first
> * Make it very clear that the incorrect one is not to be used
> 3. Document isolation level and behavior
> 4. Document optimistic/pessimistic behavior, deadlocks, conflicts
> 5. javadoc for * T runInTransaction* is copypasted
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22265) Improve IgniteTransactions javadoc
[
https://issues.apache.org/jira/browse/IGNITE-22265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-22265:
Description:
1. "Begins an asynchronous transaction." -> "Begins a transaction
asynchronously"
2. "Take care then using the asynchronous operations inside the closure..."
uses an incorrect example first.
* Show the correct one first
* Make it very clear that the incorrect one is not to be used
3. Document isolation level and behavior
4. Document optimistic/pessimistic behavior
5. javadoc for {{ T runInTransaction}} is copypasted
was:
1. "Begins an asynchronous transaction." -> "Begins a transaction
asynchronously"
2. "Take care then using the asynchronous operations inside the closure..."
uses an incorrect example first.
* Show the correct one first
* Make it very clear that the incorrect one is not to be used
3. Document isolation level and behavior
4. Document optimistic/pessimistic behavior
> Improve IgniteTransactions javadoc
> --
>
> Key: IGNITE-22265
> URL: https://issues.apache.org/jira/browse/IGNITE-22265
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> 1. "Begins an asynchronous transaction." -> "Begins a transaction
> asynchronously"
> 2. "Take care then using the asynchronous operations inside the closure..."
> uses an incorrect example first.
> * Show the correct one first
> * Make it very clear that the incorrect one is not to be used
> 3. Document isolation level and behavior
> 4. Document optimistic/pessimistic behavior
> 5. javadoc for {{ T runInTransaction}} is copypasted
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22265) Improve IgniteTransactions javadoc
[ https://issues.apache.org/jira/browse/IGNITE-22265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22265: Description: 1. "Begins an asynchronous transaction." -> "Begins a transaction asynchronously" 2. "Take care then using the asynchronous operations inside the closure..." uses an incorrect example first. * Show the correct one first * Make it very clear that the incorrect one is not to be used 3. Document isolation level and behavior 4. Document optimistic/pessimistic behavior was: 1. "Begins an asynchronous transaction." -> "Begins a transaction asynchronously" 2. "Take care then using the asynchronous operations inside the closure..." uses an incorrect example first. * Show the correct one first * Make it very clear that the incorrect one is not to be used 3. tbd > Improve IgniteTransactions javadoc > -- > > Key: IGNITE-22265 > URL: https://issues.apache.org/jira/browse/IGNITE-22265 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > 1. "Begins an asynchronous transaction." -> "Begins a transaction > asynchronously" > 2. "Take care then using the asynchronous operations inside the closure..." > uses an incorrect example first. > * Show the correct one first > * Make it very clear that the incorrect one is not to be used > 3. Document isolation level and behavior > 4. Document optimistic/pessimistic behavior -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22265) Improve IgniteTransactions javadoc
[ https://issues.apache.org/jira/browse/IGNITE-22265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22265: Description: 1. "Begins an asynchronous transaction." -> "Begins a transaction asynchronously" 2. "Take care then using the asynchronous operations inside the closure..." uses an incorrect example first. * Show the correct one first * Make it very clear that the incorrect one is not to be used 3. tbd was: 1. "Begins an asynchronous transaction." -> "Begins a transaction asynchronously" 2. "Take care then using the asynchronous operations inside the closure..." uses an incorrect example first. * Show the correct one first * Make it very clear that the incorrect one is not to be used > Improve IgniteTransactions javadoc > -- > > Key: IGNITE-22265 > URL: https://issues.apache.org/jira/browse/IGNITE-22265 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > 1. "Begins an asynchronous transaction." -> "Begins a transaction > asynchronously" > 2. "Take care then using the asynchronous operations inside the closure..." > uses an incorrect example first. > * Show the correct one first > * Make it very clear that the incorrect one is not to be used > 3. tbd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22265) Improve IgniteTransactions javadoc
[ https://issues.apache.org/jira/browse/IGNITE-22265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22265: Description: 1. "Begins an asynchronous transaction." -> "Begins a transaction asynchronously" 2. "Take care then using the asynchronous operations inside the closure..." uses an incorrect example first. * Show the correct one first * Make it very clear that the incorrect one is not to be used 3. tbd was: 1. "Begins an asynchronous transaction." -> "Begins a transaction asynchronously" 2. "Take care then using the asynchronous operations inside the closure..." uses an incorrect example first. * Show the correct one first * Make it very clear that the incorrect one is not to be used 3. tbd > Improve IgniteTransactions javadoc > -- > > Key: IGNITE-22265 > URL: https://issues.apache.org/jira/browse/IGNITE-22265 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > 1. "Begins an asynchronous transaction." -> "Begins a transaction > asynchronously" > 2. "Take care then using the asynchronous operations inside the closure..." > uses an incorrect example first. > * Show the correct one first > * Make it very clear that the incorrect one is not to be used > 3. tbd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22265) Improve IgniteTransactions javadoc
[ https://issues.apache.org/jira/browse/IGNITE-22265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22265: Description: 1. "Begins an asynchronous transaction." -> "Begins a transaction asynchronously" 2. "Take care then using the asynchronous operations inside the closure..." uses an incorrect example first. * Show the correct one first * Make it very clear that the incorrect one is not to be used > Improve IgniteTransactions javadoc > -- > > Key: IGNITE-22265 > URL: https://issues.apache.org/jira/browse/IGNITE-22265 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > 1. "Begins an asynchronous transaction." -> "Begins a transaction > asynchronously" > 2. "Take care then using the asynchronous operations inside the closure..." > uses an incorrect example first. > * Show the correct one first > * Make it very clear that the incorrect one is not to be used -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22265) Improve IgniteTransactions javadoc
Pavel Tupitsyn created IGNITE-22265: --- Summary: Improve IgniteTransactions javadoc Key: IGNITE-22265 URL: https://issues.apache.org/jira/browse/IGNITE-22265 Project: Ignite Issue Type: Improvement Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22264) Startup instructions in examples are outdated
[ https://issues.apache.org/jira/browse/IGNITE-22264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22264: Description: Verify startup instructions (at the top of every example), make sure they work with upcoming Ignite beta2. https://github.com/apache/ignite-3/tree/main/examples/src/main/java/org/apache/ignite/example was:Verify startup instructions (at the top of every example), make sure they work with upcoming Ignite beta2. > Startup instructions in examples are outdated > - > > Key: IGNITE-22264 > URL: https://issues.apache.org/jira/browse/IGNITE-22264 > Project: Ignite > Issue Type: Bug > Components: examples >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Verify startup instructions (at the top of every example), make sure they > work with upcoming Ignite beta2. > https://github.com/apache/ignite-3/tree/main/examples/src/main/java/org/apache/ignite/example -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22264) Startup instructions in examples are outdated
Pavel Tupitsyn created IGNITE-22264: --- Summary: Startup instructions in examples are outdated Key: IGNITE-22264 URL: https://issues.apache.org/jira/browse/IGNITE-22264 Project: Ignite Issue Type: Bug Components: examples Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 Verify startup instructions (at the top of every example), make sure they work with upcoming Ignite beta2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22263) Sql. Avoid starting transaction for KV operation
[
https://issues.apache.org/jira/browse/IGNITE-22263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-22263:
-
Assignee: Konstantin Orlov
> Sql. Avoid starting transaction for KV operation
>
>
> Key: IGNITE-22263
> URL: https://issues.apache.org/jira/browse/IGNITE-22263
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> Currently, performance of KV put operation via SQL API is ~2 times worse than
> via KeyValueView API:
> {code:java}
> Benchmark (clusterSize) Mode CntScore Error Units
> InsertBenchmark.kvInsert 1 avgt 20 67.154 ± 4.266 us/op
> InsertBenchmark.sqlInsert 1 avgt 20 149.900 ± 9.679 us/op
> // these numbers acquired on MBP M3, commit c25f9fda.
> {code}
> This is caused by the fact that sql engine starts transaction explicitly if
> one was not provided by the user, thus not taking an advantage of single
> phase commit optimisation which is available for implicit transactions which
> touch only one partition.
> We can address the issue by postponing the moment of starting a transaction
> till execution phase. This will help to avoid starting an explicit
> transaction for simple KV cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22263) Sql. Avoid starting transaction for KV operation
Konstantin Orlov created IGNITE-22263:
-
Summary: Sql. Avoid starting transaction for KV operation
Key: IGNITE-22263
URL: https://issues.apache.org/jira/browse/IGNITE-22263
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Konstantin Orlov
Currently, performance of KV put operation via SQL API is ~2 times worse than
via KeyValueView API:
{code:java}
Benchmark (clusterSize) Mode CntScore Error Units
InsertBenchmark.kvInsert 1 avgt 20 67.154 ± 4.266 us/op
InsertBenchmark.sqlInsert 1 avgt 20 149.900 ± 9.679 us/op
// these numbers acquired on MBP M3, commit c25f9fda.
{code}
This is caused by the fact that sql engine starts transaction explicitly if one
was not provided by the user, thus not taking an advantage of single phase
commit optimisation which is available for implicit transactions which touch
only one partition.
We can address the issue by postponing the moment of starting a transaction
till execution phase. This will help to avoid starting an explicit transaction
for simple KV cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-22089: Description: To remove MVCC code from Yardstick. To delete classes: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark - NativeJavaApiPutRemoveBenchmark was: To remove MVCC code from Yardstick. To delete classes: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > To remove MVCC code from Yardstick. To delete classes: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark > - NativeJavaApiPutRemoveBenchmark -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[ https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-22089: Description: To remove MVCC code from Yardstick. To delete classes: - AbstractDistributedMvccBenchmark - MvccProcessorBenchmark - MvccUpdateContentionBenchmark was: AbstractDistributedMvccBenchmark MvccProcessorBenchmark MvccUpdateContentionBenchmark > Removal of MVCC benchmarks in Yardstick > --- > > Key: IGNITE-22089 > URL: https://issues.apache.org/jira/browse/IGNITE-22089 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > To remove MVCC code from Yardstick. To delete classes: > - AbstractDistributedMvccBenchmark > - MvccProcessorBenchmark > - MvccUpdateContentionBenchmark -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22089) Removal of MVCC benchmarks in Yardstick
[
https://issues.apache.org/jira/browse/IGNITE-22089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847212#comment-17847212
]
Ignite TC Bot commented on IGNITE-22089:
{panel:title=Branch: [pull/11345/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11345/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7871915&buildTypeId=IgniteTests24Java8_RunAll]
> Removal of MVCC benchmarks in Yardstick
> ---
>
> Key: IGNITE-22089
> URL: https://issues.apache.org/jira/browse/IGNITE-22089
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> AbstractDistributedMvccBenchmark
> MvccProcessorBenchmark
> MvccUpdateContentionBenchmark
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22262) Startup instructions missing in SqlApiExample
Pavel Tupitsyn created IGNITE-22262: --- Summary: Startup instructions missing in SqlApiExample Key: IGNITE-22262 URL: https://issues.apache.org/jira/browse/IGNITE-22262 Project: Ignite Issue Type: Bug Components: examples Reporter: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22262) Startup instructions missing in SqlApiExample
[ https://issues.apache.org/jira/browse/IGNITE-22262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22262: Ignite Flags: (was: Docs Required,Release Notes Required) > Startup instructions missing in SqlApiExample > - > > Key: IGNITE-22262 > URL: https://issues.apache.org/jira/browse/IGNITE-22262 > Project: Ignite > Issue Type: Bug > Components: examples >Reporter: Pavel Tupitsyn >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22262) Startup instructions missing in SqlApiExample
[ https://issues.apache.org/jira/browse/IGNITE-22262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22262: Priority: Minor (was: Major) > Startup instructions missing in SqlApiExample > - > > Key: IGNITE-22262 > URL: https://issues.apache.org/jira/browse/IGNITE-22262 > Project: Ignite > Issue Type: Bug > Components: examples >Reporter: Pavel Tupitsyn >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22262) Startup instructions missing in SqlApiExample
[ https://issues.apache.org/jira/browse/IGNITE-22262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22262: Description: * Standard header with node start instructions is missing. * The example fails if you run it as is (without starting a properly configured node) > Startup instructions missing in SqlApiExample > - > > Key: IGNITE-22262 > URL: https://issues.apache.org/jira/browse/IGNITE-22262 > Project: Ignite > Issue Type: Bug > Components: examples >Reporter: Pavel Tupitsyn >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > * Standard header with node start instructions is missing. > * The example fails if you run it as is (without starting a properly > configured node) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22261) Deadlock on configuration application in NodeImpl when disruptors are full
[ https://issues.apache.org/jira/browse/IGNITE-22261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-22261: --- Description: # NodeImpl#executeApplyingTasks() takes NodeImpl.writeLock and calls LogManager.appendEntries() # LogManager tries to enqueue a task to diskQueue which is full, hence it blocks until a task gets consumed from diskQueue # diskQueue is consumed by StableClosureEventHandler # StableClosureEventHandler tries to enqueue a task to FSMCallerImpl#taskQueue, which is also full, so this also blocks until a task gets consumed from FSMCallerImpl#taskQueue # FSMCallerImpl#taskQueue is consumed by ApplyTaskHandler # ApplyTaskHandler calls NodeImpl#onConfigurationChangeDone(), which tries to take NodeImpl#writeLock As a result, there is a deadlock: NodeImpl#writeLock->LogManager#diskQueue->FSMCallerImpl#taskQueue->NodeImpl#writeLock (disruptors are used as blocking queues in JRaft, so, when full, they act like locks). This was caught by ItNodeTest#testNodeTaskOverload() which uses extremely short disruptors (2 items max each). was: # NodeImpl#executeApplyingTasks() takes NodeImpl.writeLock and calls LogManager.appendEntries() # LogManager tries to enqueue a task to diskQueue which is full, hence it blocks until a task gets consumed from diskQueue # diskQueue is consumed by StableClosureEventHandler # StableClosureEventHandler tries to enqueue a task to FSMCallerImpl#taskQueue, which is also full, so this also blocks until a task gets consumed from FSMCallerImpl#taskQueue # FSMCallerImpl#taskQueue is consumed by ApplyTaskHandler # ApplyTaskHandler calls NodeImpl#onConfigurationChangeDone(), which tries to take NodeImpl#writeLock As a result, there is a deadlock: NodeImpl#writeLock->LogManager#diskQueue->FSMCallerImpl#taskQueue->NodeImpl#writeLock (disruptors are used as blocking queues in JRaft, so, when full, they act like locks). > Deadlock on configuration application in NodeImpl when disruptors are full > -- > > Key: IGNITE-22261 > URL: https://issues.apache.org/jira/browse/IGNITE-22261 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > # NodeImpl#executeApplyingTasks() takes NodeImpl.writeLock and calls > LogManager.appendEntries() > # LogManager tries to enqueue a task to diskQueue which is full, hence it > blocks until a task gets consumed from diskQueue > # diskQueue is consumed by StableClosureEventHandler > # StableClosureEventHandler tries to enqueue a task to > FSMCallerImpl#taskQueue, which is also full, so this also blocks until a task > gets consumed from FSMCallerImpl#taskQueue > # FSMCallerImpl#taskQueue is consumed by ApplyTaskHandler > # ApplyTaskHandler calls NodeImpl#onConfigurationChangeDone(), which tries > to take NodeImpl#writeLock > As a result, there is a deadlock: > NodeImpl#writeLock->LogManager#diskQueue->FSMCallerImpl#taskQueue->NodeImpl#writeLock > (disruptors are used as blocking queues in JRaft, so, when full, they act > like locks). > This was caught by ItNodeTest#testNodeTaskOverload() which uses extremely > short disruptors (2 items max each). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22261) Deadlock on configuration application in NodeImpl when disruptors are full
[ https://issues.apache.org/jira/browse/IGNITE-22261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-22261: --- Description: # NodeImpl#executeApplyingTasks() takes NodeImpl.writeLock and calls LogManager.appendEntries() # LogManager tries to enqueue a task to diskQueue which is full, hence it blocks until a task gets consumed from diskQueue # diskQueue is consumed by StableClosureEventHandler # StableClosureEventHandler tries to enqueue a task to FSMCallerImpl#taskQueue, which is also full, so this also blocks until a task gets consumed from FSMCallerImpl#taskQueue # FSMCallerImpl#taskQueue is consumed by ApplyTaskHandler # ApplyTaskHandler calls NodeImpl#onConfigurationChangeDone(), which tries to take NodeImpl#writeLock As a result, there is a deadlock: NodeImpl#writeLock->LogManager#diskQueue->FSMCallerImpl#taskQueue->NodeImpl#writeLock (disruptors are used as blocking queues in JRaft, so, when full, they act like locks). > Deadlock on configuration application in NodeImpl when disruptors are full > -- > > Key: IGNITE-22261 > URL: https://issues.apache.org/jira/browse/IGNITE-22261 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > # NodeImpl#executeApplyingTasks() takes NodeImpl.writeLock and calls > LogManager.appendEntries() > # LogManager tries to enqueue a task to diskQueue which is full, hence it > blocks until a task gets consumed from diskQueue > # diskQueue is consumed by StableClosureEventHandler > # StableClosureEventHandler tries to enqueue a task to > FSMCallerImpl#taskQueue, which is also full, so this also blocks until a task > gets consumed from FSMCallerImpl#taskQueue > # FSMCallerImpl#taskQueue is consumed by ApplyTaskHandler > # ApplyTaskHandler calls NodeImpl#onConfigurationChangeDone(), which tries > to take NodeImpl#writeLock > As a result, there is a deadlock: > NodeImpl#writeLock->LogManager#diskQueue->FSMCallerImpl#taskQueue->NodeImpl#writeLock > (disruptors are used as blocking queues in JRaft, so, when full, they act > like locks). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22261) Deadlock on configuration application in NodeImpl when disruptors are full
Roman Puchkovskiy created IGNITE-22261: -- Summary: Deadlock on configuration application in NodeImpl when disruptors are full Key: IGNITE-22261 URL: https://issues.apache.org/jira/browse/IGNITE-22261 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21466) Add metrics for partition states
[ https://issues.apache.org/jira/browse/IGNITE-21466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-21466: Assignee: Kirill Tkalenko (was: Ivan Bessonov) > Add metrics for partition states > > > Key: IGNITE-21466 > URL: https://issues.apache.org/jira/browse/IGNITE-21466 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21445) IndexQuery ignores pageSize if setLocal=true is set
[
https://issues.apache.org/jira/browse/IGNITE-21445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847172#comment-17847172
]
Ignite TC Bot commented on IGNITE-21445:
{panel:title=Branch: [pull/11317/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11317/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7872521&buildTypeId=IgniteTests24Java8_RunAll]
> IndexQuery ignores pageSize if setLocal=true is set
> ---
>
> Key: IGNITE-21445
> URL: https://issues.apache.org/jira/browse/IGNITE-21445
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Maksim Timonin
>Assignee: Oleg Valuyskiy
>Priority: Major
> Labels: ise
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> In 2.14, see GridCacheQueryManager#runQuery:L1323
> If query is local it just collects all possible data.
> For ScanQuery this code doesn't work, as it directly uses local
> scanQueryIterator that returns entry one by one.
> Solution:
> # Prepare page for iterating
> # Use the same logic as ScanQuery for local queries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22260) Sql. Unexpected results with CASE query.
Evgeny Stanilovsky created IGNITE-22260:
---
Summary: Sql. Unexpected results with CASE query.
Key: IGNITE-22260
URL: https://issues.apache.org/jira/browse/IGNITE-22260
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
Fix For: 3.0.0-beta2
{noformat}
@Test
@WithSystemProperty(key = "IMPLICIT_PK_ENABLED", value = "true")
public void test0() {
sql("CREATE TABLE tbl_ProductSales (ColID int, Product_Category
varchar(64), Product_Name varchar(64), TotalSales int);");
sql("CREATE TABLE another_T (col1 INT, col2 INT, col3 INT, col4 INT,
col5 INT, col6 INT, col7 INT, col8 INT);");
sql("INSERT INTO tbl_ProductSales VALUES (1,'Game','Mobo
Game',200),(2,'Game','PKO
Game',400),(3,'Fashion','Shirt',500),(4,'Fashion','Shorts',100);");
sql("INSERT INTO another_T VALUES (1,2,3,4,5,6,7,8),
(11,22,33,44,55,66,77,88), (111,222,333,444,555,666,777,888),
(,,,,,,,);");
List> res = sql(
"SSELECT CASE WHEN 1 IN (SELECT MAX(col7) UNION ALL (SELECT
MIN(ColID) FROM tbl_ProductSales INNER JOIN another_T t2 ON t2.col5 = t2.col1))
THEN 2 ELSE NULL END FROM another_T t1;");
res.get(0);
}
{noformat}
{noformat}
expected=[[null]], actual=[[null], [null], [null], [null]]]
{noformat}
this statement is a part of:
test_grouped_correlated_subquery.test_ignore
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22260) Sql. Unexpected results with CASE query.
[
https://issues.apache.org/jira/browse/IGNITE-22260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-22260:
Description:
{noformat}
@Test
@WithSystemProperty(key = "IMPLICIT_PK_ENABLED", value = "true")
public void test0() {
sql("CREATE TABLE tbl_ProductSales (ColID int, Product_Category
varchar(64), Product_Name varchar(64), TotalSales int);");
sql("CREATE TABLE another_T (col1 INT, col2 INT, col3 INT, col4 INT,
col5 INT, col6 INT, col7 INT, col8 INT);");
sql("INSERT INTO tbl_ProductSales VALUES (1,'Game','Mobo
Game',200),(2,'Game','PKO
Game',400),(3,'Fashion','Shirt',500),(4,'Fashion','Shorts',100);");
sql("INSERT INTO another_T VALUES (1,2,3,4,5,6,7,8),
(11,22,33,44,55,66,77,88), (111,222,333,444,555,666,777,888),
(,,,,,,,);");
List> res = sql(
"SELECT CASE WHEN 1 IN (SELECT MAX(col7) UNION ALL (SELECT
MIN(ColID) FROM tbl_ProductSales INNER JOIN another_T t2 ON t2.col5 = t2.col1))
THEN 2 ELSE NULL END FROM another_T t1;");
res.get(0);
}
{noformat}
{noformat}
expected=[[null]], actual=[[null], [null], [null], [null]]]
{noformat}
this statement is a part of:
test_grouped_correlated_subquery.test_ignore
was:
{noformat}
@Test
@WithSystemProperty(key = "IMPLICIT_PK_ENABLED", value = "true")
public void test0() {
sql("CREATE TABLE tbl_ProductSales (ColID int, Product_Category
varchar(64), Product_Name varchar(64), TotalSales int);");
sql("CREATE TABLE another_T (col1 INT, col2 INT, col3 INT, col4 INT,
col5 INT, col6 INT, col7 INT, col8 INT);");
sql("INSERT INTO tbl_ProductSales VALUES (1,'Game','Mobo
Game',200),(2,'Game','PKO
Game',400),(3,'Fashion','Shirt',500),(4,'Fashion','Shorts',100);");
sql("INSERT INTO another_T VALUES (1,2,3,4,5,6,7,8),
(11,22,33,44,55,66,77,88), (111,222,333,444,555,666,777,888),
(,,,,,,,);");
List> res = sql(
"SSELECT CASE WHEN 1 IN (SELECT MAX(col7) UNION ALL (SELECT
MIN(ColID) FROM tbl_ProductSales INNER JOIN another_T t2 ON t2.col5 = t2.col1))
THEN 2 ELSE NULL END FROM another_T t1;");
res.get(0);
}
{noformat}
{noformat}
expected=[[null]], actual=[[null], [null], [null], [null]]]
{noformat}
this statement is a part of:
test_grouped_correlated_subquery.test_ignore
> Sql. Unexpected results with CASE query.
>
>
> Key: IGNITE-22260
> URL: https://issues.apache.org/jira/browse/IGNITE-22260
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {noformat}
> @Test
> @WithSystemProperty(key = "IMPLICIT_PK_ENABLED", value = "true")
> public void test0() {
> sql("CREATE TABLE tbl_ProductSales (ColID int, Product_Category
> varchar(64), Product_Name varchar(64), TotalSales int);");
> sql("CREATE TABLE another_T (col1 INT, col2 INT, col3 INT, col4 INT,
> col5 INT, col6 INT, col7 INT, col8 INT);");
> sql("INSERT INTO tbl_ProductSales VALUES (1,'Game','Mobo
> Game',200),(2,'Game','PKO
> Game',400),(3,'Fashion','Shirt',500),(4,'Fashion','Shorts',100);");
> sql("INSERT INTO another_T VALUES (1,2,3,4,5,6,7,8),
> (11,22,33,44,55,66,77,88), (111,222,333,444,555,666,777,888),
> (,,,,,,,);");
> List> res = sql(
> "SELECT CASE WHEN 1 IN (SELECT MAX(col7) UNION ALL (SELECT
> MIN(ColID) FROM tbl_ProductSales INNER JOIN another_T t2 ON t2.col5 =
> t2.col1)) THEN 2 ELSE NULL END FROM another_T t1;");
> res.get(0);
> }
> {noformat}
> {noformat}
> expected=[[null]], actual=[[null], [null], [null], [null]]]
> {noformat}
> this statement is a part of:
> test_grouped_correlated_subquery.test_ignore
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
