[jira] [Created] (IGNITE-22257) Move IgniteUtils#copyStateTo to CompletableFutures
Kirill Tkalenko created IGNITE-22257: Summary: Move IgniteUtils#copyStateTo to CompletableFutures Key: IGNITE-22257 URL: https://issues.apache.org/jira/browse/IGNITE-22257 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 I noticed that we have *org.apache.ignite.internal.util.IgniteUtils#copyStateTo*, but it would be more appropriate to move it to *org.apache.ignite.internal.util.CompletableFutures*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21981) Extend test coverage for SQL F862( in subqueries)
[ https://issues.apache.org/jira/browse/IGNITE-21981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-21981: - Assignee: Maksim Zhuravkov > Extend test coverage for SQL F862( in subqueries) > --- > > Key: IGNITE-21981 > URL: https://issues.apache.org/jira/browse/IGNITE-21981 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Test coverage for SQL F862( in subqueries) is poor. > Let's increase the test coverage. > > ref - test/sql/subquery/scalar/test_correlated_subquery_cte.test > -- 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: InsertBenchmark.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
>
> 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: StripedDisruptor.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
>
> 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=17847113#comment-17847113
]
Vladislav Pyatkov commented on IGNITE-15568:
After two passes (the benchmark was attached), it showed a weak positive
impingement.
{code:java}
New disruptor
Benchmark (clusterSize) (fsync) (partitionCount) Mode Cnt
Score Error Units
InsertBenchmark.kvInsert 1false 1 avgt 200
6891,786 ± 480,532 us/op
InsertBenchmark.kvInsert 1 true 1 avgt 200
7615,249 ± 462,971 us/op
Benchmark (clusterSize) (fsync) (partitionCount) Mode Cnt
Score Error Units
InsertBenchmark.kvInsert 1false 1 avgt 200
6676,231 ± 435,272 us/op
InsertBenchmark.kvInsert 1 true 1 avgt 200
7656,038 ± 460,172 us/op
Old disruptor
Benchmark (clusterSize) (fsync) (partitionCount) Mode Cnt
Score Error Units
InsertBenchmark.kvInsert 1false 1 avgt 200
7398,135 ± 895,617 us/op
InsertBenchmark.kvInsert 1 true 1 avgt 200
7965,185 ± 443,870 us/op
Benchmark (clusterSize) (fsync) (partitionCount) Mode Cnt
Score Error Units
InsertBenchmark.kvInsert 1false 1 avgt 200
6618,169 ± 1093,236 us/op
InsertBenchmark.kvInsert 1 true 1 avgt 200
8136,877 ± 292,777 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: StripedDisruptor.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: StripedDisruptor.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: StripedDisruptor.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-22241) Make ClusterManagementGroupManager more extensible
[
https://issues.apache.org/jira/browse/IGNITE-22241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tiago Marques Godinho updated IGNITE-22241:
---
Reviewer: Roman Puchkovskiy
> Make ClusterManagementGroupManager more extensible
> --
>
> Key: IGNITE-22241
> URL: https://issues.apache.org/jira/browse/IGNITE-22241
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Tiago Marques Godinho
>Assignee: Tiago Marques Godinho
>Priority: Minor
> Labels: ignite-3
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The {color:#00}ClusterManagementGroupManager class is pretty much closed
> for extension.
> It is getting too complex to add functionality to this class.
> It would be very nice for the future if this class supported the
> EventProducer API.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [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=17847002#comment-17847002
]
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=7870847]]
* {color:#013220}IgniteSpiDiscoverySelfTestSuite:
TcpDiscoveryNetworkIssuesTest.testBackwardConnectionCheckFailedLogMessage -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7870721buildTypeId=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] [Resolved] (IGNITE-21812) Add automatic product version resolve
[ https://issues.apache.org/jira/browse/IGNITE-21812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin resolved IGNITE-21812. Resolution: Fixed > Add automatic product version resolve > - > > Key: IGNITE-21812 > URL: https://issues.apache.org/jira/browse/IGNITE-21812 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Now the product version is hardcoded in EventBuilder but we can fetch the > product version automatically from the environment that can be formed during > the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21812) Add automatic product version resolve
[ https://issues.apache.org/jira/browse/IGNITE-21812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846998#comment-17846998 ] Mikhail Pochatkin commented on IGNITE-21812: Merged to main b60fed3ff2265755c78d6217c806104d0e35ced6 > Add automatic product version resolve > - > > Key: IGNITE-21812 > URL: https://issues.apache.org/jira/browse/IGNITE-21812 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Now the product version is hardcoded in EventBuilder but we can fetch the > product version automatically from the environment that can be formed during > the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21980) Extend test coverage for SQL F861(Top-level in )
[ https://issues.apache.org/jira/browse/IGNITE-21980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846963#comment-17846963 ] Maksim Zhuravkov commented on IGNITE-21980: --- Covered under sql/order/test_top_n.test > Extend test coverage for SQL F861(Top-level in expression>) > - > > Key: IGNITE-21980 > URL: https://issues.apache.org/jira/browse/IGNITE-21980 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Test coverage for SQL F861(Top-level in expression>) is poor. > Let's increase the test coverage. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22050) Data structures don't clear partId of reused page
[
https://issues.apache.org/jira/browse/IGNITE-22050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846943#comment-17846943
]
Aleksandr Polovtsev commented on IGNITE-22050:
--
Here's the original problem reproducer, it should also be checked during the
ticket development and/or converted into a test:
{code:java}
public class GcIssueExample extends ClusterPerClassIntegrationTest {
@Override
protected int initialNodes() {
return 1;
}
@Override
protected void configureInitParameters(InitParametersBuilder builder) {
builder.clusterConfiguration("{"
+ "gc.lowWatermark.dataAvailabilityTime: 1000,\n"
+ "gc.lowWatermark.updateFrequency: 3000\n"
+ "}");
}
@Test
public void test() throws Exception {
sql("CREATE ZONE IF NOT EXISTS zone_test WITH
storage_profiles='default_aimem'");
sql("CREATE TABLE IF NOT EXISTS db1 (id int, f_name varchar, l_name
varchar, str varchar,"
+ " PRIMARY KEY (id)) WITH PRIMARY_ZONE='ZONE_TEST';");
int numberOfRecords = 10;
//int numberOfUpdates = 400; // Works fine
//int numberOfUpdates = 500; // Works fine
//int numberOfUpdates = 600; // Doesn't work
int numberOfUpdates = 1000; // Doesn't work
for(int i = 0; i < numberOfRecords; i++) {
sql(format("INSERT INTO db1 (id, f_name, l_name, str) VALUES ({},
'John', 'Doe', 'test');", i));
for (int j = 0; j < numberOfUpdates; j++ ) {
sql(format("UPDATE db1 SET str = 'Some test data version {}'
WHERE id = {}", j, i));
}
}
}
}
{code}
> Data structures don't clear partId of reused page
> -
>
> Key: IGNITE-22050
> URL: https://issues.apache.org/jira/browse/IGNITE-22050
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In current implementation we use a single reuse list for all partitions in
> aimem storage engine.
> That works fine in Ignite 2, but here in Ignite 3 we implemented a
> "partitilnless link" format for eliminating 2 bytes, that indicate partition
> number, from the data in pages. This means that if allocator provided the
> structure with the page from partition X, but the structure itself represents
> partition Y, we will lose the "X" in the process and next time will try
> accessing the page by the pageId that has Y encoded in it. This would lead to
> pageId mismatch.
> We have several options here.
> * ignore mismatched partitions
> * get rid of partitionless pageIds
> * fix the allocator, so that it would change partition Id upon allocation
> Ideally, we should go with the 3rd option. It requires some slight changes in
> internal data structure API, so that we would pass the required partitionId
> directly into the allocator (reuse list). This is a little bit excessive at
> first sight, but seems more appropriate in a long run. Ignite 2 pageIds are
> all messed up inside of structures, we can fix that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22256) ItKvKeyColumnPositionTest contains tests that are no longer needed.
[
https://issues.apache.org/jira/browse/IGNITE-22256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22256:
--
Description:
Remove testNotNullableGetSimple and testNotNullableGetComplex from
ItKvKeyColumnPositionTest as these tests are no longer needed.
These are also not correct w.r.t behaviour of `getNullable*` operation that was
fixed under IGNITE-21836:
{code:java}
kvView.put(null, key, null);
//Or with arg names
kvView.put(, , );
{code}
Should throw an exception, when value is null, because `put(key, null)` is
permitted only for values of simple type.
was:
Remove testNotNullableGetSimple and testNotNullableGetComplex from
ItKvKeyColumnPositionTest as these tests are no longer needed.
These are also not correct w.r.t behaviour of `getNullable*` operation that was
fixed under IGNITE-21836:
{code:java}
kvView.put(null, key, null);
//Or with arg names
kvView.put(, , );
{code}
Should throw an exception, when value is null, because `put(key, null)` is
permitted only for values of simple type.
> ItKvKeyColumnPositionTest contains tests that are no longer needed.
> ---
>
> Key: IGNITE-22256
> URL: https://issues.apache.org/jira/browse/IGNITE-22256
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Remove testNotNullableGetSimple and testNotNullableGetComplex from
> ItKvKeyColumnPositionTest as these tests are no longer needed.
> These are also not correct w.r.t behaviour of `getNullable*` operation that
> was fixed under IGNITE-21836:
> {code:java}
> kvView.put(null, key, null);
> //Or with arg names
> kvView.put(, , );
> {code}
> Should throw an exception, when value is null, because `put(key, null)` is
> permitted only for values of simple type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22256) ItKvKeyColumnPositionTest contains tests that are no longer needed.
[
https://issues.apache.org/jira/browse/IGNITE-22256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22256:
--
Description:
Remove testNotNullableGetSimple and testNotNullableGetComplex from
ItKvKeyColumnPositionTest as these tests are no longer needed.
These are also not correct w.r.t behaviour of `getNullable*` operation that was
fixed under IGNITE-21836:
{code:java}
kvView.put(null, key, null);
//Or with arg names
kvView.put(, , );
{code}
Should throw an exception, when value is null, because `put(key, null)` is
permitted only for values of simple type.
was:
Remove testNotNullableGetSimple and testNotNullableGetComplex from
ItKvKeyColumnPositionTest as these tests are no longer needed.
These are also not correct w.r.t behaviour of `getNullable*` operation that was
fixed under IGNITE-21836:
{code:java}
kvView.put(null, key, null);
//Or with arg names
kvView.put(, , );
{code}
Should throw an exception, when value is null, because put(key, null) works
only for values of simple type.
> ItKvKeyColumnPositionTest contains tests that are no longer needed.
> ---
>
> Key: IGNITE-22256
> URL: https://issues.apache.org/jira/browse/IGNITE-22256
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Remove testNotNullableGetSimple and testNotNullableGetComplex from
> ItKvKeyColumnPositionTest as these tests are no longer needed.
> These are also not correct w.r.t behaviour of `getNullable*` operation that
> was fixed under IGNITE-21836:
> {code:java}
> kvView.put(null, key, null);
> //Or with arg names
> kvView.put(, , );
> {code}
> Should throw an exception, when value is null, because `put(key, null)` is
> permitted only for values of simple type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22256) ItKvKeyColumnPositionTest contains tests that are no longer needed.
[
https://issues.apache.org/jira/browse/IGNITE-22256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22256:
--
Description:
Remove testNotNullableGetSimple and testNotNullableGetComplex from
ItKvKeyColumnPositionTest as these tests are no longer needed.
These are also not correct w.r.t behaviour of `getNullable*` operation that was
fixed under IGNITE-21836:
{code:java}
kvView.put(null, key, null);
//Or with arg names
kvView.put(, , );
{code}
Should throw an exception, when value is null, because put(key, null) works
only for values of simple type.
was:
Remove testNotNullableGetSimple and testNotNullableGetComplex from
ItKvKeyColumnPositionTest, as these tests are no longer needed and they are
also not correct w.r.t behaviour of `getNullable*` operation that was fixed
under IGNITE-21836.
> ItKvKeyColumnPositionTest contains tests that are no longer needed.
> ---
>
> Key: IGNITE-22256
> URL: https://issues.apache.org/jira/browse/IGNITE-22256
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Remove testNotNullableGetSimple and testNotNullableGetComplex from
> ItKvKeyColumnPositionTest as these tests are no longer needed.
> These are also not correct w.r.t behaviour of `getNullable*` operation that
> was fixed under IGNITE-21836:
> {code:java}
> kvView.put(null, key, null);
> //Or with arg names
> kvView.put(, , );
> {code}
> Should throw an exception, when value is null, because put(key, null) works
> only for values of simple type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22256) ItKvKeyColumnPositionTest contains tests that are no longer needed.
Maksim Zhuravkov created IGNITE-22256: - Summary: ItKvKeyColumnPositionTest contains tests that are no longer needed. Key: IGNITE-22256 URL: https://issues.apache.org/jira/browse/IGNITE-22256 Project: Ignite Issue Type: Improvement Reporter: Maksim Zhuravkov Remove testNotNullableGetSimple and testNotNullableGetComplex from ItKvKeyColumnPositionTest, as these tests are no longer needed and they are also not correct w.r.t behaviour of `getNullable*` operation that was fixed under IGNITE-21836. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22256) ItKvKeyColumnPositionTest contains tests that are no longer needed.
[ https://issues.apache.org/jira/browse/IGNITE-22256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-22256: - Assignee: Maksim Zhuravkov > ItKvKeyColumnPositionTest contains tests that are no longer needed. > --- > > Key: IGNITE-22256 > URL: https://issues.apache.org/jira/browse/IGNITE-22256 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > Remove testNotNullableGetSimple and testNotNullableGetComplex from > ItKvKeyColumnPositionTest, as these tests are no longer needed and they are > also not correct w.r.t behaviour of `getNullable*` operation that was fixed > under IGNITE-21836. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22164) Sql. Merge throws exception if columns defined in different from table definition order.
[
https://issues.apache.org/jira/browse/IGNITE-22164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-22164:
-
Assignee: Pavel Pereslegin
> Sql. Merge throws exception if columns defined in different from table
> definition order.
>
>
> Key: IGNITE-22164
> URL: https://issues.apache.org/jira/browse/IGNITE-22164
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Reproducer:
> {noformat}
> sql("create table limitedChar (pk int primary key, f1 CHAR(2), f2
> CHAR(2))");
> sql("create table test1 (pk int primary key, f1 CHAR(2), f2
> CHAR(2))");
> String mergeSql2 = "MERGE INTO limitedChar dst USING test1 src ON
> dst.pk = src.pk "
> + "WHEN MATCHED THEN UPDATE SET f1 = '12' "
> + "WHEN NOT MATCHED THEN INSERT (pk, f2, f1) VALUES (src.pk,
> src.f2, src.f1)";
> sql(mergeSql2);
> {noformat}
> Caused by: java.lang.ClassCastException: class
> org.apache.ignite.internal.sql.engine.rel.logical.IgniteLogicalTableScan
> cannot be cast to class org.apache.calcite.rel.logical.LogicalProject
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21980) Extend test coverage for SQL F861(Top-level in )
[ https://issues.apache.org/jira/browse/IGNITE-21980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-21980: - Assignee: Maksim Zhuravkov > Extend test coverage for SQL F861(Top-level in expression>) > - > > Key: IGNITE-21980 > URL: https://issues.apache.org/jira/browse/IGNITE-21980 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Test coverage for SQL F861(Top-level in expression>) is poor. > Let's increase the test coverage. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19065) Sql. Reject INSERT statements with missing not nullable columns at the validation phase.
[
https://issues.apache.org/jira/browse/IGNITE-19065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich reassigned IGNITE-19065:
---
Assignee: Iurii Gerzhedovich
> Sql. Reject INSERT statements with missing not nullable columns at the
> validation phase.
>
>
> Key: IGNITE-19065
> URL: https://issues.apache.org/jira/browse/IGNITE-19065
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Iurii Gerzhedovich
>Priority: Minor
> Labels: calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> INSERT queries with missing columns that have NOT NULL constraint
> successfully pass the validation phase and fail at the execution phase
> because that constraint is violated.
> It would be better to reject INSERT statements with omitted not nullable
> columns at the validation phase in order not execute queries that always fail.
> An example of the current behaviour:
> {code:java}
>@Test
> public void test() {
> sql("CREATE TABLE integers(i INTEGER, j INTEGER NOT NULL, k
> INTEGER)");
> sql("INSERT INTO integers (i, k) VALUES (1, 0)");
> }
> {code}
> Error:
> {code:java}
> Caused by: org.apache.ignite.internal.schema.SchemaMismatchException:
> IGN-CMN-65535 TraceId:73ff8353-de43-4a58-9332-9f7d87718a93 Failed to set
> column (null was passed, but column is not nullable): Column [schemaIndex=1,
> columnOrder=1, name=J, type=NativeType [name=INT32, sizeInBytes=4,
> fixed=true], nullable=false]
> at
> org.apache.ignite.internal.schema.row.RowAssembler.appendNull(RowAssembler.java:261)
> at
> org.apache.ignite.internal.schema.row.RowAssembler.writeValue(RowAssembler.java:112)
> at
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.convertRow(IgniteTableImpl.java:516)
> at
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.insertAll(IgniteTableImpl.java:390)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18559) Sql. The least restrictive type between VARCHAR and DECIMAL is DECIMAL(precision=32767, scale=16383)
[
https://issues.apache.org/jira/browse/IGNITE-18559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich reassigned IGNITE-18559:
---
Assignee: (was: Iurii Gerzhedovich)
> Sql. The least restrictive type between VARCHAR and DECIMAL is
> DECIMAL(precision=32767, scale=16383)
>
>
> Key: IGNITE-18559
> URL: https://issues.apache.org/jira/browse/IGNITE-18559
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> At the moment the least restrictive type between VARCHAR and DECIMAL is
> DECIMAL(precision=32767, scale=16383). See TypeCoercionTest
> testVarCharToNumeric.
> Investigate why that happens and whether it is a problem or not.
> Test query:
> {code:java}
> SELECT NULLIF(12.2, 'b') -- Should fail since types do not match {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18559) Sql. The least restrictive type between VARCHAR and DECIMAL is DECIMAL(precision=32767, scale=16383)
[
https://issues.apache.org/jira/browse/IGNITE-18559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich reassigned IGNITE-18559:
---
Assignee: Iurii Gerzhedovich
> Sql. The least restrictive type between VARCHAR and DECIMAL is
> DECIMAL(precision=32767, scale=16383)
>
>
> Key: IGNITE-18559
> URL: https://issues.apache.org/jira/browse/IGNITE-18559
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Iurii Gerzhedovich
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> At the moment the least restrictive type between VARCHAR and DECIMAL is
> DECIMAL(precision=32767, scale=16383). See TypeCoercionTest
> testVarCharToNumeric.
> Investigate why that happens and whether it is a problem or not.
> Test query:
> {code:java}
> SELECT NULLIF(12.2, 'b') -- Should fail since types do not match {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22219) Remove unused code for hanlding SqlQuery
[
https://issues.apache.org/jira/browse/IGNITE-22219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846923#comment-17846923
]
Ignite TC Bot commented on IGNITE-22219:
{panel:title=Branch: [pull/11347/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11347/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=7867772buildTypeId=IgniteTests24Java8_RunAll]
> Remove unused code for hanlding SqlQuery
>
>
> Key: IGNITE-22219
> URL: https://issues.apache.org/jira/browse/IGNITE-22219
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> SqlQuery uses SqlFieldsQuery pipeline, then code for SqlQuery in cache
> queries is useless.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22231) Implement zone creation trigger for ZoneReplicasManager component
[ https://issues.apache.org/jira/browse/IGNITE-22231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22231: Description: *Motivation* As a first step of ZoneReplicasManager implementation we need to implement the basic flow of reaction to new zone creation trigger. *Definition of done* - When the new zone created in catalog - start the appropriate RAFT node with empty partition listener; start the replica with empty replica listener - Implement the test PlacementDriver, which always choose the zone replica as a primary one (zone replicas should have the appropriate prefix). And write appropriate test which should insert the data to noop state machine successfully. was: *Motivation* As a first step of ZoneReplicasManager implementation we need to implement the basic flow of reaction to new zone creation trigger. *Definition of done* - When the new zone created in catalog - start the appropriate RAFT node with empty partition listener; start the replica with empty replica listener - Implement the test PlacementDriver, which always choose the zone replica as a primary one (zone replicas should have the appropriate prefix) > Implement zone creation trigger for ZoneReplicasManager component > - > > Key: IGNITE-22231 > URL: https://issues.apache.org/jira/browse/IGNITE-22231 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > As a first step of ZoneReplicasManager implementation we need to implement > the basic flow of reaction to new zone creation trigger. > *Definition of done* > - When the new zone created in catalog - start the appropriate RAFT node with > empty partition listener; start the replica with empty replica listener > - Implement the test PlacementDriver, which always choose the zone replica as > a primary one (zone replicas should have the appropriate prefix). And write > appropriate test which should insert the data to noop state machine > successfully. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22231) Implement zone creation trigger for ZoneReplicasManager component
[ https://issues.apache.org/jira/browse/IGNITE-22231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22231: Description: *Motivation* As a first step of ZoneReplicasManager implementation we need to implement the basic flow of reaction to new zone creation trigger. *Definition of done* - When the new zone created in catalog - start the appropriate RAFT node with empty partition listener; start the replica with empty replica listener - Implement the test PlacementDriver, which always choose the zone replica as a primary one (zone replicas should have the appropriate prefix) was: *Motivation* As a first step of ZoneReplicasManager implementation we need to implement the basic flow of reaction to new zone creation trigger. *Definition of done* - On the component start assignments calculated and wrote to separate metastore prefix (to avoid the clash with the real current table assignments) - When the new zone created in catalog - start the appropriate RAFT node with empty partition listener; start the replica with empty replica listener - Implement the test PlacementDriver, which always choose the zone replica as a primary one (zone replicas should have the appropriate prefix) > Implement zone creation trigger for ZoneReplicasManager component > - > > Key: IGNITE-22231 > URL: https://issues.apache.org/jira/browse/IGNITE-22231 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > As a first step of ZoneReplicasManager implementation we need to implement > the basic flow of reaction to new zone creation trigger. > *Definition of done* > - When the new zone created in catalog - start the appropriate RAFT node with > empty partition listener; start the replica with empty replica listener > - Implement the test PlacementDriver, which always choose the zone replica as > a primary one (zone replicas should have the appropriate prefix) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22155) Introduce new component ZoneReplicasManager
[ https://issues.apache.org/jira/browse/IGNITE-22155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-22155: Description: *Motivation* To implement the further steps in the zone-based collocation track we need to prepare the new component ZoneReplicasManager. *Definition of done* * Component created under the separate module * Component started before the table manager, but after the zone manager * Component has the feature flag and working only when it is activated was: *Motivation* To implement the further steps in the zone-based collocation track we need to move the logic around start/stop replicas to separate component ZoneReplicasManager. *Definition of done* - Component listens the zone creation/drop events (and do nothing at the moment, but will populate the PartitionListener by TableProcessors in future) - Component listens the table create/drop events and start the appropriate replicas/partition listeners - Component initializes the appropriate rebalance listeners > Introduce new component ZoneReplicasManager > --- > > Key: IGNITE-22155 > URL: https://issues.apache.org/jira/browse/IGNITE-22155 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > *Motivation* > To implement the further steps in the zone-based collocation track we need to > prepare the new component ZoneReplicasManager. > *Definition of done* > * Component created under the separate module > * Component started before the table manager, but after the zone manager > * Component has the feature flag and working only when it is activated -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21812) Add automatic product version resolve
[ https://issues.apache.org/jira/browse/IGNITE-21812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev reassigned IGNITE-21812: - Assignee: Vadim Pakhnushev > Add automatic product version resolve > - > > Key: IGNITE-21812 > URL: https://issues.apache.org/jira/browse/IGNITE-21812 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > > Now the product version is hardcoded in EventBuilder but we can fetch the > product version automatically from the environment that can be formed during > the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22255) Use proper product version in events
[
https://issues.apache.org/jira/browse/IGNITE-22255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev resolved IGNITE-22255.
---
Resolution: Duplicate
> Use proper product version in events
>
>
> Key: IGNITE-22255
> URL: https://issues.apache.org/jira/browse/IGNITE-22255
> Project: Ignite
> Issue Type: Bug
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
>
> {{IgniteEvents}} use hardcoded "3.0.0" version, we should use
> {{IgniteProductVersion.CURRENT_VERSION}} instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22255) Use proper product version in events
Vadim Pakhnushev created IGNITE-22255:
-
Summary: Use proper product version in events
Key: IGNITE-22255
URL: https://issues.apache.org/jira/browse/IGNITE-22255
Project: Ignite
Issue Type: Bug
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
{{IgniteEvents}} use hardcoded "3.0.0" version, we should use
{{IgniteProductVersion.CURRENT_VERSION}} instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16116) Support user mapping functions
[
https://issues.apache.org/jira/browse/IGNITE-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-16116:
Summary: Support user mapping functions (was: Support user mapping
functions.)
> Support user mapping functions
> --
>
> Key: IGNITE-16116
> URL: https://issues.apache.org/jira/browse/IGNITE-16116
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> Let's allow users to implement their own strategy of marshaling objects.
> The {{Tuple}} interface looks good candidate for representing a row, rather
> than exposing any internals to the user.
> Start point is {{Mapper.of(Function objectToRow, Function
> rowToObject)}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22254) Cluster initialization fails when event log is configured
[
https://issues.apache.org/jira/browse/IGNITE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev updated IGNITE-22254:
--
Description:
When event logging is configured in the cluster init configuration:
{code:java}
eventlog {
sinks.logSink.channel: testChannel,
channels.testChannel.events: [USER_AUTHENTICATED]
}
{code}
Then the cluster initialization fails with the following exception:
{code:java}
InitException: ... Unable to initialize the cluster: Validation did not pass
for keys: [eventlog.channels.testChannel.events, Unable to find event type
'USER_AUTHENTICATED' in the system. Please, make sure you set the correct event
type.]{code}
was:
When event logging is configured in the cluster init configuration:
{code:java}
eventlog {
sinks.logSink: { channel: testChannel },
channels.testChannel.events: [USER_AUTHENTICATED]
}
{code}
Then the cluster initialization fails with the following exception:
{code:java}
InitException: ... Unable to initialize the cluster: Validation did not pass
for keys: [eventlog.channels.testChannel.events, Unable to find event type
'USER_AUTHENTICATED' in the system. Please, make sure you set the correct event
type.]{code}
> Cluster initialization fails when event log is configured
> -
>
> Key: IGNITE-22254
> URL: https://issues.apache.org/jira/browse/IGNITE-22254
> Project: Ignite
> Issue Type: Bug
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When event logging is configured in the cluster init configuration:
> {code:java}
> eventlog {
> sinks.logSink.channel: testChannel,
> channels.testChannel.events: [USER_AUTHENTICATED]
> }
> {code}
> Then the cluster initialization fails with the following exception:
> {code:java}
> InitException: ... Unable to initialize the cluster: Validation did not pass
> for keys: [eventlog.channels.testChannel.events, Unable to find event type
> 'USER_AUTHENTICATED' in the system. Please, make sure you set the correct
> event type.]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22254) Cluster initialization fails when event log is configured
[
https://issues.apache.org/jira/browse/IGNITE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev updated IGNITE-22254:
--
Description:
When event logging is configured in the cluster init configuration:
{code:java}
eventlog {
sinks.logSink: { channel: testChannel },
channels.testChannel.events: [USER_AUTHENTICATED]
}
{code}
Then the cluster initialization fails with the following exception:
{code:java}
InitException: ... Unable to initialize the cluster: Validation did not pass
for keys: [eventlog.channels.testChannel.events, Unable to find event type
'USER_AUTHENTICATED' in the system. Please, make sure you set the correct event
type.]{code}
was:
When event logging is configured in the cluster init configuration:
{code}
eventlog {
sinks.logSink: { channel: testChannel },
channels.testChannel: { events: [USER_AUTHENTICATED] }
}
{code}
Then the cluster initialization fails with the following exception:
{code}
InitException: ... Unable to initialize the cluster: Validation did not pass
for keys: [eventlog.channels.testChannel.events, Unable to find event type
'USER_AUTHENTICATED' in the system. Please, make sure you set the correct event
type.]{code}
> Cluster initialization fails when event log is configured
> -
>
> Key: IGNITE-22254
> URL: https://issues.apache.org/jira/browse/IGNITE-22254
> Project: Ignite
> Issue Type: Bug
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When event logging is configured in the cluster init configuration:
> {code:java}
> eventlog {
> sinks.logSink: { channel: testChannel },
> channels.testChannel.events: [USER_AUTHENTICATED]
> }
> {code}
> Then the cluster initialization fails with the following exception:
> {code:java}
> InitException: ... Unable to initialize the cluster: Validation did not pass
> for keys: [eventlog.channels.testChannel.events, Unable to find event type
> 'USER_AUTHENTICATED' in the system. Please, make sure you set the correct
> event type.]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22254) Cluster initialization fails when event log is configured
[
https://issues.apache.org/jira/browse/IGNITE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev updated IGNITE-22254:
--
Summary: Cluster initialization fails when event log is configured (was:
Cluster can't initialize when event log is configured)
> Cluster initialization fails when event log is configured
> -
>
> Key: IGNITE-22254
> URL: https://issues.apache.org/jira/browse/IGNITE-22254
> Project: Ignite
> Issue Type: Bug
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
>
> When event logging is configured in the cluster init configuration:
> {code}
> eventlog {
> sinks.logSink: { channel: testChannel },
> channels.testChannel: { events: [USER_AUTHENTICATED] }
> }
> {code}
> Then the cluster initialization fails with the following exception:
> {code}
> InitException: ... Unable to initialize the cluster: Validation did not pass
> for keys: [eventlog.channels.testChannel.events, Unable to find event type
> 'USER_AUTHENTICATED' in the system. Please, make sure you set the correct
> event type.]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22251) Fix tests in ItIgniteNodeRestartTest after adding new system views
[ https://issues.apache.org/jira/browse/IGNITE-22251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-22251: Assignee: Denis Chudov > Fix tests in ItIgniteNodeRestartTest after adding new system views > -- > > Key: IGNITE-22251 > URL: https://issues.apache.org/jira/browse/IGNITE-22251 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Tkalenko >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > After adding new system views for disaster recovery, only tests from > *org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest* began to > fail, because the constant > *org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest#TABLE_ID* is > used and this is not correct since it can easily change, you need to take it > honestly from the catalog or in another way. > See *@Disabled* in *ItIgniteNodeRestartTest* and TODO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22251) Fix tests in ItIgniteNodeRestartTest after adding new system views
[
https://issues.apache.org/jira/browse/IGNITE-22251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-22251:
-
Description:
After adding new system views for disaster recovery, only tests from
*org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest* began to fail,
because the constant
*org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest#TABLE_ID* is
used and this is not correct since it can easily change, you need to take it
honestly from the catalog or in another way.
See *@Disabled* in *ItIgniteNodeRestartTest* and TODO.
was:
After adding new system views for disaster recovery, only one tests from
*org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest* began to fail,
judging by the initial analysis, the problem was due to the use of both
*org.apache.ignite.internal.BaseIgniteRestartTest#startNode(int)* (regular
ignite node starts) and
*org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest#startPartialNode*
({color:#DE350B}NOT{color} regular ignite node starts), which differ in the
number of components and the order in which they are launched.
See *@Disabled* in *ItIgniteNodeRestartTest*.
> Fix tests in ItIgniteNodeRestartTest after adding new system views
> --
>
> Key: IGNITE-22251
> URL: https://issues.apache.org/jira/browse/IGNITE-22251
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
>
> After adding new system views for disaster recovery, only tests from
> *org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest* began to
> fail, because the constant
> *org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest#TABLE_ID* is
> used and this is not correct since it can easily change, you need to take it
> honestly from the catalog or in another way.
> See *@Disabled* in *ItIgniteNodeRestartTest* and TODO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22254) Cluster can't initialize when event log is configured
Vadim Pakhnushev created IGNITE-22254:
-
Summary: Cluster can't initialize when event log is configured
Key: IGNITE-22254
URL: https://issues.apache.org/jira/browse/IGNITE-22254
Project: Ignite
Issue Type: Bug
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
When event logging is configured in the cluster init configuration:
{code}
eventlog {
sinks.logSink: { channel: testChannel },
channels.testChannel: { events: [USER_AUTHENTICATED] }
}
{code}
Then the cluster initialization fails with the following exception:
{code}
InitException: ... Unable to initialize the cluster: Validation did not pass
for keys: [eventlog.channels.testChannel.events, Unable to find event type
'USER_AUTHENTICATED' in the system. Please, make sure you set the correct event
type.]{code}
--
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: Labels: iep-102 iep-121 ignite-3 (was: iep-102 ignite-3) > 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 Use Case 2 in the > [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21410) Ignite 3.0: Create tables from Java classes
[ https://issues.apache.org/jira/browse/IGNITE-21410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21410: Labels: iep-123 ignite-3 (was: ignite-3) > Ignite 3.0: Create tables from Java classes > --- > > Key: IGNITE-21410 > URL: https://issues.apache.org/jira/browse/IGNITE-21410 > Project: Ignite > Issue Type: Epic >Reporter: Vadim Kolodin >Priority: Major > Labels: iep-123, ignite-3 > > In addition to SQL DDL commands, provide a simple Java API for initial tables > generation from POJO. Support custom annotations and simple builders. This > feature should work seamlessly with existing Mapper interface (keyValueView > and recordView). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19546) .NET: Thin 3.0: Data Streamer with Receiver
[ https://issues.apache.org/jira/browse/IGNITE-19546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19546: Labels: .NET iep-102 iep-121 ignite-3 (was: .NET iep-102 ignite-3) > .NET: Thin 3.0: Data Streamer with Receiver > --- > > Key: IGNITE-19546 > URL: https://issues.apache.org/jira/browse/IGNITE-19546 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-102, iep-121, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement data streamer with receiver in .NET client - see Use Case 2 in the > [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22058) Use paranoid leak detection in tests
[ https://issues.apache.org/jira/browse/IGNITE-22058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846868#comment-17846868 ] Pavel Tupitsyn commented on IGNITE-22058: - Let's enable leak detection for CLI and JDBC tests as well, those use thin client internally. > Use paranoid leak detection in tests > > > Key: IGNITE-22058 > URL: https://issues.apache.org/jira/browse/IGNITE-22058 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We should set `io.netty.leakDetection.level=paranoid` in integration tests > and network tests, in order to detect possible leaks. > https://netty.io/wiki/reference-counted-objects.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22224) Rework embedded mode API
[
https://issues.apache.org/jira/browse/IGNITE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin reassigned IGNITE-4:
--
Assignee: Vadim Pakhnushev
> Rework embedded mode API
> -
>
> Key: IGNITE-4
> URL: https://issues.apache.org/jira/browse/IGNITE-4
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Pochatkin
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
>
> Currently, we have follow classes in *ignite-api*
> # org.apache.ignite.Ignite
> # org.apache.ignite.Ignition
> # org.apache.ignite.IgnitionManager
> # org.apache.ignite.InitParameters
> # org.apache.ignite.InitParametersBuilder
> While the first interface still makes sense, since it is the access point to
> the entire public API, the others have no such relationship to the API. These
> classes and interface are necessary to start *Apache Ignite 3* in embedded
> mode and cannot be used on their own, but you need to have access to the
> *ignite-runner* module and use implementations from there.
>
> This ticket proposes to remove these interfaces from the module with the
> public API and move them to the new module {*}ignite-embedded{*}. Also, by
> anology with Thin Clients we should rework *Ignition* interface and create
> *IgniteEmbedded* interface which should be entry point to embedded mode.
> *IgnitionManager* interface should be removed and *IgniteEmbedded* creation
> process reworked to builder pattern like Thin Clients.
> Cluster initialization process also should be reworked and all initialization
> methods moved to *IgniteEmbedded* interface.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22058) Use paranoid leak detection in tests
[ https://issues.apache.org/jira/browse/IGNITE-22058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22058: Description: We should set `io.netty.leakDetection.level=paranoid` in integration tests and network tests, in order to detect possible leaks. https://netty.io/wiki/reference-counted-objects.html was:We should set `io.netty.leakDetection.level=paranoid` in integration tests and network tests, in order to detect possible leaks > Use paranoid leak detection in tests > > > Key: IGNITE-22058 > URL: https://issues.apache.org/jira/browse/IGNITE-22058 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We should set `io.netty.leakDetection.level=paranoid` in integration tests > and network tests, in order to detect possible leaks. > https://netty.io/wiki/reference-counted-objects.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21984) Extend test coverage for SQL T621(Enhanced numeric functions)
[ https://issues.apache.org/jira/browse/IGNITE-21984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-21984: Description: Test coverage for SQL T621(Enhanced numeric functions) is poor. Let's increase the test coverage. ref - test/sql/function/numeric/test_pg_math.test T621 defines: 1. *natural logarithm* (supported, test: test_pg_math.test) 2. *exponential function* (supported, test: test_pg_math.test) 3. *power function* (supported, test: test_pow.test) 4. *square root* (supported, test: test_pg_math.test) 5. *ceiling function* (supported, test: test_pg_math.test) 6. *STDDEV_POP, STDDEV_SAMP, VAR_POP, VAR_SAMP* (not supported, test: test_stddev.test_ignore) 7. *binary set function type*, i.e : COVAR_POP, COVAR_SAMP, CORR, REGR_SLOPE, REGR_INTERCEPT, REGR_COUNT, REGR_R2, REGR_AVGX, REGR_AVGY, REGR_SXX, REGR_SYY, REGR_SXY (not supported, test: test_covar.test_ignore) was: Test coverage for SQL T621(Enhanced numeric functions) is poor. Let's increase the test coverage. ref - test/sql/function/numeric/test_pg_math.test T621 defines: 1. *natural logarithm* (supported, test: test_pg_math.test) 2. *exponential function* (supported, test: test_pg_math.test) 3. *power function* (supported, test: test_pow.test) 4. *square root* (supported, test: test_pg_math.test) 5. *ceiling function* (supported, test: test_pg_math.test) 6. *STDDEV_POP, STDDEV_SAMP, VAR_POP, VAR_SAMP* (not supported, test: test_stddev.test_ignore) 7. *binary set function type*, i.e : COVAR_POP, COVAR_SAMP, CORR, REGR_SLOPE, REGR_INTERCEPT, REGR_COUNT, REGR_R2, REGR_AVGX, REGR_AVGY, REGR_SXX, REGR_SYY, REGR_SXY > Extend test coverage for SQL T621(Enhanced numeric functions) > - > > Key: IGNITE-21984 > URL: https://issues.apache.org/jira/browse/IGNITE-21984 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Test coverage for SQL T621(Enhanced numeric functions) is poor. > Let's increase the test coverage. > > ref - test/sql/function/numeric/test_pg_math.test > T621 defines: > 1. *natural logarithm* (supported, test: test_pg_math.test) > 2. *exponential function* (supported, test: test_pg_math.test) > 3. *power function* (supported, test: test_pow.test) > 4. *square root* (supported, test: test_pg_math.test) > 5. *ceiling function* (supported, test: test_pg_math.test) > 6. *STDDEV_POP, STDDEV_SAMP, VAR_POP, VAR_SAMP* (not supported, test: > test_stddev.test_ignore) > 7. *binary set function type*, i.e : > COVAR_POP, COVAR_SAMP, CORR, REGR_SLOPE, REGR_INTERCEPT, REGR_COUNT, REGR_R2, > REGR_AVGX, REGR_AVGY, REGR_SXX, REGR_SYY, REGR_SXY (not supported, test: > test_covar.test_ignore) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22172) Make ignite-collocation-feature branch stable
[ https://issues.apache.org/jira/browse/IGNITE-22172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846862#comment-17846862 ] Vladislav Pyatkov edited comment on IGNITE-22172 at 5/16/24 7:56 AM: - Merged in feature branch. https://github.com/gridgain/apache-ignite-3/tree/ignite-collocation-feature was (Author: v.pyatkov): Merged in feature branch. > Make ignite-collocation-feature branch stable > - > > Key: IGNITE-22172 > URL: https://issues.apache.org/jira/browse/IGNITE-22172 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > h3. Motivation > Too many flaky tests are there. This behavior does not allow us to review a > new patch to the branch because TC is permanently red. > h3. Definition of done > Meke TC green for the ignite-collocation-feature branch. > If this point is not acceptable, we need to describe the current issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21984) Extend test coverage for SQL T621(Enhanced numeric functions)
[ https://issues.apache.org/jira/browse/IGNITE-21984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-21984: Description: Test coverage for SQL T621(Enhanced numeric functions) is poor. Let's increase the test coverage. ref - test/sql/function/numeric/test_pg_math.test T621 defines: 1. *natural logarithm* (supported, test: test_pg_math.test) 2. *exponential function* (supported, test: test_pg_math.test) 3. *power function* (supported, test: test_pow.test) 4. *square root* (supported, test: test_pg_math.test) 5. *ceiling function* (supported, test: test_pg_math.test) 6. *STDDEV_POP, STDDEV_SAMP, VAR_POP, VAR_SAMP* (not supported, test: test_stddev.test_ignore) 7. *binary set function type*, i.e : COVAR_POP, COVAR_SAMP, CORR, REGR_SLOPE, REGR_INTERCEPT, REGR_COUNT, REGR_R2, REGR_AVGX, REGR_AVGY, REGR_SXX, REGR_SYY, REGR_SXY was: Test coverage for SQL T621(Enhanced numeric functions) is poor. Let's increase the test coverage. ref - test/sql/function/numeric/test_pg_math.test > Extend test coverage for SQL T621(Enhanced numeric functions) > - > > Key: IGNITE-21984 > URL: https://issues.apache.org/jira/browse/IGNITE-21984 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Test coverage for SQL T621(Enhanced numeric functions) is poor. > Let's increase the test coverage. > > ref - test/sql/function/numeric/test_pg_math.test > T621 defines: > 1. *natural logarithm* (supported, test: test_pg_math.test) > 2. *exponential function* (supported, test: test_pg_math.test) > 3. *power function* (supported, test: test_pow.test) > 4. *square root* (supported, test: test_pg_math.test) > 5. *ceiling function* (supported, test: test_pg_math.test) > 6. *STDDEV_POP, STDDEV_SAMP, VAR_POP, VAR_SAMP* (not supported, test: > test_stddev.test_ignore) > 7. *binary set function type*, i.e : > COVAR_POP, COVAR_SAMP, CORR, REGR_SLOPE, REGR_INTERCEPT, REGR_COUNT, REGR_R2, > REGR_AVGX, REGR_AVGY, REGR_SXX, REGR_SYY, REGR_SXY > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22245) Write intents are not switched if primary changes
[ https://issues.apache.org/jira/browse/IGNITE-22245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22245: - Ignite Flags: (was: Docs Required,Release Notes Required) > Write intents are not switched if primary changes > - > > Key: IGNITE-22245 > URL: https://issues.apache.org/jira/browse/IGNITE-22245 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Sizov >Assignee: Kirill Sizov >Priority: Major > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > > If during the cleanup process the cleanup request fails to execute on an > initially enlisted node the durable cleanup logic retries the cleanup request > on the new partition primaries. > Since the new primary node does not have in-memory transactional state, it > skips write intent switch and reports successful cleanup. > As a result we get a successfully completed transaction with write intents > instead of real data in the storage. We had been covered with write intent > resolution before vacuum was introduced. > Now, if the state has been vacuumized, there is no chance to correctly > resolve such write intents and we get corrupted data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22253) Add a command to clean WAL segments in cdc directory
[ https://issues.apache.org/jira/browse/IGNITE-22253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-22253: Description: Users cleans cdc directory with `rm -rf` that might delete system files and break CDC pipeline. Users goal is to clean segments as they require disk space while a cdc receiver is off. Steps are as the following: # Disable CDC by setting the flag cdc.disabled = true # Remove the segments. # Await while the receiver come back. # Set cdc.disabled = false # Resend whole data with the `resend` command. We need a control.sh command to clean the directory. Should the command disable CDC also? was: Users cleans cdc directory with `rm -rf` that might delete system files and break CDC pipeline. Users goal is to clean segments as they require disk space while a cdc receiver is off. Steps are as the following: # Disable CDC by setting the flag cdc.disabled = true # Remove the segments. # Await while the receiver come back. # Set cdc.disabled = false # Resend whole data with the `resend` command. We need a control.sh command to clean the directory. > Add a command to clean WAL segments in cdc directory > > > Key: IGNITE-22253 > URL: https://issues.apache.org/jira/browse/IGNITE-22253 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.17 > > > Users cleans cdc directory with `rm -rf` that might delete system files and > break CDC pipeline. > Users goal is to clean segments as they require disk space while a cdc > receiver is off. Steps are as the following: > # Disable CDC by setting the flag cdc.disabled = true > # Remove the segments. > # Await while the receiver come back. > # Set cdc.disabled = false > # Resend whole data with the `resend` command. > We need a control.sh command to clean the directory. Should the command > disable CDC also? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22253) Add a command to clean WAL segments in cdc directory
[ https://issues.apache.org/jira/browse/IGNITE-22253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-22253: Description: Users cleans cdc directory with `rm -rf` that might delete system files and break CDC pipeline. Users goal is to clean segments as they require disk space while a cdc receiver is off. Steps are as the following: # Disable CDC by setting the flag cdc.disabled = true # Remove the segments. # Await while the receiver come back. # Set cdc.disabled = false # Resend whole data with the `resend` command. We need a control.sh command to clean the directory. was: Users cleans cdc directory with `rm -rf` that might delete system files and break CDC pipeline. Users goal is to clean segments as they require disk space while a cdc receiver is off. So it's OK to remove the segments and resend all data after the receiver come back. We need a control.sh command to clean the directory. > Add a command to clean WAL segments in cdc directory > > > Key: IGNITE-22253 > URL: https://issues.apache.org/jira/browse/IGNITE-22253 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.17 > > > Users cleans cdc directory with `rm -rf` that might delete system files and > break CDC pipeline. > Users goal is to clean segments as they require disk space while a cdc > receiver is off. Steps are as the following: > # Disable CDC by setting the flag cdc.disabled = true > # Remove the segments. > # Await while the receiver come back. > # Set cdc.disabled = false > # Resend whole data with the `resend` command. > We need a control.sh command to clean the directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22253) Add a command to clean WAL segments in cdc directory
[ https://issues.apache.org/jira/browse/IGNITE-22253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-22253: Fix Version/s: 2.17 > Add a command to clean WAL segments in cdc directory > > > Key: IGNITE-22253 > URL: https://issues.apache.org/jira/browse/IGNITE-22253 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > Fix For: 2.17 > > > Users cleans cdc directory with `rm -rf` that might delete system files and > break CDC pipeline. > Users goal is to clean segments as they require disk space while a cdc > receiver is off. So it's OK to remove the segments and resend all data after > the receiver come back. > We need a control.sh command to clean the directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22253) Add a command to clean WAL segments in cdc directory
[ https://issues.apache.org/jira/browse/IGNITE-22253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-22253: Labels: ise (was: ) > Add a command to clean WAL segments in cdc directory > > > Key: IGNITE-22253 > URL: https://issues.apache.org/jira/browse/IGNITE-22253 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: ise > > Users cleans cdc directory with `rm -rf` that might delete system files and > break CDC pipeline. > Users goal is to clean segments as they require disk space while a cdc > receiver is off. So it's OK to remove the segments and resend all data after > the receiver come back. > We need a control.sh command to clean the directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22253) Add a command to clean WAL segments in cdc directory
Maksim Timonin created IGNITE-22253: --- Summary: Add a command to clean WAL segments in cdc directory Key: IGNITE-22253 URL: https://issues.apache.org/jira/browse/IGNITE-22253 Project: Ignite Issue Type: Improvement Reporter: Maksim Timonin Assignee: Maksim Timonin Users cleans cdc directory with `rm -rf` that might delete system files and break CDC pipeline. Users goal is to clean segments as they require disk space while a cdc receiver is off. So it's OK to remove the segments and resend all data after the receiver come back. We need a control.sh command to clean the directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21984) Extend test coverage for SQL T621(Enhanced numeric functions)
[ https://issues.apache.org/jira/browse/IGNITE-21984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846851#comment-17846851 ] Evgeny Stanilovsky edited comment on IGNITE-21984 at 5/16/24 7:34 AM: -- Feature is implemented partially, appropriate implementation issue is attached. was (Author: zstan): Feature is not implemented for now, appropriate implementation issue is attached. > Extend test coverage for SQL T621(Enhanced numeric functions) > - > > Key: IGNITE-21984 > URL: https://issues.apache.org/jira/browse/IGNITE-21984 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Test coverage for SQL T621(Enhanced numeric functions) is poor. > Let's increase the test coverage. > > ref - test/sql/function/numeric/test_pg_math.test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21984) Extend test coverage for SQL T621(Enhanced numeric functions)
[ https://issues.apache.org/jira/browse/IGNITE-21984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846851#comment-17846851 ] Evgeny Stanilovsky commented on IGNITE-21984: - Feature is not implemented for now, appropriate implementation issue is attached. > Extend test coverage for SQL T621(Enhanced numeric functions) > - > > Key: IGNITE-21984 > URL: https://issues.apache.org/jira/browse/IGNITE-21984 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Test coverage for SQL T621(Enhanced numeric functions) is poor. > Let's increase the test coverage. > > ref - test/sql/function/numeric/test_pg_math.test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22252) Sql. Implement aggregate functions according to standard Feature T621
Evgeny Stanilovsky created IGNITE-22252:
---
Summary: Sql. Implement aggregate functions according to standard
Feature T621
Key: IGNITE-22252
URL: https://issues.apache.org/jira/browse/IGNITE-22252
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
Standard defines Feature T621 as support for STDDEV_POP, STDDEV_SAMP, VAR_POP,
VAR_SAMP. Seems all we need to implement such functionality:
# Register appropriate in IgniteSqlOperatorTable
# Append IgniteSqlValidator#validateAggregateFunction
# Define implementation here Accumulators#accumulatorFunctionFactory
# And the main (because calcite derive incorrect return type by default)
override IgniteTypeSystem.deriveAvgAggType
According to standard :
STDDEV_POP(X) is equivalent to SQRT(VAR_POP(X)).
STDDEV_SAMP(X) is equivalent to SQRT(VAR_SAMP(X)).
Thus derived type need to be double or BigDecimal if we need to use
java.math.BigDecimal.sqrt
useful implementation info can be found here
AggregateReduceFunctionsRule#reduceAgg
{noformat}
STDDEV_POP:
SQRT((SUM(x * x) - SUM(x) * SUM(x) / COUNT(x)) / COUNT(x))
STDDEV_SAMP:
SQRT((SUM(x * x) - SUM(x) * SUM(x) / COUNT(x)) / CASE COUNT(x) WHEN 1
THEN NULL ELSE COUNT(x) - 1 END)
VAR_POP:
(SUM(x * x) - SUM(x) * SUM(x) / COUNT(x)) / COUNT(x)
case VAR_SAMP:
(SUM(x * x) - SUM(x) * SUM(x) / COUNT(x)) / CASE COUNT(x) WHEN 1 THEN
NULL ELSE COUNT(x) - 1 END
{noformat}
Also need to mention that results for appropriate muted tests (for example
test_stddev.test_ignore) are not correct (sqrt return is trimmed) and pg
returns a bit different results that corresponds to standard, need to fix
return results too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22251) Fix tests in ItIgniteNodeRestartTest after adding new system views
[
https://issues.apache.org/jira/browse/IGNITE-22251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-22251:
-
Description:
After adding new system views for disaster recovery, only one tests from
*org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest* began to fail,
judging by the initial analysis, the problem was due to the use of both
*org.apache.ignite.internal.BaseIgniteRestartTest#startNode(int)* (regular
ignite node starts) and
*org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest#startPartialNode*
({color:#DE350B}NOT{color} regular ignite node starts), which differ in the
number of components and the order in which they are launched.
See *@Disabled* in *ItIgniteNodeRestartTest*.
was:
After adding new system views for disaster recovery, only one tests from
*org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest* began to fail,
judging by the initial analysis, the problem was due to the use of both
*org.apache.ignite.internal.BaseIgniteRestartTest#startNode(int)* (regular
ignite node starts) and
*org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest#startPartialNode*
(*{color:#DE350B}NOT {color}*regular ignite node starts), which differ in the
number of components and the order in which they are launched.
See *@Disabled* in *ItIgniteNodeRestartTest*.
> Fix tests in ItIgniteNodeRestartTest after adding new system views
> --
>
> Key: IGNITE-22251
> URL: https://issues.apache.org/jira/browse/IGNITE-22251
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
>
> After adding new system views for disaster recovery, only one tests from
> *org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest* began to
> fail, judging by the initial analysis, the problem was due to the use of both
> *org.apache.ignite.internal.BaseIgniteRestartTest#startNode(int)* (regular
> ignite node starts) and
> *org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest#startPartialNode*
> ({color:#DE350B}NOT{color} regular ignite node starts), which differ in the
> number of components and the order in which they are launched.
> See *@Disabled* in *ItIgniteNodeRestartTest*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-18610) ItTableRaftSnapshotsTest#leaderFeedsFollowerWithSnapshot hangs
[
https://issues.apache.org/jira/browse/IGNITE-18610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy resolved IGNITE-18610.
Resolution: Fixed
Fixed by IGNITE-19234
> ItTableRaftSnapshotsTest#leaderFeedsFollowerWithSnapshot hangs
> ---
>
> Key: IGNITE-18610
> URL: https://issues.apache.org/jira/browse/IGNITE-18610
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: _Integration_Tests_Module_Runner_7366.log (1).zip
>
>
> It was found that
> *org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest#leaderFeedsFollowerWithSnapshot*
> could hang, it is not yet clear why, but the following stack trace was found
> in the logs, [TC
> link|https://ci.ignite.apache.org/viewLog.html?buildId=7023641=buildResultsDiv=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRunner=].
> I will also attach the [^_Integration_Tests_Module_Runner_7366.log (1).zip]
> , to start the analysis you need to find the line
> *org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.leaderFeedsFollowerWithSnapshot([3]
> aimem) (running for 25m:11s)*.
> {noformat}
> 2023-01-23 20:09:22:012 +0300
> [ERROR][%itrst_lffws_2%JRaft-FSMCaller-Disruptor-_stripe_3-0][StripedDisruptor]
> Handle disruptor event error
> [name=%itrst_lffws_2%JRaft-FSMCaller-Disruptor-,
> event=org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTask@766e6436,
> hasHandler=false]
> org.apache.ignite.internal.storage.StorageClosedException: IGN-STORAGE-3
> TraceId:7e8dadf9-d715-494e-817f-67e2a75eabba Storage is already closed:
> [table=TEST, partitionId=0]
> at
> org.apache.ignite.internal.storage.util.StorageUtils.throwExceptionDependingOnStorageState(StorageUtils.java:81)
> at
> org.apache.ignite.internal.storage.pagememory.mv.AbstractPageMemoryMvPartitionStorage.busy(AbstractPageMemoryMvPartitionStorage.java:1037)
> at
> org.apache.ignite.internal.storage.pagememory.mv.VolatilePageMemoryMvPartitionStorage.lastAppliedIndex(VolatilePageMemoryMvPartitionStorage.java:102)
> at
> org.apache.ignite.internal.table.distributed.raft.snapshot.outgoing.SnapshotAwarePartitionDataStorage.lastAppliedIndex(SnapshotAwarePartitionDataStorage.java:87)
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.onConfigurationCommitted(PartitionListener.java:394)
> at
> org.apache.ignite.internal.raft.server.impl.JraftServerImpl$DelegatingStateMachine.onRawConfigurationCommitted(JraftServerImpl.java:642)
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl.doSnapshotLoad(FSMCallerImpl.java:695)
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl.runApplyTask(FSMCallerImpl.java:403)
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTaskHandler.onEvent(FSMCallerImpl.java:136)
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTaskHandler.onEvent(FSMCallerImpl.java:130)
> at
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:217)
> at
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:181)
> at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19234) Race between additional volatile storage assignment update and installation of RAFT snapshot
[ https://issues.apache.org/jira/browse/IGNITE-19234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846835#comment-17846835 ] Roman Puchkovskiy commented on IGNITE-19234: It turned out that the 'anti-double-vote' algorithm was not working for about half a year (it was erroneously disabled). So the following was done in the PR: # It was enabled back # Its implementation was fixed (as the common rebalancing code switched from storing serialized Set to storing serialized Assignments; this had to be changed for the algorithm as well; also, storages had to be accessed in correct threads, otherwise thread assertions were triggered) # StorageRebalanceException and StorageClosedException are handled > Race between additional volatile storage assignment update and installation > of RAFT snapshot > > > Key: IGNITE-19234 > URL: https://issues.apache.org/jira/browse/IGNITE-19234 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Code in TableManager#updateAssignmentInternal() has a specific case for > volatile storages, see IGNITE-16668. For them, an additional rebalance might > be triggered. This additional rebalance causes data races with > IncomingSnapshotCopier. > This is only about in-memory storages (namely, in-memory pagemem), it does > not harm persistent storages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22251) Fix tests in ItIgniteNodeRestartTest after adding new system views
Kirill Tkalenko created IGNITE-22251:
Summary: Fix tests in ItIgniteNodeRestartTest after adding new
system views
Key: IGNITE-22251
URL: https://issues.apache.org/jira/browse/IGNITE-22251
Project: Ignite
Issue Type: Bug
Reporter: Kirill Tkalenko
After adding new system views for disaster recovery, only one tests from
*org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest* began to fail,
judging by the initial analysis, the problem was due to the use of both
*org.apache.ignite.internal.BaseIgniteRestartTest#startNode(int)* (regular
ignite node starts) and
*org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest#startPartialNode*
(*{color:#DE350B}NOT {color}*regular ignite node starts), which differ in the
number of components and the order in which they are launched.
See *@Disabled* in *ItIgniteNodeRestartTest*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
