[jira] [Commented] (IGNITE-21313) Incorrect behaviour when invalid zone filter is applied to zone
[
https://issues.apache.org/jira/browse/IGNITE-21313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813528#comment-17813528
]
Vladislav Pyatkov commented on IGNITE-21313:
Merged 9e7288ab46924324a576af30009e4021efdfd849
> Incorrect behaviour when invalid zone filter is applied to zone
>
>
> Key: IGNITE-21313
> URL: https://issues.apache.org/jira/browse/IGNITE-21313
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Let's consider this code to be run in a test:
>
> {code:java}
> sql("CREATE ZONE ZONE1 WITH DATA_NODES_FILTER = 'INCORRECT_FILTER'");
> sql("CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0 INT) WITH
> PRIMARY_ZONE='ZONE1'"); {code}
> Current behaviour is that test hangs with spamming
>
> {noformat}
> [2024-01-19T12:56:25,163][ERROR][%ictdt_n_0%metastorage-watch-executor-2][WatchProcessor]
> Error occurred when notifying safe time advanced callback
> java.util.concurrent.CompletionException:
> com.jayway.jsonpath.PathNotFoundException: No results for path:
> $['INCORRECT_FILTER']
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:870)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883)
> [?:?]
> at
> java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2257)
> [?:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:213)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$3(WatchProcessor.java:169)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:829) [?:?]
> Caused by: com.jayway.jsonpath.PathNotFoundException: No results for path:
> $['INCORRECT_FILTER']{noformat}
>
> We need to fix that and formulate a reaction to an incorrect filter
>
> *Implementation notes:*
> To fix it we need to change implementation of DistributionZonesUtil#filter.
> Instead of
> {code:java}
> List> res = JsonPath.read(convertedAttributes,
> filter);{code}
> need to use
> {code:java}
> Configuration configuration = new Configuration.ConfigurationBuilder()
> .options(Option.SUPPRESS_EXCEPTIONS, Option.ALWAYS_RETURN_LIST)
> .build();
> List> res =
> JsonPath.using(configuration).parse(convertedAttributes).read(filter);{code}
> In this case incorrect filter will not throw PathNotFoundException and
> returns empty 'res'.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21366) AssertionError during the execution of the request
[
https://issues.apache.org/jira/browse/IGNITE-21366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-21366:
---
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> AssertionError during the execution of the request
> ---
>
> Key: IGNITE-21366
> URL: https://issues.apache.org/jira/browse/IGNITE-21366
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Nikolaev
>Assignee: Aleksandr Nikolaev
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If GridH2Table#cache size is greater than int, then we get an AssertionError:
> {code}
> -26T19:32:35,247][ERROR][main][] Test failed
> [test=RowCountTableStatisticsUsageTest#compareJoinsWithConditionsOnBothTables[cacheMode=REPLICATED],
> duration=10]
> java.lang.AssertionError: totalRowCnt=-4294967096, localRowCount=-2147483548
> at
> org.apache.ignite.internal.processors.query.h2.opt.TableStatistics.(TableStatistics.java:34)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.refreshStatsIfNeeded(GridH2Table.java:1055)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.getRowCountApproximation(GridH2Table.java:1013)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.getRowCountApproximation(GridH2IndexBase.java:226)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2ScanIndex.getRowCountApproximation(H2ScanIndex.java:158)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2ScanIndex.getCost(H2ScanIndex.java:289)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2TableScanIndex.getCost(H2TableScanIndex.java:74)
> ~[classes/:?]
> at org.h2.table.Table.getBestPlanItem(Table.java:714)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.table.TableFilter.getBestPlanItem(TableFilter.java:224)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.table.Plan.calculateCost(Plan.java:121)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.testPlan(Optimizer.java:180)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.calculateBestPlan(Optimizer.java:81)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.optimize(Optimizer.java:239)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Select.preparePlan(Select.java:1018)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Select.prepare(Select.java:884)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Explain.prepare(Explain.java:49)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.Parser.prepareCommand(Parser.java:283)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.Session.prepareLocal(Session.java:611)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.Session.prepareCommand(Session.java:549)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
> ~[h2-1.4.197.jar:1.4.197]
> at
> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
> ~[h2-1.4.197.jar:1.4.197]
> at
> org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:191)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.H2PooledConnection.prepareStatementNoCache(H2PooledConnection.java:109)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:341)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:225)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:138)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1011)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3115)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3086)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3821)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3132)
>
[jira] [Commented] (IGNITE-21313) Incorrect behaviour when invalid zone filter is applied to zone
[
https://issues.apache.org/jira/browse/IGNITE-21313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813511#comment-17813511
]
Mirza Aliev commented on IGNITE-21313:
--
LGTM
> Incorrect behaviour when invalid zone filter is applied to zone
>
>
> Key: IGNITE-21313
> URL: https://issues.apache.org/jira/browse/IGNITE-21313
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Let's consider this code to be run in a test:
>
> {code:java}
> sql("CREATE ZONE ZONE1 WITH DATA_NODES_FILTER = 'INCORRECT_FILTER'");
> sql("CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0 INT) WITH
> PRIMARY_ZONE='ZONE1'"); {code}
> Current behaviour is that test hangs with spamming
>
> {noformat}
> [2024-01-19T12:56:25,163][ERROR][%ictdt_n_0%metastorage-watch-executor-2][WatchProcessor]
> Error occurred when notifying safe time advanced callback
> java.util.concurrent.CompletionException:
> com.jayway.jsonpath.PathNotFoundException: No results for path:
> $['INCORRECT_FILTER']
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:870)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883)
> [?:?]
> at
> java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2257)
> [?:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:213)
> ~[main/:?]
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$3(WatchProcessor.java:169)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> [?:?]
> at
> java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:829) [?:?]
> Caused by: com.jayway.jsonpath.PathNotFoundException: No results for path:
> $['INCORRECT_FILTER']{noformat}
>
> We need to fix that and formulate a reaction to an incorrect filter
>
> *Implementation notes:*
> To fix it we need to change implementation of DistributionZonesUtil#filter.
> Instead of
> {code:java}
> List> res = JsonPath.read(convertedAttributes,
> filter);{code}
> need to use
> {code:java}
> Configuration configuration = new Configuration.ConfigurationBuilder()
> .options(Option.SUPPRESS_EXCEPTIONS, Option.ALWAYS_RETURN_LIST)
> .build();
> List> res =
> JsonPath.using(configuration).parse(convertedAttributes).read(filter);{code}
> In this case incorrect filter will not throw PathNotFoundException and
> returns empty 'res'.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21419) Optimize listener collection update in AbstractEventProducer
[
https://issues.apache.org/jira/browse/IGNITE-21419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813510#comment-17813510
]
Kirill Tkalenko commented on IGNITE-21419:
--
My variant not optimal, I have attached a benchmark and its results:
{noformat}
BenchmarkMode Cnt
Score Error Units
RemoveWithCopyListMicroBenchmark.remove100_000_middle_newavgt 25
865788,301 � 139764,886 ns/op
RemoveWithCopyListMicroBenchmark.remove100_000_middle_oldavgt 25
717813,727 � 79712,872 ns/op
RemoveWithCopyListMicroBenchmark.remove100_middle_newavgt 25
892,892 � 85,316 ns/op
RemoveWithCopyListMicroBenchmark.remove100_middle_oldavgt 25
731,736 � 99,779 ns/op
RemoveWithCopyListMicroBenchmark.remove10_000_middle_new avgt 25
85465,439 � 27578,902 ns/op
RemoveWithCopyListMicroBenchmark.remove10_000_middle_old avgt 25
62351,185 �5958,444 ns/op
RemoveWithCopyListMicroBenchmark.remove10_middle_new avgt 25
222,722 � 56,660 ns/op
RemoveWithCopyListMicroBenchmark.remove10_middle_old avgt 25
92,436 � 15,677 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_000_middle_new avgt 25
16297910,000 � 1053968,832 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_000_middle_old avgt 25
17191652,000 � 801548,036 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_middle_new avgt 25
8885,919 �1442,966 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_middle_old avgt 25
6076,685 � 907,782 ns/op
{noformat}
> Optimize listener collection update in AbstractEventProducer
>
>
> Key: IGNITE-21419
> URL: https://issues.apache.org/jira/browse/IGNITE-21419
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: RemoveWithCopyListMicroBenchmark.java
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I discovered that updating the collection of listeners in
> *org.apache.ignite.internal.event.AbstractEventProducer* is a little not
> optimal, I’m optimizing it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21419) Optimize listener collection update in AbstractEventProducer
[
https://issues.apache.org/jira/browse/IGNITE-21419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813510#comment-17813510
]
Kirill Tkalenko edited comment on IGNITE-21419 at 2/2/24 6:57 AM:
--
My variant not optimal, I have attached a
[^RemoveWithCopyListMicroBenchmark.java] and its results:
{noformat}
BenchmarkMode Cnt
Score Error Units
RemoveWithCopyListMicroBenchmark.remove100_000_middle_newavgt 25
865788,301 � 139764,886 ns/op
RemoveWithCopyListMicroBenchmark.remove100_000_middle_oldavgt 25
717813,727 � 79712,872 ns/op
RemoveWithCopyListMicroBenchmark.remove100_middle_newavgt 25
892,892 � 85,316 ns/op
RemoveWithCopyListMicroBenchmark.remove100_middle_oldavgt 25
731,736 � 99,779 ns/op
RemoveWithCopyListMicroBenchmark.remove10_000_middle_new avgt 25
85465,439 � 27578,902 ns/op
RemoveWithCopyListMicroBenchmark.remove10_000_middle_old avgt 25
62351,185 �5958,444 ns/op
RemoveWithCopyListMicroBenchmark.remove10_middle_new avgt 25
222,722 � 56,660 ns/op
RemoveWithCopyListMicroBenchmark.remove10_middle_old avgt 25
92,436 � 15,677 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_000_middle_new avgt 25
16297910,000 � 1053968,832 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_000_middle_old avgt 25
17191652,000 � 801548,036 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_middle_new avgt 25
8885,919 �1442,966 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_middle_old avgt 25
6076,685 � 907,782 ns/op
{noformat}
was (Author: ktkale...@gridgain.com):
My variant not optimal, I have attached a benchmark and its results:
{noformat}
BenchmarkMode Cnt
Score Error Units
RemoveWithCopyListMicroBenchmark.remove100_000_middle_newavgt 25
865788,301 � 139764,886 ns/op
RemoveWithCopyListMicroBenchmark.remove100_000_middle_oldavgt 25
717813,727 � 79712,872 ns/op
RemoveWithCopyListMicroBenchmark.remove100_middle_newavgt 25
892,892 � 85,316 ns/op
RemoveWithCopyListMicroBenchmark.remove100_middle_oldavgt 25
731,736 � 99,779 ns/op
RemoveWithCopyListMicroBenchmark.remove10_000_middle_new avgt 25
85465,439 � 27578,902 ns/op
RemoveWithCopyListMicroBenchmark.remove10_000_middle_old avgt 25
62351,185 �5958,444 ns/op
RemoveWithCopyListMicroBenchmark.remove10_middle_new avgt 25
222,722 � 56,660 ns/op
RemoveWithCopyListMicroBenchmark.remove10_middle_old avgt 25
92,436 � 15,677 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_000_middle_new avgt 25
16297910,000 � 1053968,832 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_000_middle_old avgt 25
17191652,000 � 801548,036 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_middle_new avgt 25
8885,919 �1442,966 ns/op
RemoveWithCopyListMicroBenchmark.remove1_000_middle_old avgt 25
6076,685 � 907,782 ns/op
{noformat}
> Optimize listener collection update in AbstractEventProducer
>
>
> Key: IGNITE-21419
> URL: https://issues.apache.org/jira/browse/IGNITE-21419
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: RemoveWithCopyListMicroBenchmark.java
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I discovered that updating the collection of listeners in
> *org.apache.ignite.internal.event.AbstractEventProducer* is a little not
> optimal, I’m optimizing it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21419) Optimize listener collection update in AbstractEventProducer
[ https://issues.apache.org/jira/browse/IGNITE-21419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-21419: - Attachment: RemoveWithCopyListMicroBenchmark.java > Optimize listener collection update in AbstractEventProducer > > > Key: IGNITE-21419 > URL: https://issues.apache.org/jira/browse/IGNITE-21419 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Attachments: RemoveWithCopyListMicroBenchmark.java > > Time Spent: 1h 10m > Remaining Estimate: 0h > > I discovered that updating the collection of listeners in > *org.apache.ignite.internal.event.AbstractEventProducer* is a little not > optimal, I’m optimizing it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21112) Mechanism to wait for completion of transactions started on schema versions preceding a target schema version
[
https://issues.apache.org/jira/browse/IGNITE-21112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko resolved IGNITE-21112.
--
Resolution: Fixed
Implemented in IGNITE-21155.
> Mechanism to wait for completion of transactions started on schema versions
> preceding a target schema version
> -
>
> Key: IGNITE-21112
> URL: https://issues.apache.org/jira/browse/IGNITE-21112
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> A. Each node should handle the following message:
> RwTransactionsFinishedRequest; it will have targetSchemaVersion field of type
> int (which represents a Catalog version). The response will be
> RwTransactionsFinishedResponse containing the only field: finished (of type
> boolean).
> B. When the node gets such a request, it should (1) first check whether the
> target version has activated (not just appeared in the local Catalog) on the
> node. If not, (2) it should return false. If it has already been activated on
> the node, then the node should atomically query its TxManager whether it has
> any non-finished RW transactions that started on schema versions preceding
> the target version (this is determined by the beginTs of the transaction).
> C. To avoid a race between starting an RW transaction and checking for
> non-finished transactions, we need to start RW transactions in the following
> way:
> # beginTs = HLC.now()
> # {*}Without doing a schema sync{*}, find the Catalog version active at
> beginTs, assign it to TxCatalogVersion
> # Atomically wrt checking for transactions existence on schemas before X
> (see B.2), wrt finishing RW transactions and wrt raising the 'latest
> activated Catalog version' (used in B.1), add the new transaction with
> beginTs to the map of the currently active transactions (only if the 'latest
> activated Catalog version' is not higher than TxCatalogVersion)
> # If on item 3 it turned out that TxCatalogVersion is already lower than the
> 'latest activated Catalog version', goto step 1
> Note that, as on step 2 we don't do schema sync, resolving the catalog
> version corresponding to the beginTs might yield different results, so we
> might increment one counter and decrement another counter for the same
> transaction. To avoid this, we could resolve the 'catalog version for
> counter' just once (when incrementing) and store it (for instance, in
> TxStateMeta).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21112) Mechanism to wait for completion of transactions started on schema versions preceding a target schema version
[
https://issues.apache.org/jira/browse/IGNITE-21112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-21112:
-
Fix Version/s: 3.0.0-beta2
> Mechanism to wait for completion of transactions started on schema versions
> preceding a target schema version
> -
>
> Key: IGNITE-21112
> URL: https://issues.apache.org/jira/browse/IGNITE-21112
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> A. Each node should handle the following message:
> RwTransactionsFinishedRequest; it will have targetSchemaVersion field of type
> int (which represents a Catalog version). The response will be
> RwTransactionsFinishedResponse containing the only field: finished (of type
> boolean).
> B. When the node gets such a request, it should (1) first check whether the
> target version has activated (not just appeared in the local Catalog) on the
> node. If not, (2) it should return false. If it has already been activated on
> the node, then the node should atomically query its TxManager whether it has
> any non-finished RW transactions that started on schema versions preceding
> the target version (this is determined by the beginTs of the transaction).
> C. To avoid a race between starting an RW transaction and checking for
> non-finished transactions, we need to start RW transactions in the following
> way:
> # beginTs = HLC.now()
> # {*}Without doing a schema sync{*}, find the Catalog version active at
> beginTs, assign it to TxCatalogVersion
> # Atomically wrt checking for transactions existence on schemas before X
> (see B.2), wrt finishing RW transactions and wrt raising the 'latest
> activated Catalog version' (used in B.1), add the new transaction with
> beginTs to the map of the currently active transactions (only if the 'latest
> activated Catalog version' is not higher than TxCatalogVersion)
> # If on item 3 it turned out that TxCatalogVersion is already lower than the
> 'latest activated Catalog version', goto step 1
> Note that, as on step 2 we don't do schema sync, resolving the catalog
> version corresponding to the beginTs might yield different results, so we
> might increment one counter and decrement another counter for the same
> transaction. To avoid this, we could resolve the 'catalog version for
> counter' just once (when incrementing) and store it (for instance, in
> TxStateMeta).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21424) ItScaleCubeNetworkMessagingTest.reconnectsAfterConnectionDrop causes an NPE to be logged
Roman Puchkovskiy created IGNITE-21424: -- Summary: ItScaleCubeNetworkMessagingTest.reconnectsAfterConnectionDrop causes an NPE to be logged Key: IGNITE-21424 URL: https://issues.apache.org/jira/browse/IGNITE-21424 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 [2024-02-01T17:15:59,855][ERROR][%iscnmt_racd_3345%MessagingService-inbound-0-0][DefaultMessagingService] onMessage() failed while processing TestMessageImpl [map=null, msg=trailblazer] from iscnmt_racd_3344 java.lang.NullPointerException: null at java.util.Objects.requireNonNull(Objects.java:221) ~[?:?] at org.apache.ignite.network.scalecube.ItScaleCubeNetworkMessagingTest.lambda$reconnectsAfterConnectionDrop$16(ItScaleCubeNetworkMessagingTest.java:597) ~[integrationTest/:?] at org.apache.ignite.network.TrackableNetworkMessageHandler.onReceived(TrackableNetworkMessageHandler.java:48) ~[ignite-network-api-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.network.DefaultMessagingService.handleIncomingMessage(DefaultMessagingService.java:405) ~[ignite-network-3.0.0-SNAPSHOT.jar:?] at org.apache.ignite.network.DefaultMessagingService.lambda$onMessage$4(DefaultMessagingService.java:356) ~[ignite-network-3.0.0-SNAPSHOT.jar:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?] at java.lang.Thread.run(Thread.java:834) [?:?] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21366) AssertionError during the execution of the request
[
https://issues.apache.org/jira/browse/IGNITE-21366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813493#comment-17813493
]
Ignite TC Bot commented on IGNITE-21366:
{panel:title=Branch: [pull/11214/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11214/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=7726050buildTypeId=IgniteTests24Java8_RunAll]
> AssertionError during the execution of the request
> ---
>
> Key: IGNITE-21366
> URL: https://issues.apache.org/jira/browse/IGNITE-21366
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Nikolaev
>Assignee: Aleksandr Nikolaev
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If GridH2Table#cache size is greater than int, then we get an AssertionError:
> {code}
> -26T19:32:35,247][ERROR][main][] Test failed
> [test=RowCountTableStatisticsUsageTest#compareJoinsWithConditionsOnBothTables[cacheMode=REPLICATED],
> duration=10]
> java.lang.AssertionError: totalRowCnt=-4294967096, localRowCount=-2147483548
> at
> org.apache.ignite.internal.processors.query.h2.opt.TableStatistics.(TableStatistics.java:34)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.refreshStatsIfNeeded(GridH2Table.java:1055)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.getRowCountApproximation(GridH2Table.java:1013)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.getRowCountApproximation(GridH2IndexBase.java:226)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2ScanIndex.getRowCountApproximation(H2ScanIndex.java:158)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2ScanIndex.getCost(H2ScanIndex.java:289)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2TableScanIndex.getCost(H2TableScanIndex.java:74)
> ~[classes/:?]
> at org.h2.table.Table.getBestPlanItem(Table.java:714)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.table.TableFilter.getBestPlanItem(TableFilter.java:224)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.table.Plan.calculateCost(Plan.java:121)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.testPlan(Optimizer.java:180)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.calculateBestPlan(Optimizer.java:81)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.optimize(Optimizer.java:239)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Select.preparePlan(Select.java:1018)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Select.prepare(Select.java:884)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Explain.prepare(Explain.java:49)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.Parser.prepareCommand(Parser.java:283)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.Session.prepareLocal(Session.java:611)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.Session.prepareCommand(Session.java:549)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
> ~[h2-1.4.197.jar:1.4.197]
> at
> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
> ~[h2-1.4.197.jar:1.4.197]
> at
> org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:191)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.H2PooledConnection.prepareStatementNoCache(H2PooledConnection.java:109)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:341)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:225)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:138)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1011)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3115)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3086)
> ~[classes/:?]
> at
>
[jira] [Commented] (IGNITE-21342) Update guava and grpc in OpenCensus dependency
[ https://issues.apache.org/jira/browse/IGNITE-21342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813486#comment-17813486 ] Aleksandr Nikolaev commented on IGNITE-21342: - [~PetrovMikhail] thnx for review > Update guava and grpc in OpenCensus dependency > -- > > Key: IGNITE-21342 > URL: https://issues.apache.org/jira/browse/IGNITE-21342 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21394) TimeoutException in the listener of pending assignments change shouldn't fail the watch processor
[
https://issues.apache.org/jira/browse/IGNITE-21394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813398#comment-17813398
]
Vladislav Pyatkov commented on IGNITE-21394:
Merged d1cb712f0667f80d9896ca15f39939ba00afdaca
> TimeoutException in the listener of pending assignments change shouldn't fail
> the watch processor
> -
>
> Key: IGNITE-21394
> URL: https://issues.apache.org/jira/browse/IGNITE-21394
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> *Motivation*
> The handler of pending assignments event change (
> TableManager#handleChangePendingAssignmentEvent() ) tries to do
> changePeerAsync after starting the partition and client. In order to know
> whether the calling of changePeerAsync is needed, it tries to get the current
> leader of corresponding raft group. This call of
> RaftGroupService#refreshAndGetLeaderWithTerm can fail with TimeoutException.
> For example, there is no known leader on the node that the GetLeader request
> is sent to, or that node is no more in the raft group, etc., and in the same
> time that node is the only known peer of the raft group: in these cases the
> GetLeader request will be constantly retried in hope to get a response with
> leader finally, when it's elected, but this can never happen. So, the
> TimeoutException is expected in this case.
> This exception should be handled within the mentioned listener of pending
> assignments event change. otherwise it fails the watch processor, making it
> unable to handle the further meta storage updates (and making the node
> inoperable). This means that, most likely, the current node is not a leader
> of the raft group, and changePeers shouln't be done, or it has not caught up
> with the current assignments events, this means that some requests for this
> node for this partition will fail, but the node will remain operable.
> *Definition of done*
> TimeoutException in the listener of pending assignments change doesn't fail
> the watch processor and doesn't lead to multiple exceptions like this:
> {code:java}
> [2024-01-29T22:00:58,658][ERROR][%isckvt_tmccd_3344%Raft-Group-Client-5][WatchProcessor]
> Error occurred when notifying safe time advanced callback
> java.util.concurrent.CompletionException:
> java.util.concurrent.TimeoutException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> ~[?:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:546)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.lambda$handleErrorResponse$42(RaftGroupServiceImpl.java:635)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.util.concurrent.TimeoutException
> ... 8 more{code}
>
> *Implementation notes*
> It can be reproduced in integration tests like
> ItSchemaChangeKvViewTest#testMergeChangesColumnDefault when there are 3 nodes
> starting, then a table with 25 partitions/1 replica created. During the table
> start the rebalance is possible, like this:
> * a replication group is moved from node A to node B
> * some node C tries to perform GetLeader, and has only node A in local peers
> * node A thinks it is the only member of the replication group, and is not
> leader, sends "Unknown leader" response to C
> * node C constatnly retries the request to node A.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21423) Improve toString() implementations for classes representing Catalog objects
Roman Puchkovskiy created IGNITE-21423: -- Summary: Improve toString() implementations for classes representing Catalog objects Key: IGNITE-21423 URL: https://issues.apache.org/jira/browse/IGNITE-21423 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 All classes that extend CatalogObjectDescriptor define toString() that miss a lot of important information. We always need it to output id and name of the object; also the important properties useful when debugging should be included in toString() (probably, everything that is not too long). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21423) Improve toString() implementations for classes representing Catalog objects
[ https://issues.apache.org/jira/browse/IGNITE-21423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-21423: -- Assignee: Roman Puchkovskiy > Improve toString() implementations for classes representing Catalog objects > --- > > Key: IGNITE-21423 > URL: https://issues.apache.org/jira/browse/IGNITE-21423 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > All classes that extend CatalogObjectDescriptor define toString() that miss a > lot of important information. We always need it to output id and name of the > object; also the important properties useful when debugging should be > included in toString() (probably, everything that is not too long). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21132) Buffered disk writing when creating dump
[ https://issues.apache.org/jira/browse/IGNITE-21132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-21132: Ignite Flags: (was: Docs Required,Release Notes Required) > Buffered disk writing when creating dump > > > Key: IGNITE-21132 > URL: https://issues.apache.org/jira/browse/IGNITE-21132 > Project: Ignite > Issue Type: Task >Reporter: Yuri Naryshkin >Assignee: Yuri Naryshkin >Priority: Major > Labels: IEP-109, ise > Fix For: 2.17 > > Time Spent: 5h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21132) Buffered disk writing when creating dump
[ https://issues.apache.org/jira/browse/IGNITE-21132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin resolved IGNITE-21132. - Reviewer: Maksim Timonin Resolution: Fixed > Buffered disk writing when creating dump > > > Key: IGNITE-21132 > URL: https://issues.apache.org/jira/browse/IGNITE-21132 > Project: Ignite > Issue Type: Task >Reporter: Yuri Naryshkin >Assignee: Yuri Naryshkin >Priority: Major > Labels: IEP-109, ise > Time Spent: 5h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21132) Buffered disk writing when creating dump
[ https://issues.apache.org/jira/browse/IGNITE-21132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-21132: Fix Version/s: 2.17 > Buffered disk writing when creating dump > > > Key: IGNITE-21132 > URL: https://issues.apache.org/jira/browse/IGNITE-21132 > Project: Ignite > Issue Type: Task >Reporter: Yuri Naryshkin >Assignee: Yuri Naryshkin >Priority: Major > Labels: IEP-109, ise > Fix For: 2.17 > > Time Spent: 5h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21422) Cancelling queued job should cancel result
Vadim Pakhnushev created IGNITE-21422:
-
Summary: Cancelling queued job should cancel result
Key: IGNITE-21422
URL: https://issues.apache.org/jira/browse/IGNITE-21422
Project: Ignite
Issue Type: Bug
Components: compute
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
{{JobExecution.resultAsync}} should complete exceptionally with the
{{CancellationException}} when the job is in the queue and is cancelled.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21236) Handle DataStreamer entry version in dump
[ https://issues.apache.org/jira/browse/IGNITE-21236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-21236: - Assignee: Vladimir Steshin > Handle DataStreamer entry version in dump > - > > Key: IGNITE-21236 > URL: https://issues.apache.org/jira/browse/IGNITE-21236 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Assignee: Vladimir Steshin >Priority: Major > Labels: IEP-109, ise > > DataStreamer writes entries with fixed GridCacheVersion, that is greater than > any existing version. > During dump creation it filters all such entries by version, and no entries > created by data streamer lands into the dump. > Possible solution is to apply all entries with this DataStreamer version to > dump. Other hand, it might make the dump inconsistent when it's created > parallel to DataStreamer activity (we have the warn for this case in > Snapshots already) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20894) Add tests for ensuring transactional guarantees
[ https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-20894: - Reviewer: Alexander Lapin (was: Vladislav Pyatkov) > Add tests for ensuring transactional guarantees > --- > > Key: IGNITE-20894 > URL: https://issues.apache.org/jira/browse/IGNITE-20894 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > h3. Motivation > The first purpose of the transaction flow tests is to preserve consistency in > storage. The reason for this might be partial commits due to executing > commits and rollbacks on one transaction. The second is avoiding redundant or > permanent locks that can originate from an asynchronous operation happening > in parallel with commit/rollback. > h3. Definition of done > Here is a list of tests that should be present: > # Multiple commits of the transaction from different threads. There should > be also some multithreaded enlists (via get/put operations) which should fail > if the finishing process of the transaction has already started (transition > to FINISHING state is done). After the completion of all asynchronous > operations there should be no locks left on server side (we should check that > the failed enlisting operations haven't left any locks as well). > # Same as 1, but there should be concurrent rollbacks instead of commits. > # Same as 1, but there should be random finish operations for transaction, > there can be commits after rollback and rollbacks after commit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20894) Add tests for ensuring transactional guarantees
[ https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813313#comment-17813313 ] Alexander Lapin commented on IGNITE-20894: -- [~Denis Chudov] Generally LGTM, few minors. > Add tests for ensuring transactional guarantees > --- > > Key: IGNITE-20894 > URL: https://issues.apache.org/jira/browse/IGNITE-20894 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > h3. Motivation > The first purpose of the transaction flow tests is to preserve consistency in > storage. The reason for this might be partial commits due to executing > commits and rollbacks on one transaction. The second is avoiding redundant or > permanent locks that can originate from an asynchronous operation happening > in parallel with commit/rollback. > h3. Definition of done > Here is a list of tests that should be present: > # Multiple commits of the transaction from different threads. There should > be also some multithreaded enlists (via get/put operations) which should fail > if the finishing process of the transaction has already started (transition > to FINISHING state is done). After the completion of all asynchronous > operations there should be no locks left on server side (we should check that > the failed enlisting operations haven't left any locks as well). > # Same as 1, but there should be concurrent rollbacks instead of commits. > # Same as 1, but there should be random finish operations for transaction, > there can be commits after rollback and rollbacks after commit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-16094) Mapper and Marshaller caching
[ https://issues.apache.org/jira/browse/IGNITE-16094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-16094: - Assignee: Maksim Zhuravkov > Mapper and Marshaller caching > - > > Key: IGNITE-16094 > URL: https://issues.apache.org/jira/browse/IGNITE-16094 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *Mapper* and *Marshaller* implementations use reflection to retrieve > object fields. We should cache results when possible. > For example: > * *IdentityMapper* instances can be cached by Class > * *Marshaller* instances can be cached by Class + Schema when using > IdentityMapper > See TODOs in code with "IGNITE-16094". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20122) When a REGISTERED/BACKFILLING index is dropped, it should be removed right away
[ https://issues.apache.org/jira/browse/IGNITE-20122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-20122. Resolution: Fixed Implemented in IGNITE-20119 > When a REGISTERED/BACKFILLING index is dropped, it should be removed right > away > --- > > Key: IGNITE-20122 > URL: https://issues.apache.org/jira/browse/IGNITE-20122 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When a DROP INDEX is executed for an index that is STARTING or BACKFILLING, > it should be removed right away (skipping the AVAILABLE and subsequent > states) and start destruction. This should be done using a conditional schema > update (IGNITE-20115) to avoid a race with switching to the > BACKFILING/AVAILABLE state. > If the conditional schema update fails (because the index has been switched > to the BACKFILLING/AVAILABLE state), we should retry at the new state. If > it's BACKFILLING, we should try to destroy the index again; if it's > AVAILABLE, then fallback to the usual procedure (IGNITE-20119). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20131) Consider all index-related schema changes as compatible
[ https://issues.apache.org/jira/browse/IGNITE-20131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-20131. Resolution: Won't Fix This already works like this as index creation does not increment a table version, hence our current schema compatibility validation is simply not triggered by index-related changes. > Consider all index-related schema changes as compatible > --- > > Key: IGNITE-20131 > URL: https://issues.apache.org/jira/browse/IGNITE-20131 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > All allowed index state transfers are compatible: > * Creation (as STARTING) > * STARTING -> READY > * READY -> STOPPING > * STOPPING -> [not-existent] > * STARTING -> [not-existent] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19498) Start building indexes only once
[ https://issues.apache.org/jira/browse/IGNITE-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-19498. Resolution: Invalid As per a call, we don't need this anymore, hence closing the issue. > Start building indexes only once > > > Key: IGNITE-19498 > URL: https://issues.apache.org/jira/browse/IGNITE-19498 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > As part of IGNITE-19177, the building of indexes moves from the > *IndexManager* to the replica, because of this, a race may occur when the > replica becomes the leader, and we need to start listening to the creation of > indexes in the configuration and reading previous indexes from the > configuration. > Therefore, we need to figure out how we can avoid the double start of index > building, maybe this is not a problem and later we will just close the ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20119) Switch index to STOPPING state as a reaction to DROP INDEX
[ https://issues.apache.org/jira/browse/IGNITE-20119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813257#comment-17813257 ] Roman Puchkovskiy commented on IGNITE-20119: Thanks! > Switch index to STOPPING state as a reaction to DROP INDEX > -- > > Key: IGNITE-20119 > URL: https://issues.apache.org/jira/browse/IGNITE-20119 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2.5h > Remaining Estimate: 0h > > DROP INDEX should do the following: > # If the index is AVAILABLE, move it to STOPPING > # If it was not yet available (that is, it's REGISTERED or BUILDING), remove > it from the Catalog > Also, RemoveIndexCommand should be added that will be used to move a STOPPED > index from the Catalog (invocation of the command is out of scope of this > issue). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21236) Handle DataStreamer entry version in dump
[ https://issues.apache.org/jira/browse/IGNITE-21236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-21236: Ignite Flags: (was: Docs Required,Release Notes Required) > Handle DataStreamer entry version in dump > - > > Key: IGNITE-21236 > URL: https://issues.apache.org/jira/browse/IGNITE-21236 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Priority: Major > Labels: IEP-109, ise > > DataStreamer writes entries with fixed GridCacheVersion, that is greater than > any existing version. > During dump creation it filters all such entries by version, and no entries > created by data streamer lands into the dump. > Possible solution is to apply all entries with this DataStreamer version to > dump. Other hand, it might make the dump inconsistent when it's created > parallel to DataStreamer activity (we have the warn for this case in > Snapshots already) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21132) Buffered disk writing when creating dump
[
https://issues.apache.org/jira/browse/IGNITE-21132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813231#comment-17813231
]
Ignite TC Bot commented on IGNITE-21132:
{panel:title=Branch: [pull/8/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Snapshots 3{color} [[tests
6|https://ci2.ignite.apache.org/viewLog.html?buildId=7723631]]
* {color:#013220}IgniteSnapshotTestSuite3: BufferedFileIOTest.testLargeEntry -
PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite3:
BufferedFileIOTest.testBufferSizeEntry - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite3: BufferedFileIOTest.testDoubleClose -
PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite3:
BufferedFileIOTest.testAFewSmallEntries - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite3: BufferedFileIOTest.testWrongArg -
PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite3: BufferedFileIOTest.testOneSmallEntry
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7723632buildTypeId=IgniteTests24Java8_RunAll]
> Buffered disk writing when creating dump
>
>
> Key: IGNITE-21132
> URL: https://issues.apache.org/jira/browse/IGNITE-21132
> Project: Ignite
> Issue Type: Task
>Reporter: Yuri Naryshkin
>Assignee: Yuri Naryshkin
>Priority: Major
> Labels: IEP-109, ise
> Time Spent: 5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21421) Calcite engine. Tuple (row) comparison is not working
Aleksey Plekhanov created IGNITE-21421:
--
Summary: Calcite engine. Tuple (row) comparison is not working
Key: IGNITE-21421
URL: https://issues.apache.org/jira/browse/IGNITE-21421
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Currentrly, row comparison fails with an error and don't use index.
Reproducer:
{code:java}
sql("CREATE TABLE test (id INTEGER, val INTEGER)");
sql("CREATE INDEX test_idx ON test (id, val)");
sql("INSERT INTO test VALUES (0, 0), (0, 1), (1, 0), (1, 1)");
assertQuery("SELECT * FROM test WHERE (id, val) >= (?, ?)")
.withParams(0, 1)
//.matches(QueryChecker.containsIndexScan("PUBLIC", "TEST", "TEST_IDX"))
.returns(0, 1)
.returns(1, 0)
.returns(1, 1)
.check(); {code}
Exception:
{noformat}
Caused by: java.lang.RuntimeException: while resolving method 'ge[class
[Ljava.lang.Object;, class [Ljava.lang.Object;]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:318)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:449)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable$BinaryImplementor.implementSafe(RexImpTable.java:1233)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:1950)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:1911)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20990) Switch to storage-profile based configs in storage engine
[
https://issues.apache.org/jira/browse/IGNITE-20990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov updated IGNITE-20990:
Description:
*Motivation:*
At the moment storage profiles defined for the tables and zones accordingly,
but the storage engine layer still use the region-based configurations. We need
to switch storage engine configuration to profiles too.
*Definition of done:*
* The storage profiles configuration must initiate appropriate storage
profiles in the each storage engine
*Implementation notes:*
- Change the *StorageEngineConfigurationSchema to implement the
StorageEngineConfigurationSchema (it the parent of storage profiles
configuration)
- Make *DataStorageModule use the new non-root
*StorageEngineConfigurationSchema, which is the part of StoragesConfiguration
- Due to the fact, that there is no default storage profile at all, we need to
remove the default region abstraction and change all builtin configs to the
appropariate value, which support default region of table creation DDL
Note: at the moment it can be difficult to remove all stuff connected with data
regions in zones and tables, so, the separate issue for final code cleanup
created IGNITE-21385
was:
*Motivation:*
At the moment storage profiles defined for the tables and zones accordingly,
but the storage engine layer still use the region-based configurations. We need
to switch storage engine configuration to profiles too.
{*}Definition of done:{*}{*}{*}
* The storage profiles configuration must initiate appropriate storage
profiles in the each storage engine
*Implementation notes:*
- Change the *StorageEngineConfigurationSchema to implement the
StorageEngineConfigurationSchema (it the parent of storage profiles
configuration)
- Make *DataStorageModule use the new non-root
*StorageEngineConfigurationSchema, which is the part of StoragesConfiguration
- Due to the fact, that there is no default storage profile at all, we need to
remove the default region abstraction and change all builtin configs to the
appropariate value, which support default region of table creation DDL
Note: at the moment it can be difficult to remove all stuff connected with data
regions in zones and tables, so, the separate issue for final code cleanup
created IGNITE-21385
> Switch to storage-profile based configs in storage engine
> -
>
> Key: IGNITE-20990
> URL: https://issues.apache.org/jira/browse/IGNITE-20990
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Assignee: Kirill Gusakov
>Priority: Major
> Labels: ignite-3
>
> *Motivation:*
> At the moment storage profiles defined for the tables and zones accordingly,
> but the storage engine layer still use the region-based configurations. We
> need to switch storage engine configuration to profiles too.
> *Definition of done:*
> * The storage profiles configuration must initiate appropriate storage
> profiles in the each storage engine
> *Implementation notes:*
> - Change the *StorageEngineConfigurationSchema to implement the
> StorageEngineConfigurationSchema (it the parent of storage profiles
> configuration)
> - Make *DataStorageModule use the new non-root
> *StorageEngineConfigurationSchema, which is the part of StoragesConfiguration
> - Due to the fact, that there is no default storage profile at all, we need
> to remove the default region abstraction and change all builtin configs to
> the appropariate value, which support default region of table creation DDL
> Note: at the moment it can be difficult to remove all stuff connected with
> data regions in zones and tables, so, the separate issue for final code
> cleanup created IGNITE-21385
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20990) Switch to storage-profile based configs in storage engine
[
https://issues.apache.org/jira/browse/IGNITE-20990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov updated IGNITE-20990:
Description:
*Motivation:*
At the moment storage profiles defined for the tables and zones accordingly,
but the storage engine layer still use the region-based configurations. We need
to switch storage engine configuration to profiles too.
{*}Definition of done:{*}{*}{*}
* The storage profiles configuration must initiate appropriate storage
profiles in the each storage engine
*Implementation notes:*
- Change the *StorageEngineConfigurationSchema to implement the
StorageEngineConfigurationSchema (it the parent of storage profiles
configuration)
- Make *DataStorageModule use the new non-root
*StorageEngineConfigurationSchema, which is the part of StoragesConfiguration
- Due to the fact, that there is no default storage profile at all, we need to
remove the default region abstraction and change all builtin configs to the
appropariate value, which support default region of table creation DDL
Note: at the moment it can be difficult to remove all stuff connected with data
regions in zones and tables, so, the separate issue for final code cleanup
created IGNITE-21385
was:
- Change the *StorageEngineConfigurationSchema to implement the
StorageEngineConfigurationSchema
- Make *DataStorageModule use the new non-root
*StorageEngineConfigurationSchema, which is the part of StoragesConfiguration
- Implement the appropariate mechanism to handle default config values if there
is no StoragesConfiguration engine entity of the needed type (aipersist, aimem
and etc.), because at the moment defaults loading from the root engine
configuration, but this approach will not work anymore.
- Due to the fact, that there is no default storage profile at all, we need to
remove the default region abstraction and change all builtin configs to the
appropariate value, which support default region of table creation DDL
> Switch to storage-profile based configs in storage engine
> -
>
> Key: IGNITE-20990
> URL: https://issues.apache.org/jira/browse/IGNITE-20990
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Assignee: Kirill Gusakov
>Priority: Major
> Labels: ignite-3
>
> *Motivation:*
> At the moment storage profiles defined for the tables and zones accordingly,
> but the storage engine layer still use the region-based configurations. We
> need to switch storage engine configuration to profiles too.
> {*}Definition of done:{*}{*}{*}
> * The storage profiles configuration must initiate appropriate storage
> profiles in the each storage engine
> *Implementation notes:*
> - Change the *StorageEngineConfigurationSchema to implement the
> StorageEngineConfigurationSchema (it the parent of storage profiles
> configuration)
> - Make *DataStorageModule use the new non-root
> *StorageEngineConfigurationSchema, which is the part of StoragesConfiguration
> - Due to the fact, that there is no default storage profile at all, we need
> to remove the default region abstraction and change all builtin configs to
> the appropariate value, which support default region of table creation DDL
> Note: at the moment it can be difficult to remove all stuff connected with
> data regions in zones and tables, so, the separate issue for final code
> cleanup created IGNITE-21385
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21420) Refactor ComputeController
Vadim Pakhnushev created IGNITE-21420:
-
Summary: Refactor ComputeController
Key: IGNITE-21420
URL: https://issues.apache.org/jira/browse/IGNITE-21420
Project: Ignite
Issue Type: Improvement
Components: rest
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
In order to keep consistency between thin client and rest, the controller
should use {{IgniteComputeInternal}} rather than {{ComputeComponent}} directly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21419) Optimize listener collection update in AbstractEventProducer
[ https://issues.apache.org/jira/browse/IGNITE-21419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-21419: - Fix Version/s: 3.0.0-beta2 > Optimize listener collection update in AbstractEventProducer > > > Key: IGNITE-21419 > URL: https://issues.apache.org/jira/browse/IGNITE-21419 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > I discovered that updating the collection of listeners in > *org.apache.ignite.internal.event.AbstractEventProducer* is a little not > optimal, I’m optimizing it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21419) Optimize listener collection update in AbstractEventProducer
[ https://issues.apache.org/jira/browse/IGNITE-21419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-21419: Assignee: Kirill Tkalenko > Optimize listener collection update in AbstractEventProducer > > > Key: IGNITE-21419 > URL: https://issues.apache.org/jira/browse/IGNITE-21419 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > I discovered that updating the collection of listeners in > *org.apache.ignite.internal.event.AbstractEventProducer* is a little not > optimal, I’m optimizing it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21419) Optimize listener collection update in AbstractEventProducer
Kirill Tkalenko created IGNITE-21419: Summary: Optimize listener collection update in AbstractEventProducer Key: IGNITE-21419 URL: https://issues.apache.org/jira/browse/IGNITE-21419 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko I discovered that updating the collection of listeners in *org.apache.ignite.internal.event.AbstractEventProducer* is a little not optimal, I’m optimizing it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21417) .NET: TestReconnectToOldNodeDisablesPartitionAwareness fails on JDK 11
[ https://issues.apache.org/jira/browse/IGNITE-21417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813178#comment-17813178 ] Pavel Tupitsyn commented on IGNITE-21417: - Merged to master: c1fad6dff172af874edb2757544f9de08e88428d > .NET: TestReconnectToOldNodeDisablesPartitionAwareness fails on JDK 11 > -- > > Key: IGNITE-21417 > URL: https://issues.apache.org/jira/browse/IGNITE-21417 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.16 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Ignite 2.4.0 and 2.6.0 can't start on some JDK 11 versions. Skip the test > with a condition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21417) .NET: TestReconnectToOldNodeDisablesPartitionAwareness fails on JDK 11
[
https://issues.apache.org/jira/browse/IGNITE-21417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813168#comment-17813168
]
Ignite TC Bot commented on IGNITE-21417:
{panel:title=Branch: [pull/11212/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=7817498]]
* DotNetCore: IgniteExceptionTaskSelfTest.TestRemoteResultError - Test has low
fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/11212/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *- Run :: .NET*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=7817500buildTypeId=IgniteTests24Java8_RunAllNet]
> .NET: TestReconnectToOldNodeDisablesPartitionAwareness fails on JDK 11
> --
>
> Key: IGNITE-21417
> URL: https://issues.apache.org/jira/browse/IGNITE-21417
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.16
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite 2.4.0 and 2.6.0 can't start on some JDK 11 versions. Skip the test
> with a condition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-15226) Print original exception when SSLException occurs
[
https://issues.apache.org/jira/browse/IGNITE-15226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-15226:
-
Assignee: (was: Denis Chudov)
> Print original exception when SSLException occurs
> -
>
> Key: IGNITE-15226
> URL: https://issues.apache.org/jira/browse/IGNITE-15226
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
>
> We have to print original message when SSLException occurs.
> {noformat}
> 2021-02-23 03:23:35.579 [2021-02-23 03:23:35,579][WARN
> ][grid-nio-worker-client-listener-0-#150][ClientListenerProcessor] Closing
> NIO session because of unhandled exception [cls=class
> o.a.i.i.util.nio.GridNioException, msg=Failed to decode SSL data:
> GridSelectorNioSessionImpl [worker=GridWorker
> [name=grid-nio-worker-client-listener-0, igniteInstanceName=null,
> finished=false, heartbeatTs=1614039815570, hashCode=1938562251,
> interrupted=false,
> runner=grid-nio-worker-client-listener-0-#150]AbstractNioClientWorker [idx=0,
> bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true,
> super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=517
> lim=517 cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
> outRecovery=null, super=GridNioSessionImpl [locAddr=IP, rmtAddr=IP,
> createTime=1614039815116, closeTime=0, bytesSent=7268, bytesRcvd=7785,
> bytesSent0=7268, bytesRcvd0=7785, sndSchedTime=1614039815560,
> lastSndTime=1614039815570, lastRcvTime=1614039815570, readsPaused=false,
> filterChain=GridNioCodecFilter [parser=ClientListenerBufferedParser,
> directMode=false]FilterChain[filters=[GridNioAsyncNotifyFilter, , SSL
> filter], accepted=true, markedForClose=false]]]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21418) ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-21418:
-
Description:
{code:java}
java.lang.NullPointerException at
org.apache.ignite.internal.table.TxAbstractTest.testDeleteUpsertAllRollback(TxAbstractTest.java:233)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
{code}
[https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7814256?expandCode+Inspection=true=true=false=true=false=true]
Flaky rate is low.
> ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is
> flaky
> ---
>
> Key: IGNITE-21418
> URL: https://issues.apache.org/jira/browse/IGNITE-21418
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> java.lang.NullPointerException at
> org.apache.ignite.internal.table.TxAbstractTest.testDeleteUpsertAllRollback(TxAbstractTest.java:233)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> {code}
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7814256?expandCode+Inspection=true=true=false=true=false=true]
> Flaky rate is low.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21418) ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is flaky
[ https://issues.apache.org/jira/browse/IGNITE-21418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21418: - Ignite Flags: (was: Docs Required,Release Notes Required) > ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is > flaky > --- > > Key: IGNITE-21418 > URL: https://issues.apache.org/jira/browse/IGNITE-21418 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21418) ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is flaky
[ https://issues.apache.org/jira/browse/IGNITE-21418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21418: - Labels: ignite-3 (was: ) > ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is > flaky > --- > > Key: IGNITE-21418 > URL: https://issues.apache.org/jira/browse/IGNITE-21418 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21418) ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is flaky
Alexander Lapin created IGNITE-21418: Summary: ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is flaky Key: IGNITE-21418 URL: https://issues.apache.org/jira/browse/IGNITE-21418 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21418) ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is flaky
[ https://issues.apache.org/jira/browse/IGNITE-21418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21418: - Epic Link: IGNITE-21389 > ItTxDistributedTestThreeNodesThreeReplicas#testDeleteUpsertAllRollback is > flaky > --- > > Key: IGNITE-21418 > URL: https://issues.apache.org/jira/browse/IGNITE-21418 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21290) Scan cursors do not close after being fully read in transactions
[ https://issues.apache.org/jira/browse/IGNITE-21290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813149#comment-17813149 ] Alexander Lapin commented on IGNITE-21290: -- [~v.pyatkov] LGTM. > Scan cursors do not close after being fully read in transactions > > > Key: IGNITE-21290 > URL: https://issues.apache.org/jira/browse/IGNITE-21290 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 1h 40m > Remaining Estimate: 0h > > h3. Motivation > Open cursors require extra memory on the server side, so they should be > closed as soon as they are no longer used. It is easy to understand on the > coursor owner server when the coursor returns false for the hasNext > invocation. > Despite the fact that all acquired transaction resources should be released > after the transaction finalizes, it would be better to close usles coursorse > faseter. Moreover, the agreement is fit for all types of transactions: RO, > RW, and inplicit. > h3. Implementation notes > When the replica returns a batch, their size can be estimated, and the cursor > can be closed if the size is less than requested. > h3. Definition of done > A cursor is closed on the server side when the client retrieves all data from > it through any type of scan operation. > Moreover, the server-side cursors should be closed in case the cursor > supplier is closing through the API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20120) Remove index from Catalog when it's READ_ONLY and activation of its STOPPING state is below GC LWM
[ https://issues.apache.org/jira/browse/IGNITE-20120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-20120. Resolution: Invalid In IGNITE-20119, the index will be removed from the index as soon as it ceases to exist in the STOPPING state. > Remove index from Catalog when it's READ_ONLY and activation of its STOPPING > state is below GC LWM > -- > > Key: IGNITE-20120 > URL: https://issues.apache.org/jira/browse/IGNITE-20120 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When an index is READ_ONLY and activation moment of the STOPPING state of the > index is below GC LWM (meaning that no new transaction can read from this > index), the index should be removed from the Catalog. A conditional schema > update (IGNITE-20115) might be used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20858) Compute error handling
[ https://issues.apache.org/jira/browse/IGNITE-20858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-20858: -- Assignee: Vadim Pakhnushev (was: Ivan Gagarkin) > Compute error handling > -- > > Key: IGNITE-20858 > URL: https://issues.apache.org/jira/browse/IGNITE-20858 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Igor Sapego >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Make sure that compute follows AI3 Error Handling rules, defined in > IGNITE-14611. More specifically: > - We should never throw to user anything that is not IgniteException, > IgniteCheckedException or a public class derived from one of them; > - Make sure exceptions thrown by a user code are wrapped by IgniteException > and have a meaningful message. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21414) Use the same event loop for channels of the same logical connection
[ https://issues.apache.org/jira/browse/IGNITE-21414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813120#comment-17813120 ] Roman Puchkovskiy commented on IGNITE-21414: Thanks! > Use the same event loop for channels of the same logical connection > --- > > Key: IGNITE-21414 > URL: https://issues.apache.org/jira/browse/IGNITE-21414 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > The code in HandshakeManagerUtils switches a channel to an event loop bound > to the logical connection. The problem is that there are 2 event loop groups > (server and client ones), and we always choose an event loop from the same > group which created the channel; so we can actually chose one of 2 event > loops, not just 1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21416) Add documentation for FORCE_INDEX/NO_INDEX hints
[
https://issues.apache.org/jira/browse/IGNITE-21416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov updated IGNITE-21416:
Description:
Globally it works the same way as in
[https://ignite.apache.org/docs/latest/SQL/sql-calcite#force_index-no_index],
but has some difference when FORCE_INDEX and NO_INDEX used together in the same
query.
When both hints reference to the same index - it is invalid case. SQL is
declarative language and we shouldn't expect {{hints}} collection is ordered:
{code:java}
SELECT /*+ FORCE_INDEX(IDX_ID), NO_INDEX */ * FROM TBL1 WHERE id = ? AND val = ?
OR
SELECT /*+ NO_INDEX(IDX_VAL), FORCE_INDEX(IDX_VAL) */ * FROM TBL1 WHERE val =
?{code}
*What to do*
We need to fix example section and rewrite "Hint Scope" section.
was:
Globally it works the same way as in
[https://ignite.apache.org/docs/latest/SQL/sql-calcite#force_index-no_index],
but has some difference when FORCE_INDEX and NO_INDEX used together in the same
query.
When both hints reference to the same index - it is invalid case. SQL is
declarative language and we shouldn't expect {{hints}} collection is
ordered:}}{}}}
{code:java}
SELECT /*+ FORCE_INDEX(IDX_ID), NO_INDEX */ * FROM TBL1 WHERE id = ? AND val = ?
OR
SELECT /*+ NO_INDEX(IDX_VAL), FORCE_INDEX(IDX_VAL) */ * FROM TBL1 WHERE val =
?{code}
*What to do*
We need to fix example section and rewrite "Hint Scope" section.
> Add documentation for FORCE_INDEX/NO_INDEX hints
>
>
> Key: IGNITE-21416
> URL: https://issues.apache.org/jira/browse/IGNITE-21416
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, sql
>Reporter: Andrey Novikov
>Priority: Minor
> Labels: ignite-3
>
> Globally it works the same way as in
> [https://ignite.apache.org/docs/latest/SQL/sql-calcite#force_index-no_index],
> but has some difference when FORCE_INDEX and NO_INDEX used together in the
> same query.
> When both hints reference to the same index - it is invalid case. SQL is
> declarative language and we shouldn't expect {{hints}} collection is ordered:
> {code:java}
> SELECT /*+ FORCE_INDEX(IDX_ID), NO_INDEX */ * FROM TBL1 WHERE id = ? AND val
> = ?
> OR
> SELECT /*+ NO_INDEX(IDX_VAL), FORCE_INDEX(IDX_VAL) */ * FROM TBL1 WHERE val =
> ?{code}
>
> *What to do*
> We need to fix example section and rewrite "Hint Scope" section.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21416) Add documentation for FORCE_INDEX/NO_INDEX hints
[
https://issues.apache.org/jira/browse/IGNITE-21416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov updated IGNITE-21416:
Description:
Globally it works the same way as in
[https://ignite.apache.org/docs/latest/SQL/sql-calcite#force_index-no_index],
but has some difference when FORCE_INDEX and NO_INDEX used together in the same
query.
When both hints reference to the same index - it is invalid case. SQL is
declarative language and we shouldn't expect {{hints}} collection is
ordered:{{{}{}}}
{code:java}
{code}
{{SELECT /*+ FORCE_INDEX(IDX_ID), NO_INDEX */ * FROM TBL1 WHERE id = ? AND val
= ?}}
{{OR}}
{{SELECT /*+ NO_INDEX(IDX_VAL), FORCE_INDEX(IDX_VAL) */ * FROM TBL1 WHERE val =
?}}
*What to do*
We need to fix example section and rewrite "Hint Scope" section.
was:
Globally it works the same way as in
[https://ignite.apache.org/docs/latest/SQL/sql-calcite#force_index-no_index],
but has some difference when FORCE_INDEX and NO_INDEX used together in the same
query. When both hints reference to the same index {{SELECT /*+
FORCE_INDEX('idx'), NOINDEX *{*}/,{*} SELECT /*+ NO_INDEX(TBL1_IDX2),
FORCE_INDEX(TBL2_IDX2) */, ...}} - it is invalid case. SQL is declarative
language and we shouldn't expect {{hints}} collection is ordered.
We need to fix example section and rewrite "Hint Scope" section.
> Add documentation for FORCE_INDEX/NO_INDEX hints
>
>
> Key: IGNITE-21416
> URL: https://issues.apache.org/jira/browse/IGNITE-21416
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, sql
>Reporter: Andrey Novikov
>Priority: Minor
> Labels: ignite-3
>
> Globally it works the same way as in
> [https://ignite.apache.org/docs/latest/SQL/sql-calcite#force_index-no_index],
> but has some difference when FORCE_INDEX and NO_INDEX used together in the
> same query.
> When both hints reference to the same index - it is invalid case. SQL is
> declarative language and we shouldn't expect {{hints}} collection is
> ordered:{{{}{}}}
> {code:java}
> {code}
> {{SELECT /*+ FORCE_INDEX(IDX_ID), NO_INDEX */ * FROM TBL1 WHERE id = ? AND
> val = ?}}
> {{OR}}
> {{SELECT /*+ NO_INDEX(IDX_VAL), FORCE_INDEX(IDX_VAL) */ * FROM TBL1 WHERE val
> = ?}}
>
>
> *What to do*
> We need to fix example section and rewrite "Hint Scope" section.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21416) Add documentation for FORCE_INDEX/NO_INDEX hints
[
https://issues.apache.org/jira/browse/IGNITE-21416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov updated IGNITE-21416:
Description:
Globally it works the same way as in
[https://ignite.apache.org/docs/latest/SQL/sql-calcite#force_index-no_index],
but has some difference when FORCE_INDEX and NO_INDEX used together in the same
query.
When both hints reference to the same index - it is invalid case. SQL is
declarative language and we shouldn't expect {{hints}} collection is
ordered:}}{}}}
{code:java}
SELECT /*+ FORCE_INDEX(IDX_ID), NO_INDEX */ * FROM TBL1 WHERE id = ? AND val = ?
OR
SELECT /*+ NO_INDEX(IDX_VAL), FORCE_INDEX(IDX_VAL) */ * FROM TBL1 WHERE val =
?{code}
*What to do*
We need to fix example section and rewrite "Hint Scope" section.
was:
Globally it works the same way as in
[https://ignite.apache.org/docs/latest/SQL/sql-calcite#force_index-no_index],
but has some difference when FORCE_INDEX and NO_INDEX used together in the same
query.
When both hints reference to the same index - it is invalid case. SQL is
declarative language and we shouldn't expect {{hints}} collection is
ordered:{{{}{}}}
{code:java}
{code}
{{SELECT /*+ FORCE_INDEX(IDX_ID), NO_INDEX */ * FROM TBL1 WHERE id = ? AND val
= ?}}
{{OR}}
{{SELECT /*+ NO_INDEX(IDX_VAL), FORCE_INDEX(IDX_VAL) */ * FROM TBL1 WHERE val =
?}}
*What to do*
We need to fix example section and rewrite "Hint Scope" section.
> Add documentation for FORCE_INDEX/NO_INDEX hints
>
>
> Key: IGNITE-21416
> URL: https://issues.apache.org/jira/browse/IGNITE-21416
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, sql
>Reporter: Andrey Novikov
>Priority: Minor
> Labels: ignite-3
>
> Globally it works the same way as in
> [https://ignite.apache.org/docs/latest/SQL/sql-calcite#force_index-no_index],
> but has some difference when FORCE_INDEX and NO_INDEX used together in the
> same query.
> When both hints reference to the same index - it is invalid case. SQL is
> declarative language and we shouldn't expect {{hints}} collection is
> ordered:}}{}}}
> {code:java}
> SELECT /*+ FORCE_INDEX(IDX_ID), NO_INDEX */ * FROM TBL1 WHERE id = ? AND val
> = ?
> OR
> SELECT /*+ NO_INDEX(IDX_VAL), FORCE_INDEX(IDX_VAL) */ * FROM TBL1 WHERE val =
> ?{code}
>
> *What to do*
> We need to fix example section and rewrite "Hint Scope" section.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
