[jira] [Assigned] (IGNITE-21881) Deal with retry send metastorage raft commands after a timeout
[ https://issues.apache.org/jira/browse/IGNITE-21881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-21881: Assignee: Denis Chudov > Deal with retry send metastorage raft commands after a timeout > -- > > Key: IGNITE-21881 > URL: https://issues.apache.org/jira/browse/IGNITE-21881 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Tkalenko >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > As a result of the analysis and reproduction of IGNITE-21142, it was found > that the metastorage raft command can be re-sent if it does not time out, > which may not be good and lead to hidden negative consequences, such as in > IGNITE-21142. > Here we need to find out the reasons for this decision (with re-try by > timeout) and understand what to do next. I think we should use an infinite > timeout. > As a result of the analysis and reproduction of IGNITE-21142, it was found > that the metastorage raft command can be re-sent if it does not time out, > which may not be good and lead to hidden negative consequences, such as in > IGNITE-21142. > Here we need to find out the reasons for this decision (with re-try by > timeout) and understand what to do next. I think we should use an infinite > timeout. > h3. Upd#1 > As discussed, it's required to detect whether InvokeCommand was already > processed on a server and resend original response if true instead of > reprocessing. First of all it's not only about invoke but about all > non-idempotent commands like getAndPut, getAndPutAll, getAndRemove, etc. > Worth mentioning though that it relates only to MS and maybe CMG but not > Partitions: within partitions, tx protocol along with returning result from > indexes instead of returning result from raft, protects us from > non-idempotent command processing. > All in all following solution is expected to be implemented: > * New interface NonIdempotentCommand is introduced with an id field. > * All MS non-idempotent commands like InvokeCommand, GetAndRemoveCommand, > etc implement aforementioned interface. > * On the client side, an identifier is added to the command. Two options are > possible here: > ** It's possible to set id to the the command on command creation. Easiest > way, but it will required extra effort on the server side to track command > time. In that case it's possible to use LongCounter + nodeId as an id. > ** Or it's possible to adjust command with an id within retry loop, in that > case we may use id as a "command time", of course, it also means that clock > or System.currentTime<> should be used as id. I strongly believe that first > option is better for now. > * On the server side, precisely, within MS state machine new > nonIdempotentCommandCache is introduced commandId -> (commandResult, > commandStartTime) > * On each NonIdempotentCommand following logic should be implemented: > ** As an initial step it's required to check whether there's a command with > given id in the cache, if true just return cached result, without command > reprocessing. > ** If there's no given command in the cache, process it and populate the > cache with the result. > Basically that's all. Both cache persistence and recovery on group restart > and cache cleanup will be covered within separate tickets. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22085) Sql. Support F041-07 feature
[ https://issues.apache.org/jira/browse/IGNITE-22085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-22085: - Labels: ignite-3 (was: ) > Sql. Support F041-07 feature > > > Key: IGNITE-22085 > URL: https://issues.apache.org/jira/browse/IGNITE-22085 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Feature F041-07 (The inner table in a left or right outer join can also be > used in an inner join) is not supported for now. Check current issue mention > in logical tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22020) DumpReader misses 'keepRaw' parameter
[ https://issues.apache.org/jira/browse/IGNITE-22020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-22020: - Summary: DumpReader misses 'keepRaw' parameter (was: DumpReder misses 'keepRaw' parameter) > DumpReader misses 'keepRaw' parameter > - > > Key: IGNITE-22020 > URL: https://issues.apache.org/jira/browse/IGNITE-22020 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 40m > Remaining Estimate: 0h > > `DumpReaderConfiguration` and `DumpReder` do not use `raw` parameter. Only > `keepBinary` is available. It makes impossible to read data as > `KeyCacheObject` or `CacheObject` . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21994) Broken link to Monitoring Rebalancing Process
[ https://issues.apache.org/jira/browse/IGNITE-21994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837686#comment-17837686 ] Vyacheslav Koptilin commented on IGNITE-21994: -- lgtm > Broken link to Monitoring Rebalancing Process > - > > Key: IGNITE-21994 > URL: https://issues.apache.org/jira/browse/IGNITE-21994 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Vyacheslav Koptilin >Assignee: Alex Levitski >Priority: Major > > The following documentation topic [Monitoring Rebalancing > Process|http://https://ignite.apache.org/docs/latest/data-rebalancing#monitoring-rebalancing-process] > contains an incorrect link that leads to a non-existent page: > [https://ignite.apache.org/docs/latest/monitoring-metrics/metrics#monitoring-rebalancing] > (perhaps this page was moved or deleted). > I think we can use > [https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics#caches] > where the rebalance metrics are described. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21994) Broken link to Monitoring Rebalancing Process
[ https://issues.apache.org/jira/browse/IGNITE-21994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-21994: Assignee: Alex Levitski > Broken link to Monitoring Rebalancing Process > - > > Key: IGNITE-21994 > URL: https://issues.apache.org/jira/browse/IGNITE-21994 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Vyacheslav Koptilin >Assignee: Alex Levitski >Priority: Major > > The following documentation topic [Monitoring Rebalancing > Process|http://https://ignite.apache.org/docs/latest/data-rebalancing#monitoring-rebalancing-process] > contains an incorrect link that leads to a non-existent page: > [https://ignite.apache.org/docs/latest/monitoring-metrics/metrics#monitoring-rebalancing] > (perhaps this page was moved or deleted). > I think we can use > [https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics#caches] > where the rebalance metrics are described. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22046) Change API usage of Placement driver in PartitionReplicaListener from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-22046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-22046: Assignee: Mirza Aliev > Change API usage of Placement driver in PartitionReplicaListener from > TablePartitionId to ZonePartitionId > - > > Key: IGNITE-22046 > URL: https://issues.apache.org/jira/browse/IGNITE-22046 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to > decompose original task to several subtasks. > In this ticket we need to use previously created decorator for Placement > Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places > where PD was used in PartitionReplicaListener and other places connected to > PartitionReplicaListener that are described in the spreadsheet from > https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be > propagated to PartitionReplicaListener. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22046) Change API usage of Placement driver in PartitionReplicaListener from TablePartitionId to ZonePartitionId
[ https://issues.apache.org/jira/browse/IGNITE-22046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-22046: - Epic Link: IGNITE-19170 > Change API usage of Placement driver in PartitionReplicaListener from > TablePartitionId to ZonePartitionId > - > > Key: IGNITE-22046 > URL: https://issues.apache.org/jira/browse/IGNITE-22046 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > In https://issues.apache.org/jira/browse/IGNITE-21858 we have agreed to > decompose original task to several subtasks. > In this ticket we need to use previously created decorator for Placement > Driver from https://issues.apache.org/jira/browse/IGNITE-21911 for all places > where PD was used in PartitionReplicaListener and other places connected to > PartitionReplicaListener that are described in the spreadsheet from > https://issues.apache.org/jira/browse/IGNITE-21858. Also zone id must be > propagated to PartitionReplicaListener. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22036) Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest
[ https://issues.apache.org/jira/browse/IGNITE-22036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-22036: Assignee: Mikhail Efremov > Replace TableManager.changePeersOnRebalance by the broadcast ReplicaRequest > --- > > Key: IGNITE-22036 > URL: https://issues.apache.org/jira/browse/IGNITE-22036 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mikhail Efremov >Priority: Major > Labels: ignite-3 > > *Motivation* > To simplify the process of moving to the zone-based collocation we need to > remove all raft-connected code from TableManager. After IGNITE-21805 we will > still have: > * TableManager.changePeersOnRebalance > This method must be replaced by appropriate request to Replica. > *Definition of done* > * TableManager send the broadcast ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct call to raft changePeersAsync > *Implementation details* > We need to: > * Introduce ChangePeersReplicaRequest(PeersAndLearners peersAndLearners) - > the new replica request type > * Move the code from TableManager.changePeersOnRebalance to the Replica > itself, as a reaction to ChangePeersReplicaRequest > * TableManager must send the ChangePeersReplicaRequest to all nodes from > table partition assignments instead of direct > TableManager.changePeersOnRebalance call -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21806) Design one PrimaryReplica for many tables partitions inside the one zone
[ https://issues.apache.org/jira/browse/IGNITE-21806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-21806: Assignee: Alexander Lapin (was: Kirill Gusakov) > Design one PrimaryReplica for many tables partitions inside the one zone > > > Key: IGNITE-21806 > URL: https://issues.apache.org/jira/browse/IGNITE-21806 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > > *Motivation* > When the IGNITE-18991 we will have ZonePartitionId oriented management inside > the PlacementDriver, but still have the number of replicas, which equals to > the number of tables per partition in the zone. As a iterative step on the > road of "zone based collocation (one RAFT group per zone partition" we must > implement the another approach: one PrimaryReplica for many tables partitions > inside the zone. So, in the case of 2 tables inside the 1 zone we must have 1 > PrimaryReplica per partition. > *Definition of done* > Prepare design and according ticket breakdown for the feature implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22024) ItSqlClientSynchronousApiTest#runtimeErrorInDmlCausesTransactionToFail is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-22024:
-
Epic Link: IGNITE-21389
Ignite Flags: (was: Docs Required,Release Notes Required)
> ItSqlClientSynchronousApiTest#runtimeErrorInDmlCausesTransactionToFail is
> flaky
> ---
>
> Key: IGNITE-22024
> URL: https://issues.apache.org/jira/browse/IGNITE-22024
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Attachments: screenshot-1.png
>
>
> h3. Motivation
> Only one commit is a base transaction guarantee. The test shows this
> guarantee is violated for thin clients.
> {noformat}
> java.lang.AssertionError: Exception has not been thrown.
>
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCode(IgniteTestUtils.java:314)
> at
> org.apache.ignite.internal.sql.api.ItSqlApiBaseTest.runtimeErrorInDmlCausesTransactionToFail(ItSqlApiBaseTest.java:648)
> at
> org.apache.ignite.internal.sql.api.ItSqlClientSynchronousApiTest.runtimeErrorInDmlCausesTransactionToFail(ItSqlClientSynchronousApiTest.java:65)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1654)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:274)
> at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1654)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> {noformat}
> h3. Definition of done
> Any transaction operation must
[jira] [Updated] (IGNITE-21594) Storage profiles
[
https://issues.apache.org/jira/browse/IGNITE-21594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21594:
-
Reviewer: Aleksandr Polovtcev
> Storage profiles
> -
>
> Key: IGNITE-21594
> URL: https://issues.apache.org/jira/browse/IGNITE-21594
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Gusakov
>Assignee: Kirill Gusakov
>Priority: Major
> Labels: ignite-3
> Attachments: storage-profiles-configuration.svg
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> *Motivation*
> To implement the consistent behaviour for zone-based collocation
> https://issues.apache.org/jira/browse/IGNITE-19170 we need to introduce the
> new storage configuration approach. It must give us a guarantee, that all
> tables, which belong to the same zone, can be deployed on any nodes from this
> zone.
> To support these guarantees we introduced the new abstraction - storage
> profiles
> In general the main idea is the following:
> - Each table has the 1 storage profile. If storage profile is not specified,
> the first storage profile from the zone's storage profiles list will be used.
> - Each zone has the list of supported storage profiles.
> - Each node provide the list of supported storage profiles.
> - In addition to the usual zone filter, zone filters the nodes by the
> storage profiles list and ensure, that the nodes support the full list of
> zone storage profiles.
> - Each node supports the 'default' storage profile. Default zone has the
> 'default' storage profile as well. So, out of the box, user can just create
> the tables in the default zone and know nothing about the storage profile
> routine.
> From the point of configuration view, node storage configurations will be
> changed in the following way:
> {code:java}
> rocksDb:
> flushDelayMillis: 1000
> regions:
> lruRegion:
> cache: lru
> size: 256
> clockRegion:
> cache: clock
> size: 512
> aipersist:
> checkpoint:
> checkpointDelayMillis: 100
> regions:
> segmentedRegion:
> replacementMode: SEGMENTED_LRU
> clockRegion:
> replacementMode: CLOCK
> {code}
> to
> {code:java}
> storages:
> engines:
> aipersist:
> checkpoint:
> checkpointDelayMillis: 100
> rocksDb:
> flushDelayMillis: 1000
> profiles:
> lru_rocks:
> engine: rocksDb
> cache: lru
> size: 256
> clock_rocks:
> engine: rocksDb
> cache: clock
> size: 512
> segmented_aipersist:
> engine: aipersist
> replacementMode: SEGMENTED_LRU
> clock_aipersist:
> engine: aipersist
> replacementMode: CLOCK
> {code}
> *Definition of node*
> - Storage configuration structure reworked according to the feature design
> (please, look at the attached diagram to simplify the initial understanding
> of the result configuration structure).
> - All legacy abstractions like ENGINE and DATAREGION params removed from the
> DDLs.
> - The triad zone-table-node_configs is working as expected according to the
> storage profile design document.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22008) Fix double-checked locking in ReadWriteTransactionImpl
[
https://issues.apache.org/jira/browse/IGNITE-22008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-22008:
-
Labels: ignite-3 (was: )
> Fix double-checked locking in ReadWriteTransactionImpl
> --
>
> Key: IGNITE-22008
> URL: https://issues.apache.org/jira/browse/IGNITE-22008
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{finishFuture}} needs to be made volatile
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22007) Optimise Read-only index scan for RocksDB
[ https://issues.apache.org/jira/browse/IGNITE-22007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-22007: - Labels: ignite-3 (was: ) > Optimise Read-only index scan for RocksDB > -- > > Key: IGNITE-22007 > URL: https://issues.apache.org/jira/browse/IGNITE-22007 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Philipp Shergalis >Priority: Major > Labels: ignite-3 > > In IGNITE-21987 we added readOnlyScan method for SortedIndexStorage, but > RocksDB currently RocksDB uses default method, relying on read-write > implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21928) Describe Catalog operation flow in README
[ https://issues.apache.org/jira/browse/IGNITE-21928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21928: - Labels: ignite-3 (was: ) > Describe Catalog operation flow in README > - > > Key: IGNITE-21928 > URL: https://issues.apache.org/jira/browse/IGNITE-21928 > Project: Ignite > Issue Type: Improvement >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > Describe CatalogService operations in README.md -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21994) Broken link to Monitoring Rebalancing Process
Vyacheslav Koptilin created IGNITE-21994: Summary: Broken link to Monitoring Rebalancing Process Key: IGNITE-21994 URL: https://issues.apache.org/jira/browse/IGNITE-21994 Project: Ignite Issue Type: Bug Components: documentation Reporter: Vyacheslav Koptilin The following documentation topic [Monitoring Rebalancing Process|http://https://ignite.apache.org/docs/latest/data-rebalancing#monitoring-rebalancing-process] contains an incorrect link that leads to a non-existent page: [https://ignite.apache.org/docs/latest/monitoring-metrics/metrics#monitoring-rebalancing] (perhaps this page was moved or deleted). I think we can use [https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics#caches] where the rebalance metrics are described. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16262) Remove the hash join index section from docs
[ https://issues.apache.org/jira/browse/IGNITE-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16262: - Labels: documentation (was: docuentation documentation) > Remove the hash join index section from docs > > > Key: IGNITE-16262 > URL: https://issues.apache.org/jira/browse/IGNITE-16262 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.11.1 >Reporter: Nikita A. Safonov >Assignee: Nikita A. Safonov >Priority: Major > Labels: documentation > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > We need to remove the hash join index section from the docs > ([https://ignite.apache.org/docs/latest/SQL/distributed-joins#hash-joins]) as > there is no such functionality in Apache Ignite. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21892) ItPlacementDriverReplicaSideTest testNotificationToPlacementDriverAboutChangeLeader is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-21892:
Assignee: Alexander Lapin
> ItPlacementDriverReplicaSideTest
> testNotificationToPlacementDriverAboutChangeLeader is flaky
>
>
> Key: IGNITE-21892
> URL: https://issues.apache.org/jira/browse/IGNITE-21892
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Assignee: Alexander Lapin
>Priority: Minor
> Labels: ignite-3
>
> This test is flaky. Build error:
> {code}
> java.lang.AssertionError: There are replicas alive [replicas=[group_1]]
> at
> org.apache.ignite.internal.replicator.ReplicaManager.stop(ReplicaManager.java:658)
> at
> org.apache.ignite.internal.replicator.ItPlacementDriverReplicaSideTest.lambda$beforeTest$3(ItPlacementDriverReplicaSideTest.java:200)
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$closeAll$0(IgniteUtils.java:559)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> org.apache.ignite.internal.util.IgniteUtils.closeAll(IgniteUtils.java:557)
> at
> org.apache.ignite.internal.util.IgniteUtils.closeAll(IgniteUtils.java:580)
> at
> org.apache.ignite.internal.replicator.ItPlacementDriverReplicaSideTest.afterTest(ItPlacementDriverReplicaSideTest.java:214)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> {code}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_IntegrationTests_ModuleReplicator/7987165?expandBuildDeploymentsSection=false=false=true=false=true=true=7987165_489_86.470.489=debug=flowAware
> I was not able to reproduce the same error locally, I got an error on the
> following line instead:
> {code}
> assertTrue(waitForCondition(() -> nodesToReceivedDeclineMsg.size() ==
> placementDriverNodeNames.size(), 10_000));
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21619) "Failed to get the primary replica" after massive data insert and node restart
[
https://issues.apache.org/jira/browse/IGNITE-21619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-21619:
Assignee: Alexander Lapin
> "Failed to get the primary replica" after massive data insert and node restart
> --
>
> Key: IGNITE-21619
> URL: https://issues.apache.org/jira/browse/IGNITE-21619
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3, sql
> Attachments: ignite-config.conf, ignite3db-0.log
>
>
> Steps to reproduce:
> 1. Start a 1-node cluster.
> 2 Create several tables (5, for example) in aipersist zone.
> 3. Fill these tables with some data (1000 rows each, for example).
> 4. Verify that data is accessible via SQL.
> 5. Restart a node.
> 6. Try to fetch the same data again.
> Expected result: we could fetch data.
> Actual result: data is inaccessible.
> Trace on the client side:
> {code}
> java.sql.SQLException: Failed to get the primary replica
> [tablePartitionId=6_part_1]
> at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111)
>...
> {code}
> Trace in node log (attached):
> {code}
> 2024-02-28 12:36:34:807 +0500
> [INFO][%ClusterFailoverTest_cluster_0%sql-execution-pool-0][JdbcQueryEventHandlerImpl]
> Exception while executing query [query=select sum(k1) from failoverTest00]
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:8d366905-a4bb-4333-b0b3-c647a1cf943f Failed to get the primary
> replica [tablePartitionId=6_part_1]
> at
> org.apache.ignite.internal.lang.SqlExceptionMapperUtil.mapToPublicSqlException(SqlExceptionMapperUtil.java:61)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.wrapIfNecessary(AsyncSqlCursorImpl.java:180)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.handleError(AsyncSqlCursorImpl.java:157)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$2(AsyncSqlCursorImpl.java:96)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$18(ExecutionServiceImpl.java:864)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at
> java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:83)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:8d366905-a4bb-4333-b0b3-c647a1cf943f Failed to get the primary
> replica [tablePartitionId=6_part_1]
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:117)
> at
> org.apache.ignite.internal.lang.SqlExceptionMapperUtil.mapToPublicSqlException(SqlExceptionMapperUtil.java:51)
> ... 15 more
> Caused by: org.apache.ignite.internal.lang.IgniteInternalException:
> IGN-PLACEMENTDRIVER-1 TraceId:8d366905-a4bb-4333-b0b3-c647a1cf943f Failed to
> get the primary replica [tablePartitionId=6_part_1]
> at
> org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$1(ExceptionUtils.java:384)
> at
> org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:446)
> at
> org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:384)
> at
> org.apache.ignite.internal.sql.engine.SqlQueryProcessor.lambda$primaryReplicas$2(SqlQueryProcessor.java:402)
> at
>
[jira] [Commented] (IGNITE-21926) The status of GridCacheLockImpl and GridCacheSemaphoreImpl may be inconsistent
[
https://issues.apache.org/jira/browse/IGNITE-21926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833936#comment-17833936
]
Vyacheslav Koptilin commented on IGNITE-21926:
--
Hi [~yexiaowei] ,
Could you please share a test that demonstrates the issue? It would be nice to
add it to the patch.
> The status of GridCacheLockImpl and GridCacheSemaphoreImpl may be inconsistent
> --
>
> Key: IGNITE-21926
> URL: https://issues.apache.org/jira/browse/IGNITE-21926
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: yexiaowei
>Priority: Major
>
> I noticed that GridCacheLockImpl and GridCacheSemaphoreImpl can cause
> deadlocks. Because their model is similar to the following
> {code:java}
> Sync sync;
>
> void init() {
> sync = getSync();
> }
>
> void onUpdate(val) {
> if(sync == null) {
> return;
> }
> update(sync);
> }
> {code}
> If init and onUpdate occur at the same time, update may be missed and lagging
> data may be obtained. The fix I gave is similar to:
> {code:java}
> Sync sync;
> boolean flag = false;
>
> void init() {
> do {
> flag = false;
> s = getSync();
> } while(flag);
> }
>
> void onUpdate(val) {
> if(sync == null) {
> flag = true;
> return;
> }
> update(sync);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21307) Call failure handler in case of failure in WatchProcessor
[
https://issues.apache.org/jira/browse/IGNITE-21307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-21307:
Assignee: Vyacheslav Koptilin
> Call failure handler in case of failure in WatchProcessor
> -
>
> Key: IGNITE-21307
> URL: https://issues.apache.org/jira/browse/IGNITE-21307
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> For the linearized watch processing, we have
> WatchProcessor#notificationFuture that is rewritten for each revision
> processing and meta storage safe time advance. If some watch processor
> completes exceptionally, this means that no further updates will be
> processed, because they need the previous updates to be processed
> successfully. This is implemented in futures chaining like this:
>
> {code:java}
> notificationFuture = notificationFuture
> .thenRunAsync(() -> revisionCallback.onSafeTimeAdvanced(time),
> watchExecutor)
> .whenComplete((ignored, e) -> {
> if (e != null) {
> LOG.error("Error occurred when notifying safe time advanced
> callback", e);
> }
> }); {code}
> For now, we dont have any failure handing of exceptionally completed
> notification future. It leads to the endless log records with the same
> exception's stack trace, caused by meta storage safe time advances:
>
> {code:java}
> [2024-01-16T21:42:35,515][ERROR][%isot_n_0%JRaft-FSMCaller-Disruptor-metastorage-_stripe_0-0][WatchProcessor]
> Error occurred when notifying safe time advanced callback
> java.util.concurrent.CompletionException:
> org.apache.ignite.internal.lang.IgniteInternalException: IGN-CMN-65535
> TraceId:3877e098-6a1b-4f30-88a8-a4c13411d573 Peers are not ready
> [groupId=5_part_0]
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1081)
> ~[?:?]
> 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:834) [?:?]
> Caused by: org.apache.ignite.internal.lang.IgniteInternalException: Peers are
> not ready [groupId=5_part_0]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.randomNode(RaftGroupServiceImpl.java:725)
> ~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.randomNode(RaftGroupServiceImpl.java:709)
> ~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:234)
> ~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:190)
> ~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.start(TopologyAwareRaftGroupService.java:187)
> ~[ignite-replicator-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupServiceFactory.startRaftGroupService(TopologyAwareRaftGroupServiceFactory.java:73)
> ~[ignite-replicator-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.Loza.startRaftGroupService(Loza.java:350)
> ~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$startPartitionAndStartClient$27(TableManager.java:917)
> ~[ignite-table-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:827)
> ~[ignite-core-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$startPartitionAndStartClient$28(TableManager.java:913)
> ~[ignite-table-9.0.127-SNAPSHOT.jar:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> ~[?:?]
> ... 4 more {code}
> So, the node can't operate properly and just produces tons of logs. Such
> nodes should be halted.
> UPD:
> We decided to just add invocation of {{failureProcessor.process}} in all
> places in {{org.apache.ignite.internal.metastorage.server.WatchProcessor}}
> where exceptions happen, like
> {code:java}
> notifyWatchFuture = watchAndEvents.watch.onUpdate(event)
> .whenComplete((v,
[jira] [Updated] (IGNITE-21871) SharedRocksDbInstance#sortedIndexes method is not thread-safe
[
https://issues.apache.org/jira/browse/IGNITE-21871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21871:
-
Labels: ignite-3 (was: )
> SharedRocksDbInstance#sortedIndexes method is not thread-safe
> -
>
> Key: IGNITE-21871
> URL: https://issues.apache.org/jira/browse/IGNITE-21871
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
>
> It is possible to obtain a {{ConcurrentModificationException}} when calling
> {{SharedRocksDbInstance#sortedIndexes}}, because it performs a scan over a
> non-concurrent map that can actually be concurrently modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21859) Causality token stays 0 for default zone
[
https://issues.apache.org/jira/browse/IGNITE-21859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21859:
-
Labels: ignite-3 (was: )
> Causality token stays 0 for default zone
>
>
> Key: IGNITE-21859
> URL: https://issues.apache.org/jira/browse/IGNITE-21859
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> We have a problem where if no alter or other action was performed on default
> zone causality token in CatalogZoneDescriptor will remain 0.
> It will cause an error on any attempt of rebalacing any tables in that zone:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-18][DistributionZoneRebalanceEngine]
> Failed to update stable keys for tables [[TESTTABLE]]
> {code}
> If we will add stacktrace to output we will get following:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-13][DistributionZoneRebalanceEngine]
> CATCH,
> java.lang.IllegalArgumentException: causalityToken must be greater then zero
> [causalityToken=0"
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine.dataNodes(CausalityDataNodesEngine.java:139)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.dataNodes(DistributionZoneManager.java:324)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine.calculateAssignments(DistributionZoneRebalanceEngine.java:346)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.doStableKeySwitch(RebalanceRaftGroupEventsListener.java:408)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$0(DistributionZoneRebalanceEngine.java:294)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at java.base/java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$1(DistributionZoneRebalanceEngine.java:293)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
> {code}
> The workaround is creating a zone and specifying this zone to table.
> Also wouldn't be a bad idea to print stacktrace for "Failed to update stable
> keys for tables" at least on DEBUG log level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21538) Rework component lifecycle mode to asynchronous
[
https://issues.apache.org/jira/browse/IGNITE-21538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-21538:
Assignee: Kirill Sizov
> Rework component lifecycle mode to asynchronous
> ---
>
> Key: IGNITE-21538
> URL: https://issues.apache.org/jira/browse/IGNITE-21538
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta2
>Reporter: Alexey Scherbakov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> Current design for comp lifecycle has issues:
> 1. It was designed for synchronous components, but almost all components are
> asynchronous.
> This causes to appear ugly things like _inBusyLockAsync_ and inefficient code
> like
> _public @Nullable TxStateMeta stateMeta(UUID txId) \{ return
> inBusyLock(busyLock, () -> txStateVolatileStorage.state(txId)); }_
> 2. Currently it's not possible to do truly graceful node shutdown, because IO
> layer is disabled out-of-order, causing operation failures without a chance
> to finish.
> I suggest to rework comp lifecycle to async model:
> 1. Each component tracks it's inflight async ops (as list of async chains)
> 2. On start components are initialized using _CompletableFuture
> startAsync()_ method from root to leafs of dependency tree
> 3. On shutdown
> 3.1 _CompletableFuturebeforeShutdown_ is called on comp from leafs to
> root direction in dependency tree. This step waits for all active futures to
> complete. Any new operation return a future completed with
> _NodeStoppingException_
> 3.2 stop is called on comp from leafs to root direction in dependency tree.
> This step destroys component resources, like pools, etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21806) One PrimaryReplica for many tables partitions inside the one zone
[ https://issues.apache.org/jira/browse/IGNITE-21806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-21806: Assignee: Kirill Gusakov > One PrimaryReplica for many tables partitions inside the one zone > - > > Key: IGNITE-21806 > URL: https://issues.apache.org/jira/browse/IGNITE-21806 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > When the IGNITE-18991 we will have ZonePartitionId oriented management inside > the PlacementDriver, but still have the number of replicas, which equals to > the number of tables per partition in the zone. As a iterative step on the > road of "zone based collocation (one RAFT group per zone partition" we must > implement the another approach: one PrimaryReplica for many tables partitions > inside the zone. So, in the case of 2 tables inside the 1 zone we must have 1 > PrimaryReplica per partition. > *Definition of done* > If the zone has N tables with M partitions, it must have M PrimaryReplicas - > one PrimaryReplica per zone partition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21596) ItRebalanceTriggersRecoveryTest#testRebalanceTriggersRecoveryWhenUpdatesWereProcessedByAnotherNodesAlready fails with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-21596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21596:
-
Epic Link: IGNITE-21389
Ignite Flags: (was: Docs Required,Release Notes Required)
> ItRebalanceTriggersRecoveryTest#testRebalanceTriggersRecoveryWhenUpdatesWereProcessedByAnotherNodesAlready
> fails with AssertionError
>
>
> Key: IGNITE-21596
> URL: https://issues.apache.org/jira/browse/IGNITE-21596
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: <41> but was: <47> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:166)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:161)
> at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:632)
> at
> app//org.apache.ignite.internal.rebalance.ItRebalanceTriggersRecoveryTest.testRebalanceTriggersRecoveryWhenUpdatesWereProcessedByAnotherNodesAlready(ItRebalanceTriggersRecoveryTest.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21400) ItDataSchemaSyncTest.checkSchemasCorrectlyRestore() is flaky with The query was cancelled while executing
[
https://issues.apache.org/jira/browse/IGNITE-21400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-21400:
Assignee: Alexander Lapin
> ItDataSchemaSyncTest.checkSchemasCorrectlyRestore() is flaky with The query
> was cancelled while executing
> -
>
> Key: IGNITE-21400
> URL: https://issues.apache.org/jira/browse/IGNITE-21400
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.ignite.sql.SqlException: IGN-SQL-8
> TraceId:9ddffd30-18d6-4006-ae81-f72867235290 The query was cancelled while
> executing. at
> java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:634)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
> at
> app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> at
> app//org.apache.ignite.internal.runner.app.ItDataSchemaSyncTest.checkSchemasCorrectlyRestore(ItDataSchemaSyncTest.java:252)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
> at
> app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
>{code}
> Seems to be exactly the same as
> https://issues.apache.org/jira/browse/IGNITE-20883
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20918) Leases expire after a node has been restarted
[
https://issues.apache.org/jira/browse/IGNITE-20918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20918:
-
Epic Link: IGNITE-21389
> Leases expire after a node has been restarted
> -
>
> Key: IGNITE-20918
> URL: https://issues.apache.org/jira/browse/IGNITE-20918
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Alexander Lapin
>Priority: Critical
> Labels: ignite-3
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> IGNITE-20910 introduces a test that inserts some data after restarting a
> node. For some reason, after some time, I can see the following messages in
> the log:
> {noformat}
> [2023-11-22T10:00:17,056][INFO
> ][%isnt_tmpar_0%metastorage-watch-executor-3][PartitionReplicaListener]
> Primary replica expired [grp=5_part_19]
> [2023-11-22T10:00:17,057][INFO
> ][%isnt_tmpar_0%metastorage-watch-executor-3][PartitionReplicaListener]
> Primary replica expired [grp=5_part_0]
> [2023-11-22T10:00:17,057][INFO
> ][%isnt_tmpar_0%metastorage-watch-executor-3][PartitionReplicaListener]
> Primary replica expired [grp=5_part_9]
> [2023-11-22T10:00:17,057][INFO
> ][%isnt_tmpar_0%metastorage-watch-executor-3][PartitionReplicaListener]
> Primary replica expired [grp=5_part_10]
> {noformat}
> After that, the test fails with a {{PrimaryReplicaMissException}}. The
> problem here, that it is expected that a single node should never have
> expired leases, they should be prolongated automatically. I think that this
> happens because the initial lease that was issued before the node was
> restarted is still accepted by the node after restart.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21799) A transaction rollback fails with assertion error
[
https://issues.apache.org/jira/browse/IGNITE-21799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21799:
-
Priority: Major (was: Blocker)
> A transaction rollback fails with assertion error
> -
>
> Key: IGNITE-21799
> URL: https://issues.apache.org/jira/browse/IGNITE-21799
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> A transaction rollback fails with
> {noformat}
> java.lang.AssertionError: Thread does not have allowed operations
> {noformat}
> Here is a simple reproducer below.
> You can use an`ItCommonTest` to reproduce.
> {code:java}
> @Test
> public void rollbackAsync() {
> Ignite node = CLUSTER.aliveNode();
> sql("CREATE TABLE IF NOT EXISTS TEST(ID INT PRIMARY KEY, VAL0 INT)");
> KeyValueView view1 =
> node.tables().table("TEST").keyValueView();
> AtomicReference> rollbackFut = new
> AtomicReference<>();
>
> Transaction tx = node.transactions().begin();
> view1.getAsync(tx, makeKey(101))
> .handle((unused, err) -> {
> rollbackFut.set(tx.rollbackAsync()); // unconditional
> roll back
> return null;
> }).join();
> rollbackFut.get().join(); // <- FAILS
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20731) Exception "The primary replica has changed" on big amount of rows
[
https://issues.apache.org/jira/browse/IGNITE-20731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20731:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Exception "The primary replica has changed" on big amount of rows
> -
>
> Key: IGNITE-20731
> URL: https://issues.apache.org/jira/browse/IGNITE-20731
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
>
> *Steps to reproduce:*
> 1. Start cluster with 1 node with JVM options: "-Xms4096m -Xmx4096m"
> 2. Execute
> {code:java}
> create table rows_capacity_table(id INTEGER not null, column_1 VARCHAR(50)
> not null, column_2 VARCHAR(50) not null, column_3 VARCHAR(50) not null,
> column_4 VARCHAR(50) not null, primary key (id)) {code}
> 3. Insert rows into table up to 1 000 000 rows.
> *Expected result:*
> Rows are inserted.
> *Actual result:*
> After 733000 rows the exception is thrown.
> Client:
> {code:java}
> java.sql.BatchUpdateException:
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException:
> IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica
> has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0,
> currentLeaseholder=null]
> at
> org.apache.ignite.internal.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:155)
> {code}
> Server:
> {code:java}
> 2023-10-23 13:47:31:529 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_12]
> 2023-10-23 13:47:31:532 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_20]
> 2023-10-23 13:47:31:536 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_24]
> 2023-10-23 13:47:31:539 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_16]
> 2023-10-23 13:47:31:699 +0300
> [WARNING][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-3][ReplicaManager]
> Failed to process replica request [request=TxFinishReplicaRequestImpl
> [commit=false, commitTimestampLong=111283931920007204, groupId=5_part_24,
> groups=HashSet [5_part_5, 5_part_4, 5_part_7, 5_part_6, 5_part_1, 5_part_0,
> 5_part_3, 5_part_2, 5_part_13, 5_part_12, 5_part_15, 5_part_14, 5_part_9,
> 5_part_8, 5_part_11, 5_part_10, 5_part_21, 5_part_20, 5_part_23, 5_part_22,
> 5_part_17, 5_part_16, 5_part_19, 5_part_18, 5_part_24],
> term=111283839559532593, timestampLong=111283932466315264,
> txId=018b5c25-7653---23c06ab5]]
> java.util.concurrent.CompletionException:
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException:
> IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica
> has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0,
> currentLeaseholder=null]
> at
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> at
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> at
> java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> at
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$7(WatchProcessor.java:281)
> at
>
[jira] [Updated] (IGNITE-20142) Introduce changes for JDK17 tests run
[ https://issues.apache.org/jira/browse/IGNITE-20142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20142: - Labels: ise (was: ignite-3 ise) > Introduce changes for JDK17 tests run > - > > Key: IGNITE-20142 > URL: https://issues.apache.org/jira/browse/IGNITE-20142 > Project: Ignite > Issue Type: Improvement >Reporter: Petr Ivanov >Assignee: Petr Ivanov >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > > Introduce several changes and extend current WAs for ability to run tests > under JDK17. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21829) Trigger failureProcessor in case of exceptions in ResourceVacuumManager
[ https://issues.apache.org/jira/browse/IGNITE-21829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21829: - Summary: Trigger failureProcessor in case of exceptions in ResourceVacuumManager (was: Tigger failureProcessor in case of exceptions in ResourceVacuumManager) > Trigger failureProcessor in case of exceptions in ResourceVacuumManager > --- > > Key: IGNITE-21829 > URL: https://issues.apache.org/jira/browse/IGNITE-21829 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21829) Tigger failureProcessor in case of exceptions in ResourceVacuumManager
[ https://issues.apache.org/jira/browse/IGNITE-21829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21829: - Labels: ignite-3 (was: ) > Tigger failureProcessor in case of exceptions in ResourceVacuumManager > -- > > Key: IGNITE-21829 > URL: https://issues.apache.org/jira/browse/IGNITE-21829 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21829) Trigger failureProcessor in case of exceptions in ResourceVacuumManager
[ https://issues.apache.org/jira/browse/IGNITE-21829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21829: - Ignite Flags: (was: Docs Required,Release Notes Required) > Trigger failureProcessor in case of exceptions in ResourceVacuumManager > --- > > Key: IGNITE-21829 > URL: https://issues.apache.org/jira/browse/IGNITE-21829 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20142) Introduce changes for JDK17 tests run
[ https://issues.apache.org/jira/browse/IGNITE-20142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20142: - Labels: ignite-3 ise (was: ise) > Introduce changes for JDK17 tests run > - > > Key: IGNITE-20142 > URL: https://issues.apache.org/jira/browse/IGNITE-20142 > Project: Ignite > Issue Type: Improvement >Reporter: Petr Ivanov >Assignee: Petr Ivanov >Priority: Major > Labels: ignite-3, ise > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > > Introduce several changes and extend current WAs for ability to run tests > under JDK17. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18991) Move stable/planned/pending assignments from table to distribution zone root keys
[ https://issues.apache.org/jira/browse/IGNITE-18991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-18991: Assignee: Vladislav Pyatkov (was: Mirza Aliev) > Move stable/planned/pending assignments from table to distribution zone root > keys > - > > Key: IGNITE-18991 > URL: https://issues.apache.org/jira/browse/IGNITE-18991 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 1h 10m > Remaining Estimate: 0h > > Under the activities about moving distribution zone based data management we > need to: > * Replace metastore stable/planned/pending assignments per table by the same > per distribution zone with the correspondance keys roots zoneId.* > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21799) A transaction rollback fails with assertion error
[
https://issues.apache.org/jira/browse/IGNITE-21799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21799:
-
Labels: ignite-3 (was: )
> A transaction rollback fails with assertion error
> -
>
> Key: IGNITE-21799
> URL: https://issues.apache.org/jira/browse/IGNITE-21799
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> A transaction rollback fails with
> {noformat}
> java.lang.AssertionError: Thread does not have allowed operations
> {noformat}
> Here is a simple reproducer below.
> You can use an`ItCommonTest` to reproduce.
> {code:java}
> @Test
> public void rollbackAsync() {
> Ignite node = CLUSTER.aliveNode();
> sql("CREATE TABLE IF NOT EXISTS TEST(ID INT PRIMARY KEY, VAL0 INT)");
> KeyValueView view1 =
> node.tables().table("TEST").keyValueView();
> AtomicReference> rollbackFut = new
> AtomicReference<>();
>
> Transaction tx = node.transactions().begin();
> view1.getAsync(tx, makeKey(101))
> .handle((unused, err) -> {
> rollbackFut.set(tx.rollbackAsync()); // unconditional
> roll back
> return null;
> }).join();
> rollbackFut.get().join(); // <- FAILS
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21758) Txn resource vacuum
[ https://issues.apache.org/jira/browse/IGNITE-21758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21758: - Labels: ignite-3 (was: ) > Txn resource vacuum > --- > > Key: IGNITE-21758 > URL: https://issues.apache.org/jira/browse/IGNITE-21758 > Project: Ignite > Issue Type: Epic >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21795) Unconditionally update storage with proper raft index within PartitionListener
[
https://issues.apache.org/jira/browse/IGNITE-21795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21795:
-
Labels: ignite-3 (was: )
> Unconditionally update storage with proper raft index within PartitionListener
> --
>
> Key: IGNITE-21795
> URL: https://issues.apache.org/jira/browse/IGNITE-21795
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Despite the fact that it's reasonable to skip data update if it was already
> executed on collocated primary replica storage, it's required to
> unconditionally update storage with proper raft index within
> PartitionListener. For more details please see:
> {code:java}
> synchronized (safeTime) {
> if (cmd.safeTime().compareTo(safeTime.current()) > 0) {
> storageUpdateHandler.handleUpdate( {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21773) Don't notify low watermark update listeners at node start
[ https://issues.apache.org/jira/browse/IGNITE-21773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21773: - Labels: ignite-3 (was: ) > Don't notify low watermark update listeners at node start > - > > Key: IGNITE-21773 > URL: https://issues.apache.org/jira/browse/IGNITE-21773 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > I noticed that at the moment we are notifying listeners on the start node > about updating the low watermark, although this is not necessary and each > component can read the latest watermark at the start. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21746) Sql. Change default type of primary key index from sorted to hash.
[ https://issues.apache.org/jira/browse/IGNITE-21746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21746: - Labels: ignite-3 (was: ignite3) > Sql. Change default type of primary key index from sorted to hash. > -- > > Key: IGNITE-21746 > URL: https://issues.apache.org/jira/browse/IGNITE-21746 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Let's change type of a primary key index from sorted to hash. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20731) Exception "The primary replica has changed" on big amount of rows
[
https://issues.apache.org/jira/browse/IGNITE-20731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827477#comment-17827477
]
Vyacheslav Koptilin commented on IGNITE-20731:
--
Hello [~lunigorn] [~Berkov] ,
Could you please try to reproduce the issue on the latest main branch? Is it an
actual issue?
> Exception "The primary replica has changed" on big amount of rows
> -
>
> Key: IGNITE-20731
> URL: https://issues.apache.org/jira/browse/IGNITE-20731
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
>
> *Steps to reproduce:*
> 1. Start cluster with 1 node with JVM options: "-Xms4096m -Xmx4096m"
> 2. Execute
> {code:java}
> create table rows_capacity_table(id INTEGER not null, column_1 VARCHAR(50)
> not null, column_2 VARCHAR(50) not null, column_3 VARCHAR(50) not null,
> column_4 VARCHAR(50) not null, primary key (id)) {code}
> 3. Insert rows into table up to 1 000 000 rows.
> *Expected result:*
> Rows are inserted.
> *Actual result:*
> After 733000 rows the exception is thrown.
> Client:
> {code:java}
> java.sql.BatchUpdateException:
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException:
> IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica
> has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0,
> currentLeaseholder=null]
> at
> org.apache.ignite.internal.jdbc.JdbcPreparedStatement.executeBatch(JdbcPreparedStatement.java:155)
> {code}
> Server:
> {code:java}
> 2023-10-23 13:47:31:529 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_12]
> 2023-10-23 13:47:31:532 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_20]
> 2023-10-23 13:47:31:536 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_24]
> 2023-10-23 13:47:31:539 +0300
> [INFO][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-0][PartitionReplicaListener]
> Primary replica expired [grp=5_part_16]
> 2023-10-23 13:47:31:699 +0300
> [WARNING][%TablesAmountCapacityTest_cluster_0%metastorage-watch-executor-3][ReplicaManager]
> Failed to process replica request [request=TxFinishReplicaRequestImpl
> [commit=false, commitTimestampLong=111283931920007204, groupId=5_part_24,
> groups=HashSet [5_part_5, 5_part_4, 5_part_7, 5_part_6, 5_part_1, 5_part_0,
> 5_part_3, 5_part_2, 5_part_13, 5_part_12, 5_part_15, 5_part_14, 5_part_9,
> 5_part_8, 5_part_11, 5_part_10, 5_part_21, 5_part_20, 5_part_23, 5_part_22,
> 5_part_17, 5_part_16, 5_part_19, 5_part_18, 5_part_24],
> term=111283839559532593, timestampLong=111283932466315264,
> txId=018b5c25-7653---23c06ab5]]
> java.util.concurrent.CompletionException:
> org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException:
> IGN-REP-6 TraceId:9b8ef95a-bbbe-48cf-9c94-2e80d01c2033 The primary replica
> has changed [expectedLeaseholder=TablesAmountCapacityTest_cluster_0,
> currentLeaseholder=null]
> at
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> at
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1074)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
> at
> java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
> at
> org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
> at
> org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
> at
> org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
> at
>
[jira] [Commented] (IGNITE-20628) testDropColumn and testMergeChangesAddDropAdd in ItSchemaChangeKvViewTest are disabled
[ https://issues.apache.org/jira/browse/IGNITE-20628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827475#comment-17827475 ] Vyacheslav Koptilin commented on IGNITE-20628: -- It looks like, this ticket depends on IGNITE-21572. Need to check when the fix is ready. > testDropColumn and testMergeChangesAddDropAdd in ItSchemaChangeKvViewTest are > disabled > -- > > Key: IGNITE-20628 > URL: https://issues.apache.org/jira/browse/IGNITE-20628 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > > It was supposed that IGNITE-17931 was the culprit, but even after removing > the blocking code the tests are still flaky. > The tests fail with one of 3 symptoms: > # An NPE happens in the test method code: a value by a key for which a put > is made earlier is not found when using the same key. This is probably caused > by a transactional protocol implementation bug, maybe this: IGNITE-20116 > # A PrimaryReplicaAwaitTimeoutException > # A ReplicationTimeoutException > Items 2 and 3 need to be investigated. > h2. A stacktrace for 1 > java.lang.NullPointerException > at > org.apache.ignite.internal.runner.app.ItSchemaChangeKvViewTest.testDropColumn(ItSchemaChangeKvViewTest.java:58) > h2. A stacktrace for 2 > org.apache.ignite.tx.TransactionException: IGN-PLACEMENTDRIVER-1 > TraceId:0a32c369-b9ca-4091-b8de-af15d65a1f52 Failed to get the primary > replica [tablePartitionId=3_part_5, awaitTimestamp=HybridTimestamp > [time=111220884095959043, physical=1697096009765, logical=3]] > > at > org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$1(ExceptionUtils.java:400) > at > org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:461) > at > org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:400) > at > org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.lambda$enlist$71(InternalTableImpl.java:1659) > at > java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930) > at > java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907) > at > java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) > at > java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088) > at > java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.util.concurrent.CompletionException: > org.apache.ignite.internal.placementdriver.PrimaryReplicaAwaitTimeoutException: > IGN-PLACEMENTDRIVER-1 TraceId:0a32c369-b9ca-4091-b8de-af15d65a1f52 The > primary replica await timed out [replicationGroupId=3_part_5, > referenceTimestamp=HybridTimestamp [time=111220884095959043, > physical=1697096009765, logical=3], currentLease=Lease > [leaseholder=isckvt_tmcada_3346, accepted=false, startTime=HybridTimestamp > [time=111220884127809550, physical=1697096010251, logical=14], > expirationTime=HybridTimestamp [time=111220891992129536, > physical=1697096130251, logical=0], prolongable=false, > replicationGroupId=3_part_5]] > at > java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314) > at > java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319) > at > java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:990) > at > java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970) > ... 9 more > Caused by: > org.apache.ignite.internal.placementdriver.PrimaryReplicaAwaitTimeoutException: > IGN-PLACEMENTDRIVER-1 TraceId:0a32c369-b9ca-4091-b8de-af15d65a1f52 The > primary replica await timed out [replicationGroupId=3_part_5, > referenceTimestamp=HybridTimestamp [time=111220884095959043, > physical=1697096009765, logical=3], currentLease=Lease > [leaseholder=isckvt_tmcada_3346, accepted=false, startTime=HybridTimestamp > [time=111220884127809550, physical=1697096010251, logical=14], > expirationTime=HybridTimestamp [time=111220891992129536, >
[jira] [Assigned] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-21391:
Assignee: Alexander Lapin
> ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
> ---
>
> Key: IGNITE-21391
> URL: https://issues.apache.org/jira/browse/IGNITE-21391
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Attachments: test.log
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
> the appropariate line of code with fail
> [https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570]
> {code:java}
> cluster.ensureSame();{code}
> Didn't manage to reproduce the issue locally, however, there are several
> failures in TC with same reason.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21707) Update openapi-generator
[ https://issues.apache.org/jira/browse/IGNITE-21707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21707: - Labels: ignite-3 ignite-3-cli-tool (was: ignite-3-cli-tool) > Update openapi-generator > > > Key: IGNITE-21707 > URL: https://issues.apache.org/jira/browse/IGNITE-21707 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > Time Spent: 20m > Remaining Estimate: 0h > > We use 5.x version of https://github.com/OpenAPITools/openapi-generator but > the latest one is 7.x -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21649) Fix warning caused by PMD configuration referencing nonexisting rule
[ https://issues.apache.org/jira/browse/IGNITE-21649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21649: - Labels: ignite-3 (was: ) > Fix warning caused by PMD configuration referencing nonexisting rule > > > Key: IGNITE-21649 > URL: https://issues.apache.org/jira/browse/IGNITE-21649 > Project: Ignite > Issue Type: Improvement >Reporter: Viacheslav Blinov >Assignee: Viacheslav Blinov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21592) module packaging-java-client may produce artifact resolution error under some environments
[
https://issues.apache.org/jira/browse/IGNITE-21592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21592:
-
Labels: ignite-3 (was: )
> module packaging-java-client may produce artifact resolution error under some
> environments
> --
>
> Key: IGNITE-21592
> URL: https://issues.apache.org/jira/browse/IGNITE-21592
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Assignee: Viacheslav Blinov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After merging IGNITE-21432 and running the following build target:
> {noformat}
> ./gradlew build -x test -x integrationTest --continue{noformat}
> The build fails with following symptoms
> {noformat}
> 2: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':packaging-java-client:distZip'.
> > Could not resolve all files for configuration
> > ':packaging-java-client:javaClient'.
> > Could not resolve com.github.ben-manes.caffeine:caffeine:3.0.4.
> Required by:
> project :packaging-java-client > project :ignite-client > project
> :ignite-marshaller-common
> > The consumer was configured to find attribute
> 'org.gradle.jvm.environment' with value 'standard-jvm'. However we cannot
> choose between the following variants of
> com.github.ben-manes.caffeine:caffeine:3.0.4:
> - apiElements
> - javadocElements
> - runtimeElements
> - shadowRuntimeElements
> - sourcesElements
> All of them match the consumer attributes:
> - Variant 'apiElements' capability
> com.github.ben-manes.caffeine:caffeine:3.0.4:
> - Unmatched attributes:
> - Provides org.gradle.category 'library' but the consumer
> didn't ask for it
> - Provides org.gradle.dependency.bundling 'external' but
> the consumer didn't ask for it
> - Doesn't say anything about org.gradle.jvm.environment
> (required 'standard-jvm')
> - Provides org.gradle.jvm.version '11' but the consumer
> didn't ask for it
> - Provides org.gradle.libraryelements 'jar' but the
> consumer didn't ask for it
> - Provides org.gradle.status 'release' but the consumer
> didn't ask for it
> - Provides org.gradle.usage 'java-api' but the consumer
> didn't ask for it
> - Variant 'javadocElements' capability
> com.github.ben-manes.caffeine:caffeine:3.0.4:
> - Unmatched attributes:
> - Provides org.gradle.category 'documentation' but the
> consumer didn't ask for it
> - Provides org.gradle.dependency.bundling 'external' but
> the consumer didn't ask for it
> - Provides org.gradle.docstype 'javadoc' but the consumer
> didn't ask for it
> - Doesn't say anything about org.gradle.jvm.environment
> (required 'standard-jvm')
> - Provides org.gradle.status 'release' but the consumer
> didn't ask for it
> - Provides org.gradle.usage 'java-runtime' but the consumer
> didn't ask for it
> - Variant 'runtimeElements' capability
> com.github.ben-manes.caffeine:caffeine:3.0.4:
> - Unmatched attributes:
> - Provides org.gradle.category 'library' but the consumer
> didn't ask for it
> - Provides org.gradle.dependency.bundling 'external' but
> the consumer didn't ask for it
> - Doesn't say anything about org.gradle.jvm.environment
> (required 'standard-jvm')
> - Provides org.gradle.jvm.version '11' but the consumer
> didn't ask for it
> - Provides org.gradle.libraryelements 'jar' but the
> consumer didn't ask for it
> - Provides org.gradle.status 'release' but the consumer
> didn't ask for it
> - Provides org.gradle.usage 'java-runtime' but the consumer
> didn't ask for it
> - Variant 'shadowRuntimeElements' capability
> com.github.ben-manes.caffeine:caffeine:3.0.4:
> - Unmatched attributes:
> - Provides org.gradle.category 'library' but the consumer
> didn't ask for it
> - Provides org.gradle.dependency.bundling 'shadowed' but
> the consumer didn't ask for it
> - Doesn't say anything about org.gradle.jvm.environment
> (required 'standard-jvm')
> - Provides org.gradle.libraryelements 'jar' but the
> consumer didn't ask for it
> - Provides org.gradle.status 'release' but the consumer
>
[jira] [Updated] (IGNITE-21700) IgniteSort: result of RelOptCost.plus is ignored but it doesn't have side-effects
[
https://issues.apache.org/jira/browse/IGNITE-21700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21700:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> IgniteSort: result of RelOptCost.plus is ignored but it doesn't have
> side-effects
> -
>
> Key: IGNITE-21700
> URL: https://issues.apache.org/jira/browse/IGNITE-21700
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
> Fix For: 3.0.0-beta2
>
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> H D RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT RV: Return value of
> org.apache.calcite.plan.RelOptCost.plus(RelOptCost) ignored, but method has
> no side effect At IgniteSort.java:[line 169] {noformat}
> It looks like RelOptCost.plus is side-effect free and it's return result
> should be used, but it is ignored! It looks like a bug!
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21693) TxManagerImpl increments/decrements volatile field `inflights`
[
https://issues.apache.org/jira/browse/IGNITE-21693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21693:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> TxManagerImpl increments/decrements volatile field `inflights`
> --
>
> Key: IGNITE-21693
> URL: https://issues.apache.org/jira/browse/IGNITE-21693
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> H M VO_VOLATILE_INCREMENT VO: Increment of volatile field
> org.apache.ignite.internal.tx.impl.TxManagerImpl$TxContext.inflights in
> org.apache.ignite.internal.tx.impl.TxManagerImpl.lambda$addInflight$21(boolean[],
> UUID, TxManagerImpl$TxContext) At TxManagerImpl.java:[line 843]
> H M VO_VOLATILE_INCREMENT VO: Increment of volatile field
> org.apache.ignite.internal.tx.impl.TxManagerImpl$TxContext.inflights in
> org.apache.ignite.internal.tx.impl.TxManagerImpl.lambda$removeInflight$22(UUID,
> TxManagerImpl$TxContext) At TxManagerImpl.java:[line 858]
> {noformat}
> Increments/Decrements of volatile fields aren't atomic. If more than one
> thread is incrementing/decrementing the field at the same time,
> increments/decrements could be lost.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21710) ItIndexAndRebalanceTest.testChangeReplicaCountWithoutRestartNodes fails with Could not wait for the replica readiness due to timeout [replicaGroupId=7_part_0, req=Read
[ https://issues.apache.org/jira/browse/IGNITE-21710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21710: - Labels: ignite-3 (was: ) > ItIndexAndRebalanceTest.testChangeReplicaCountWithoutRestartNodes fails with > Could not wait for the replica readiness due to timeout > [replicaGroupId=7_part_0, req=ReadWriteSingleRowReplicaRequestImpl] > - > > Key: IGNITE-21710 > URL: https://issues.apache.org/jira/browse/IGNITE-21710 > 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] [Updated] (IGNITE-21705) CheckpointWorkflow uses weird equals implementation
[
https://issues.apache.org/jira/browse/IGNITE-21705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21705:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> CheckpointWorkflow uses weird equals implementation
> ---
>
> Key: IGNITE-21705
> URL: https://issues.apache.org/jira/browse/IGNITE-21705
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M B BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS BC: Equals method for
> org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointWorkflow$1
> assumes the argument is of type CheckpointWorkflow$1 At
> CheckpointWorkflow.java:[line 349]
> M B NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT NP:
> org.apache.ignite.internal.pagememory.persistence.checkpoint.CheckpointWorkflow$1.equals(Object)
> does not check for null argument At CheckpointWorkflow.java:[line 349]
> {noformat}
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21703) Sql. IgniteSqlFunctions.octetLength relies on default encoding
[
https://issues.apache.org/jira/browse/IGNITE-21703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21703:
-
Labels: ignite-3 (was: ignite3)
> Sql. IgniteSqlFunctions.octetLength relies on default encoding
> --
>
> Key: IGNITE-21703
> URL: https://issues.apache.org/jira/browse/IGNITE-21703
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> H I DM_DEFAULT_ENCODING Dm: Found reliance on default encoding in
> org.apache.ignite.internal.sql.engine.exec.exp.IgniteSqlFunctions.octetLength(String):
> String.getBytes() At IgniteSqlFunctions.java:[line 133]
> {noformat}
> It looks like a potential bug if system default encoding will be something
> exotic.
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21702) AbstractNode field `inBufSize` is unused
[
https://issues.apache.org/jira/browse/IGNITE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21702:
-
Labels: ignite-3 (was: ignite3)
> AbstractNode field `inBufSize` is unused
>
>
> Key: IGNITE-21702
> URL: https://issues.apache.org/jira/browse/IGNITE-21702
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M P SS_SHOULD_BE_STATIC SS: Unread field:
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.inBufSize; should
> this field be static? At AbstractNode.java:[line 39] {noformat}
> It looks like this field is just useless.
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21704) ConfigurationListenerHolder uses weird equals implementation
[
https://issues.apache.org/jira/browse/IGNITE-21704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21704:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> ConfigurationListenerHolder uses weird equals implementation
>
>
> Key: IGNITE-21704
> URL: https://issues.apache.org/jira/browse/IGNITE-21704
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M B BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS BC: Equals method for
> org.apache.ignite.internal.configuration.ConfigurationListenerHolder$1
> assumes the argument is of type ConfigurationListenerHolder$1 At
> ConfigurationListenerHolder.java:[line 56]
> M B NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT NP:
> org.apache.ignite.internal.configuration.ConfigurationListenerHolder$1.equals(Object)
> does not check for null argument At ConfigurationListenerHolder.java:[line
> 56]{noformat}
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21706) RandomLruPageReplacementPolicy has dead conditions
[
https://issues.apache.org/jira/browse/IGNITE-21706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21706:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> RandomLruPageReplacementPolicy has dead conditions
> --
>
> Key: IGNITE-21706
> URL: https://issues.apache.org/jira/browse/IGNITE-21706
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> H D UC_USELESS_CONDITION UC: Useless condition: it's known that dirty ==
> false at this point At RandomLruPageReplacementPolicy.java:[line 134]
> {noformat}
> I tried to unfold it and ended up removing quite a few lines of dead code and
> useless conditions which are constant. I'm not sure if this is right and
> there is no missing implementation there.
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21701) Sql. IgniteSender compares unrelated types
[
https://issues.apache.org/jira/browse/IGNITE-21701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21701:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> Sql. IgniteSender compares unrelated types
> --
>
> Key: IGNITE-21701
> URL: https://issues.apache.org/jira/browse/IGNITE-21701
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M C EC_UNRELATED_TYPES_USING_POINTER_EQUALITY EC: Using pointer equality to
> compare a org.apache.calcite.rel.RelDistributions$RelDistributionImpl with a
> org.apache.ignite.internal.sql.engine.trait.IgniteDistribution in new
> org.apache.ignite.internal.sql.engine.rel.IgniteSender(RelOptCluster,
> RelTraitSet, RelNode, long, long, IgniteDistribution) At
> IgniteSender.java:[line 58]
> {noformat}
> It looks like a bug because this comparsion will always yield false!
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21698) LocalConfigurationStorage reboxes unboxed value
[
https://issues.apache.org/jira/browse/IGNITE-21698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21698:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> LocalConfigurationStorage reboxes unboxed value
> ---
>
> Key: IGNITE-21698
> URL: https://issues.apache.org/jira/browse/IGNITE-21698
> Project: Ignite
> Issue Type: Task
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M P BX_UNBOXING_IMMEDIATELY_REBOXED Bx: Boxed value is unboxed and then
> immediately reboxed in
> org.apache.ignite.internal.configuration.storage.LocalConfigurationStorage.lambda$lastRevision$6()
> At LocalConfigurationStorage.java:[line 232] {noformat}
> This might cause unwanted additional GC pressure.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21699) Sql. DistributionFunction compares strings by reference
[
https://issues.apache.org/jira/browse/IGNITE-21699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21699:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> Sql. DistributionFunction compares strings by reference
> ---
>
> Key: IGNITE-21699
> URL: https://issues.apache.org/jira/browse/IGNITE-21699
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M B ES_COMPARING_STRINGS_WITH_EQ ES: Comparison of String objects using == or
> != in
> org.apache.ignite.internal.sql.engine.trait.DistributionFunction.equals(Object)
> At DistributionFunction.java:[line 76]
> M B ES_COMPARING_STRINGS_WITH_EQ ES: Comparison of String objects using == or
> != in
> org.apache.ignite.internal.sql.engine.trait.DistributionFunction.satisfy(DistributionFunction,
> DistributionFunction) At DistributionFunction.java:[line 117]
> {noformat}
> This might be wrong.
> Investigate whenever this is a false-positive and we should suppress it, or
> make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21696) LazyStripedExecutor performs synchronization on AtomicReferenceArray
[
https://issues.apache.org/jira/browse/IGNITE-21696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21696:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> LazyStripedExecutor performs synchronization on AtomicReferenceArray
>
>
> Key: IGNITE-21696
> URL: https://issues.apache.org/jira/browse/IGNITE-21696
> Project: Ignite
> Issue Type: Task
>Reporter: Viacheslav Blinov
>Assignee: Roman Puchkovskiy
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M M JLM_JSR166_UTILCONCURRENT_MONITORENTER JLM: Synchronization performed on
> java.util.concurrent.atomic.AtomicReferenceArray in
> org.apache.ignite.internal.network.LazyStripedExecutors.stripedExecutorFor(short)
> At LazyStripedExecutors.java:[line 71]
> {noformat}
> Instances of java.util.concurrent.atomic classes have their own concurrency
> control mechanisms that are orthogonal to the synchronization provided by the
> Java keyword {{{}synchronized{}}}. For example, synchronizing on an
> {{AtomicBoolean}} will not prevent other threads from modifying the
> {{{}AtomicBoolean{}}}.
> Such code may be correct, but should be carefully reviewed and documented,
> and may confuse people who have to maintain the code at a later date.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21697) ConnectionManager ignores exceptional return value of ExecutorService.submit
[
https://issues.apache.org/jira/browse/IGNITE-21697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21697:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> ConnectionManager ignores exceptional return value of ExecutorService.submit
>
>
> Key: IGNITE-21697
> URL: https://issues.apache.org/jira/browse/IGNITE-21697
> Project: Ignite
> Issue Type: Task
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M B RV_RETURN_VALUE_IGNORED_BAD_PRACTICE RV: Exceptional return value of
> java.util.concurrent.ExecutorService.submit(Callable) ignored in
> org.apache.ignite.internal.network.netty.ConnectionManager.handleNodeLeft(String)
> At ConnectionManager.java:[line 603]
> {noformat}
> If you don't check the result, you won't notice if the method invocation
> signals unexpected behavior by returning an atypical return value.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21695) PageHandler: useless control flow
[
https://issues.apache.org/jira/browse/IGNITE-21695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21695:
-
Labels: ignite-3 spotbus (was: ignite3 spotbus)
> PageHandler: useless control flow
> -
>
> Key: IGNITE-21695
> URL: https://issues.apache.org/jira/browse/IGNITE-21695
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbus
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M D UCF_USELESS_CONTROL_FLOW UCF: Useless control flow in
> org.apache.ignite.internal.pagememory.util.PageHandler. for PageHandler>() At PageHandler.java:[line 34]
> {noformat}
> One of the conditions of this interface default implementation checks for
> condition which is always true/false. This can be a sign of a bug.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21694) HeapLockManager/HeapUnboundedLockManager makes inefficient use of keySet iterator instead of entrySet iterator
[
https://issues.apache.org/jira/browse/IGNITE-21694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21694:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> HeapLockManager/HeapUnboundedLockManager makes inefficient use of keySet
> iterator instead of entrySet iterator
> --
>
> Key: IGNITE-21694
> URL: https://issues.apache.org/jira/browse/IGNITE-21694
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M P WMI_WRONG_MAP_ITERATOR WMI:
> org.apache.ignite.internal.tx.impl.HeapLockManager$WaiterImpl.recalculate()
> makes inefficient use of keySet iterator instead of entrySet iterator At
> HeapLockManager.java:[line 815]
> M P WMI_WRONG_MAP_ITERATOR WMI:
> org.apache.ignite.internal.tx.impl.HeapUnboundedLockManager$WaiterImpl.recalculate()
> makes inefficient use of keySet iterator instead of entrySet iterator At
> HeapUnboundedLockManager.java:[line 632] {noformat}
> This method accesses the value of a Map entry, using a key that was retrieved
> from a keySet iterator. It is more efficient to use an iterator on the
> entrySet of the map, to avoid the Map.get(key) lookup.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21692) AbstractFreeList has unused private method `initReusedPage`
[
https://issues.apache.org/jira/browse/IGNITE-21692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21692:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> AbstractFreeList has unused private method `initReusedPage`
> ---
>
> Key: IGNITE-21692
> URL: https://issues.apache.org/jira/browse/IGNITE-21692
> Project: Ignite
> Issue Type: Task
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs but is also highlighted by Idea inspection.
> Specifically the warning reported is:
> {noformat}
> M P UPM_UNCALLED_PRIVATE_METHOD UPM: Private method
> org.apache.ignite.internal.pagememory.freelist.AbstractFreeList.initReusedPage(Storable,
> long, IoStatisticsHolder) is never called At AbstractFreeList.java:[lines
> 707-726]
> {noformat}
> Method `initReusedPage` is never called which can be an indicator of an issue.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21691) BasicMetricExporter has inconsistent synchronized access to field `configuration`
[
https://issues.apache.org/jira/browse/IGNITE-21691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21691:
-
Labels: ignite-3 spotbugs (was: ignite3 spotbugs)
> BasicMetricExporter has inconsistent synchronized access to field
> `configuration`
> -
>
> Key: IGNITE-21691
> URL: https://issues.apache.org/jira/browse/IGNITE-21691
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs but is also highlighted by Idea inspection.
> Specifically the warning reported is:
> {noformat}
> M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of
> org.apache.ignite.internal.metrics.exporters.BasicMetricExporter.configuration;
> locked 66% of time Unsynchronized access at BasicMetricExporter.java:[line
> 41]
> {noformat}
> Field `configuration` are accessed in both synchronized and unsynchronized
> fashion. This can be a source of hard to catch bug.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21690) ConfigurationNode has inconsistent synchronized access to fields `invalid` and `val`
[
https://issues.apache.org/jira/browse/IGNITE-21690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21690:
-
Labels: ignite-3 ignite3 spotbugs (was: ignite3 spotbugs)
> ConfigurationNode has inconsistent synchronized access to fields `invalid`
> and `val`
>
>
> Key: IGNITE-21690
> URL: https://issues.apache.org/jira/browse/IGNITE-21690
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, ignite3, spotbugs
>
> Issue detected by SpotBugs but is also highlighted by Idea inspection.
> Specifically the warning reported is:
> {noformat}
> M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of
> org.apache.ignite.internal.configuration.ConfigurationNode.invalid; locked
> 66% of time Unsynchronized access at ConfigurationNode.java:[line
> 138]{noformat}
> {noformat}
> M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of
> org.apache.ignite.internal.configuration.ConfigurationNode.val; locked 60% of
> time Unsynchronized access at ConfigurationNode.java:[line 145]{noformat}
> Fields `val` and `invalid` are accessed in both synchronized and
> unsynchronized fashion. This can be a source of hard to catch bug.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21690) ConfigurationNode has inconsistent synchronized access to fields `invalid` and `val`
[
https://issues.apache.org/jira/browse/IGNITE-21690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21690:
-
Labels: ignite-3 spotbugs (was: ignite-3 ignite3 spotbugs)
> ConfigurationNode has inconsistent synchronized access to fields `invalid`
> and `val`
>
>
> Key: IGNITE-21690
> URL: https://issues.apache.org/jira/browse/IGNITE-21690
> Project: Ignite
> Issue Type: Bug
>Reporter: Viacheslav Blinov
>Priority: Major
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs but is also highlighted by Idea inspection.
> Specifically the warning reported is:
> {noformat}
> M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of
> org.apache.ignite.internal.configuration.ConfigurationNode.invalid; locked
> 66% of time Unsynchronized access at ConfigurationNode.java:[line
> 138]{noformat}
> {noformat}
> M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of
> org.apache.ignite.internal.configuration.ConfigurationNode.val; locked 60% of
> time Unsynchronized access at ConfigurationNode.java:[line 145]{noformat}
> Fields `val` and `invalid` are accessed in both synchronized and
> unsynchronized fashion. This can be a source of hard to catch bug.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21689) Correct CI jobs to remove modernizer calls
[ https://issues.apache.org/jira/browse/IGNITE-21689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21689: - Labels: ignite-3 (was: ignite3) > Correct CI jobs to remove modernizer calls > -- > > Key: IGNITE-21689 > URL: https://issues.apache.org/jira/browse/IGNITE-21689 > Project: Ignite > Issue Type: Task >Reporter: Viacheslav Blinov >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > Before merging IGNITE-21688 we should remove modernizer usage from our CI > pipelines -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21688) Remove Modernizer from gradle build
[ https://issues.apache.org/jira/browse/IGNITE-21688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21688: - Labels: ignite-3 (was: ignite3) > Remove Modernizer from gradle build > --- > > Key: IGNITE-21688 > URL: https://issues.apache.org/jira/browse/IGNITE-21688 > Project: Ignite > Issue Type: Task >Reporter: Viacheslav Blinov >Assignee: Viacheslav Blinov >Priority: Major > Labels: ignite-3 > > After IGNITE-21569 is implemented all existing modernizer rules will be > covered by Spotbugs. Let's get rid of modernizer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21666) Define base events
[ https://issues.apache.org/jira/browse/IGNITE-21666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21666: - Labels: ignite-3 (was: ) > Define base events > -- > > Key: IGNITE-21666 > URL: https://issues.apache.org/jira/browse/IGNITE-21666 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > The base events should be defined with fields: > - EventType > - User > - Time > - Type-specific fields > Also two event types are defined in this ticket: CONNECTION_ESTABLISHED, > CONNECTION_CLOSED. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21650) Extend PMD ruleset to check known performance and multithreading issues
[ https://issues.apache.org/jira/browse/IGNITE-21650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21650: - Labels: ignite-3 (was: ) > Extend PMD ruleset to check known performance and multithreading issues > --- > > Key: IGNITE-21650 > URL: https://issues.apache.org/jira/browse/IGNITE-21650 > Project: Ignite > Issue Type: Improvement >Reporter: Viacheslav Blinov >Assignee: Viacheslav Blinov >Priority: Major > Labels: ignite-3 > > See > [https://pmd.sourceforge.io/pmd-6.50.0/pmd_rules_java_performance.html] > and > https://pmd.sourceforge.io/pmd-6.50.0/pmd_rules_java_multithreading.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21665) Implement EventLog
[ https://issues.apache.org/jira/browse/IGNITE-21665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21665: - Labels: ignite-3 (was: ) > Implement EventLog > -- > > Key: IGNITE-21665 > URL: https://issues.apache.org/jira/browse/IGNITE-21665 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Given FileSink and CONNECTION_ESTABLISHED/CONNECTION_CLOSED events > implemented we have to be able to configure a channel for it with > CONNECTION_ESTABLISHED and CONNECTION_CLOSED events. Besides the > configuration the EventLog itself should be implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21657) Sql. SqlTestUtils::assertThrowsSqlException reports misleading error message
[ https://issues.apache.org/jira/browse/IGNITE-21657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21657: - Labels: ignite-3 (was: ) > Sql. SqlTestUtils::assertThrowsSqlException reports misleading error message > > > Key: IGNITE-21657 > URL: https://issues.apache.org/jira/browse/IGNITE-21657 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Trivial > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > The condition in error reporting is misleading, it should display a error > message when a message does not match, but it displays error codes (which > match). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21644: - Labels: ignite-3 (was: ) > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another batch and compose it with the first CompletableFuture with: > f.thenCompose(r -> view.putAllAsync(null, newBatch)); > Expected behavior: batch completed sucessfully. > Actual behavior: Failed to acquire a lock due to a possible deadlock -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21622) Add .editorconfig to the repo
[ https://issues.apache.org/jira/browse/IGNITE-21622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21622: - Labels: ignite-3 (was: ) > Add .editorconfig to the repo > - > > Key: IGNITE-21622 > URL: https://issues.apache.org/jira/browse/IGNITE-21622 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Sometimes I see missing EOF in the PR. I would like to add an .editorconfig > to the repo in order to avoid mentioning in everytime in PR. > https://editorconfig.org > - collect useful options in .editorconfig that will speedup a review process > - present them to the community > - integrate the config into repository > - write documentation if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21460) Add an ability to specify ignored failure types
[
https://issues.apache.org/jira/browse/IGNITE-21460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21460:
-
Fix Version/s: 3.0.0-beta2
> Add an ability to specify ignored failure types
> ---
>
> Key: IGNITE-21460
> URL: https://issues.apache.org/jira/browse/IGNITE-21460
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Motivation:
> It would be useful to introduce customized ignored failure types. The failure
> handler should be able to ignore some failures (just log a message) and not
> trigger node stopping. For example, long-running tasks in a critical worker
> might not be a reason for node stopping.
> Definition of done:
> The following two methods should be added to the FailureHandler interface:
> {code:java}
> /**
> * Sets failure types that must be ignored by failure handler.
> *
> * @param failureTypes Set of failure type that must be ignored.
> * @see FailureType
> */
> public void setIgnoredFailureTypes(Set failureTypes);
> /**
> * Returns unmodifiable set of ignored failure types.
> */
> public Set getIgnoredFailureTypes(); {code}
> Processing a failure from the list of ignored failure types should lead to
> logging a corresponding message and should not trigger node stopping.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-16899) Implement node failure process
[ https://issues.apache.org/jira/browse/IGNITE-16899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-16899. -- Resolution: Duplicate It was done under IGNITE-20452 > Implement node failure process > -- > > Key: IGNITE-16899 > URL: https://issues.apache.org/jira/browse/IGNITE-16899 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > Similar to 2.0, we need to implement a node failure process, that describe in > [IEP-14|https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21459) Implement NoOpFailure processor for testing purposes
[ https://issues.apache.org/jira/browse/IGNITE-21459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-21459. -- Resolution: Duplicate It was done under IGNITE-20452 > Implement NoOpFailure processor for testing purposes > > > Key: IGNITE-21459 > URL: https://issues.apache.org/jira/browse/IGNITE-21459 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21460) Add an ability to specify ignored failure types
[
https://issues.apache.org/jira/browse/IGNITE-21460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-21460:
Assignee: Vyacheslav Koptilin
> Add an ability to specify ignored failure types
> ---
>
> Key: IGNITE-21460
> URL: https://issues.apache.org/jira/browse/IGNITE-21460
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Motivation:
> It would be useful to introduce customized ignored failure types. The failure
> handler should be able to ignore some failures (just log a message) and not
> trigger node stopping. For example, long-running tasks in a critical worker
> might not be a reason for node stopping.
> Definition of done:
> The following two methods should be added to the FailureHandler interface:
> {code:java}
> /**
> * Sets failure types that must be ignored by failure handler.
> *
> * @param failureTypes Set of failure type that must be ignored.
> * @see FailureType
> */
> public void setIgnoredFailureTypes(Set failureTypes);
> /**
> * Returns unmodifiable set of ignored failure types.
> */
> public Set getIgnoredFailureTypes(); {code}
> Processing a failure from the list of ignored failure types should lead to
> logging a corresponding message and should not trigger node stopping.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21559) Sql. Implement expression traversal that checks whether expression is deterministic
[ https://issues.apache.org/jira/browse/IGNITE-21559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21559: - Labels: ignite-3 (was: ) > Sql. Implement expression traversal that checks whether expression is > deterministic > --- > > Key: IGNITE-21559 > URL: https://issues.apache.org/jira/browse/IGNITE-21559 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Let's implement a utility for determining whether an expression tree > (RexNodes) is deterministic or not. > Expression is deterministic if it is constant expression, dynamic parameter, > or a function like CURRENT_TIMESTAMP is evaluated once per session, or > deterministic function. > Non deterministic functions in AI-3: GEN_RANDOM_UUID. > Check to see if there are any other non-deterministic functions as well and > mark them accordingly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21530) Investigations
[ https://issues.apache.org/jira/browse/IGNITE-21530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21530: - Labels: ignite-3 (was: ) > Investigations > -- > > Key: IGNITE-21530 > URL: https://issues.apache.org/jira/browse/IGNITE-21530 > Project: Ignite > Issue Type: Wish >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21541) Avoid partition-operations pool when it not lead to starvation
[
https://issues.apache.org/jira/browse/IGNITE-21541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-21541:
Assignee: Vladislav Pyatkov
> Avoid partition-operations pool when it not lead to starvation
> --
>
> Key: IGNITE-21541
> URL: https://issues.apache.org/jira/browse/IGNITE-21541
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Chnaging pools and related parking/unparking lead to an increase in latency.
> Sometimes we can avoid extra pool changing, for example, by doing it for
> embedded operations.
> {code:title=ReplicaManager#onReplicaMessageReceived}
> ExecutorService stripeExecutor =
> ReplicationGroupStripes.stripeFor(request.groupId(), requestsExecutor);
> stripeExecutor.execute(() -> handleReplicaRequest(request,
> senderConsistentId, correlationId));
> {code}
> This code changes a thread, even if it is not necessary.
> h3. Definition of done
> ReplicaManager should not switch threads if it does not lead to starvation
> (in my opinion, the splitting is needed only in the case of the network
> thread).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21540) Handle lock exception for transaction operations
[ https://issues.apache.org/jira/browse/IGNITE-21540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-21540: Assignee: Vladislav Pyatkov > Handle lock exception for transaction operations > > > Key: IGNITE-21540 > URL: https://issues.apache.org/jira/browse/IGNITE-21540 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Deadlock prevention can throw a lock exception, but it depends on the > situation. After several retries, the exception might pass because another > transaction has already released its locks. > h3. Implementation notes > We need to consider all kinds of implicit operations that lead to the > creation of RW transactions. > h3. Definition of done > Implicit operations never throw the lock exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18991) Move stable/planned/pending assignments from table to distribution zone root keys
[ https://issues.apache.org/jira/browse/IGNITE-18991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-18991: Assignee: Mirza Aliev (was: Kirill Gusakov) > Move stable/planned/pending assignments from table to distribution zone root > keys > - > > Key: IGNITE-18991 > URL: https://issues.apache.org/jira/browse/IGNITE-18991 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Time Spent: 50m > Remaining Estimate: 0h > > Under the activities about moving distribution zone based data management we > need to: > * Replace metastore stable/planned/pending assignments per table by the same > per distribution zone with the correspondance keys roots zoneId.* > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21545) Introduce a cursor manager
[ https://issues.apache.org/jira/browse/IGNITE-21545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-21545: Assignee: Kirill Sizov (was: Denis Chudov) > Introduce a cursor manager > -- > > Key: IGNITE-21545 > URL: https://issues.apache.org/jira/browse/IGNITE-21545 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > Time Spent: 40m > Remaining Estimate: 0h > > Introduce a cursor manager that would maintain all cursors created on a node, > instead of maintaining them in partition replica listeners. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21500) Retry implicit transactions when primary replica failed or moved
[ https://issues.apache.org/jira/browse/IGNITE-21500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21500: - Epic Link: IGNITE-21174 > Retry implicit transactions when primary replica failed or moved > > > Key: IGNITE-21500 > URL: https://issues.apache.org/jira/browse/IGNITE-21500 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation* > Implicit transactions are created without a transaction from the client point > of view (the transaction is created inside the library and is not exposed > outside). > A failure to execute such transaction because of the primary replica related > exceptions (PrimaryReplicaMissException, etc.). should not result in the > users seeing them. > Instead, retrying these transactions will likely to succeed. > *Definition of done* > An implicit transaction that failed to execute because of > PrimaryReplicaMissException, PrimaryReplicaAwaitException, > TransactionExceptions with messages like "Failed to get the primary replica", > "Failed to resolve the primary replica node" > should be retried. > If it is not possible to await for the primary replica, the transaction will > fail. The primary replica failure exceptions are not propagated to the users > in cases of implicit transactions - a different exception is thrown instead. > *Implementation detail* > There might be some difficulties with implicit scan and implicit direct RO > transactions. No issues with plain implicit RW transactions is expected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21540) Unexpected lock exception in implicit operation
[ https://issues.apache.org/jira/browse/IGNITE-21540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21540: - Epic Link: IGNITE-21174 > Unexpected lock exception in implicit operation > --- > > Key: IGNITE-21540 > URL: https://issues.apache.org/jira/browse/IGNITE-21540 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Implicit operations create a transaction under the hood, and the transaction > may be in conflict with another one. This type of transaction can be > automatically retried because it does not contain user logic. > h3. Implementation notes > We need to consider all kinds of implicit operations that lead to the > creation of RW transactions. > h3. Definition of done > Implicit operations never throw the lock exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21540) Unexpected lock exception in implicit operation
[ https://issues.apache.org/jira/browse/IGNITE-21540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21540: - Ignite Flags: (was: Docs Required,Release Notes Required) > Unexpected lock exception in implicit operation > --- > > Key: IGNITE-21540 > URL: https://issues.apache.org/jira/browse/IGNITE-21540 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Implicit operations create a transaction under the hood, and the transaction > may be in conflict with another one. This type of transaction can be > automatically retried because it does not contain user logic. > h3. Implementation notes > We need to consider all kinds of implicit operations that lead to the > creation of RW transactions. > h3. Definition of done > Implicit operations never throw the lock exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21540) Unexpected lock exception in implicit operation
[ https://issues.apache.org/jira/browse/IGNITE-21540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21540: - Description: h3. Motivation Implicit operations create a transaction under the hood, and the transaction may be in conflict with another one. This type of transaction can be automatically retried because it does not contain user logic. h3. Implementation notes We need to consider all kinds of implicit operations that lead to the creation of RW transactions. h3. Definition of done Implicit operations never throw the lock exception. was: h3. Motivation Implicit operations create a transaction under the hook, and the transaction may be in conflict with another one. This type of transaction can be automatically retried because it does not contain user logic. h3. Implementation notes We need to consider all kinds of implicit operations that lead to the creation of RW transactions. h3. Definition of done Implicit operations never throw the lock exception. > Unexpected lock exception in implicit operation > --- > > Key: IGNITE-21540 > URL: https://issues.apache.org/jira/browse/IGNITE-21540 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Implicit operations create a transaction under the hood, and the transaction > may be in conflict with another one. This type of transaction can be > automatically retried because it does not contain user logic. > h3. Implementation notes > We need to consider all kinds of implicit operations that lead to the > creation of RW transactions. > h3. Definition of done > Implicit operations never throw the lock exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21484) Possible race in JobExecution.changePriority method
[ https://issues.apache.org/jira/browse/IGNITE-21484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21484: - Labels: ignite-3 (was: ) > Possible race in JobExecution.changePriority method > --- > > Key: IGNITE-21484 > URL: https://issues.apache.org/jira/browse/IGNITE-21484 > Project: Ignite > Issue Type: Bug > Components: compute >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Assignee: Dmitry Baranov >Priority: Major > Labels: ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > In > [https://github.com/apache/ignite-3/blob/6729811f99ad18b1490f9b7516a2af84a898e7af/modules/compute/src/main/java/org/apache/ignite/internal/compute/queue/QueueExecutionImpl.java#L115] > race is possible. > thread 1: remove task from the queue > thread 2: haven't found the same task in the queue because it is not added > yet by thread 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21391:
-
Description:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
the appropariate line of code with fail
[https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570]
{code:java}
cluster.ensureSame();{code}
Didn't manage to reproduce the issue locally, however there are several
failures in TC with same reason.
was:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
the appropariate line of code with fail
https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570
{code:java}
cluster.ensureSame();{code}
Didn't manage to reproduce the issue locally, however there are several
failures in TC with same reason.
> ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
> ---
>
> Key: IGNITE-21391
> URL: https://issues.apache.org/jira/browse/IGNITE-21391
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Attachments: test.log
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
> the appropariate line of code with fail
> [https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570]
> {code:java}
> cluster.ensureSame();{code}
> Didn't manage to reproduce the issue locally, however there are several
> failures in TC with same reason.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21391) ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21391:
-
Description:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
the appropariate line of code with fail
[https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570]
{code:java}
cluster.ensureSame();{code}
Didn't manage to reproduce the issue locally, however, there are several
failures in TC with same reason.
was:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was:
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
at
app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
at
app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
the appropariate line of code with fail
[https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570]
{code:java}
cluster.ensureSame();{code}
Didn't manage to reproduce the issue locally, however there are several
failures in TC with same reason.
> ItNodeTest#testAppendEntriesWhenFollowerIsInErrorState is flaky
> ---
>
> Key: IGNITE-21391
> URL: https://issues.apache.org/jira/browse/IGNITE-21391
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Attachments: test.log
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:558)
> at
> app//org.apache.ignite.raft.jraft.core.TestCluster.ensureSame(TestCluster.java:530)
> at
> app//org.apache.ignite.raft.jraft.core.ItNodeTest.testAppendEntriesWhenFollowerIsInErrorState(ItNodeTest.java:2568){code}
> the appropariate line of code with fail
> [https://github.com/apache/ignite-3/blob/f3e9af88192f5aea41a3f6a8d4cac2c891141205/modules/raft/src/integrationTest/java/org/apache/ignite/raft/jraft/core/ItNodeTest.java#L2570]
> {code:java}
> cluster.ensureSame();{code}
> Didn't manage to reproduce the issue locally, however, there are several
> failures in TC with same reason.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-16184) testTransferLeader is flaky
[ https://issues.apache.org/jira/browse/IGNITE-16184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-16184. -- Resolution: Cannot Reproduce > testTransferLeader is flaky > --- > > Key: IGNITE-16184 > URL: https://issues.apache.org/jira/browse/IGNITE-16184 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Priority: Blocker > Labels: ignite-3 > Attachments: testTransferLeader.log > > > ItCliServiceTest.testTransferLeader is flaky. Need to find out the root cause. > See attached log. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21507) Improve test coverege for colocation functionality
[ https://issues.apache.org/jira/browse/IGNITE-21507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21507: - Description: During implementation of IGNITE-16603 were added set of tests. However added set of tests is insufficient. Let's increase testc coverage for the following test cases: Integration tests: * Ensure colocation columns order leads to different distributions. * Ensure SQL JOIN on all the colocation columns leads to a plan with non-distributive join operation. * Ensure compute affinityCall always runs on the affinity node. * Failover Testing: * Ensures colocation columns information survives grid restart. # Start a cluster. # Create a table with colocated columns specified. # Restart the cluster. # Check a Catalog table descriptor still contains colocation columns. was: During implementation of IGNITE-16603 were added set of tests. However added set of tests is insufficient. Let's increase testc coverage for the following test cases: Integration tests: * Ensure colocation columns order leads to different distributions. * Ensure SQL JOIN on all the colocation columns leads to a plan with non-distributive join operation. * Ensure compute affinityCall always runs on the affinity node. Failover Testing: * Ensures colocation columns information survives grid restart. # Start a cluster. # Create a table with colocated columns specified. # Restart the cluster. # Check a Catalog table descriptor still contains colocation columns. > Improve test coverege for colocation functionality > -- > > Key: IGNITE-21507 > URL: https://issues.apache.org/jira/browse/IGNITE-21507 > Project: Ignite > Issue Type: Improvement >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > During implementation of IGNITE-16603 were added set of tests. However added > set of tests is insufficient. Let's increase testc coverage for the following > test cases: > Integration tests: > * Ensure colocation columns order leads to different distributions. > * Ensure SQL JOIN on all the colocation columns leads to a plan with > non-distributive join operation. > * Ensure compute affinityCall always runs on the affinity node. > * > Failover Testing: > * Ensures colocation columns information survives grid restart. > # Start a cluster. > # Create a table with colocated columns specified. > # Restart the cluster. > # Check a Catalog table descriptor still contains colocation columns. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21507) Improve test coverege for colocation functionality
[ https://issues.apache.org/jira/browse/IGNITE-21507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21507: - Description: During implementation of IGNITE-16603 were added set of tests. However added set of tests is insufficient. Let's increase testc coverage for the following test cases: Integration tests: * Ensure colocation columns order leads to different distributions. * Ensure SQL JOIN on all the colocation columns leads to a plan with non-distributive join operation. * Ensure compute affinityCall always runs on the affinity node. * Failover Testing: * Ensures colocation column information survives grid restart. # Start a cluster. # Create a table with colocated columns specified. # Restart the cluster. # Check a Catalog table descriptor still contains colocation columns. was: During implementation of IGNITE-16603 were added set of tests. However added set of tests is insufficient. Let's increase testc coverage for the following test cases: Integration tests: * Ensure colocation columns order leads to different distributions. * Ensure SQL JOIN on all the colocation columns leads to a plan with non-distributive join operation. * Ensure compute affinityCall always runs on the affinity node. * Failover Testing: * Ensures colocation columns information survives grid restart. # Start a cluster. # Create a table with colocated columns specified. # Restart the cluster. # Check a Catalog table descriptor still contains colocation columns. > Improve test coverege for colocation functionality > -- > > Key: IGNITE-21507 > URL: https://issues.apache.org/jira/browse/IGNITE-21507 > Project: Ignite > Issue Type: Improvement >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > During implementation of IGNITE-16603 were added set of tests. However added > set of tests is insufficient. Let's increase testc coverage for the following > test cases: > Integration tests: > * Ensure colocation columns order leads to different distributions. > * Ensure SQL JOIN on all the colocation columns leads to a plan with > non-distributive join operation. > * Ensure compute affinityCall always runs on the affinity node. > * > Failover Testing: > * Ensures colocation column information survives grid restart. > # Start a cluster. > # Create a table with colocated columns specified. > # Restart the cluster. > # Check a Catalog table descriptor still contains colocation columns. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21507) Improve test coverege for colocation functionality
[ https://issues.apache.org/jira/browse/IGNITE-21507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-21507: Assignee: Iurii Gerzhedovich > Improve test coverege for colocation functionality > -- > > Key: IGNITE-21507 > URL: https://issues.apache.org/jira/browse/IGNITE-21507 > Project: Ignite > Issue Type: Improvement >Reporter: Iurii Gerzhedovich >Assignee: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > During implementation of IGNITE-16603 were added set of tests. However added > set of tests is insufficient. Let's increase testc coverage for the following > test cases: > Integration tests: > * Ensure colocation columns order leads to different distributions. > * Ensure SQL JOIN on all the colocation columns leads to a plan with > non-distributive join operation. > * Ensure compute affinityCall always runs on the affinity node. > Failover Testing: > * Ensures colocation columns information survives grid restart. > # Start a cluster. > # Create a table with colocated columns specified. > # Restart the cluster. > # Check a Catalog table descriptor still contains colocation columns. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21280) Add DATA_PAGE_FRAGMENTED_UPDATE_RECORD WAL record type placeholder
[ https://issues.apache.org/jira/browse/IGNITE-21280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815739#comment-17815739 ] Vyacheslav Koptilin edited comment on IGNITE-21280 at 2/8/24 4:14 PM: -- However, I understand your point. There is no need to add such "reserved" wal record types. Perhaps, it makes sense to clearly state in class that any experimental and 3rd party types should use their range that uses ids starting from 100, for example. It will allow us to keep the original types clean and safe. was (Author: slava.koptilin): However, I understand your point. There is no need to add such "reserved" wal record types. Perhaps, it makes sense to clearly state in class that any experimental and 3rd party types should use their range that uses ids starting from 1000, for example. It will allow us to keep the original types clean and safe. > Add DATA_PAGE_FRAGMENTED_UPDATE_RECORD WAL record type placeholder > -- > > Key: IGNITE-21280 > URL: https://issues.apache.org/jira/browse/IGNITE-21280 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Reserve new WAL type for encrypted DATA_PAGE_FRAGMENTED_UPDATE_RECORD record. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17165) ItProjectScanMergeRuleTest fails on Windows platform
[
https://issues.apache.org/jira/browse/IGNITE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17165:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> ItProjectScanMergeRuleTest fails on Windows platform
>
>
> Key: IGNITE-17165
> URL: https://issues.apache.org/jira/browse/IGNITE-17165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Minor
> Labels: ignite-3
>
> The ItProjectScanMergeRuleTest.testProjects fails with the following error
> message:
> {noformat}
> java.lang.AssertionError: Invalid plan:
> IgniteExchange(distribution=[single]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=2.0, cpu=5.0, memory=0.0, io=0.0, network=4.0], id =
> 23507
> IgniteTableScan(table=[[PUBLIC, PRODUCTS]],
> tableId=[feaccfde-5e54-4e25-a911-7f7015c9a81e], tableVer=[1], filters=[>($t0,
> 1)], projects=[[$t1]], requiredColumns=[{2, 5}]): rowcount = 1.0, cumulative
> cost = IgniteCost [rowCount=1.0, cpu=4.0, memory=0.0, io=0.0, network=0.0],
> id = 23504
> Expected: a string contains ".*Ignite(Table|Index)Scan\\(table=\\[\\[PUBLIC,
> PRODUCTS\\]\\], .*requiredColumns=\\[\\{2, 5\\}\\].*"
> but: was "IgniteExchange(distribution=[single]): rowcount = 1.0,
> cumulative cost = IgniteCost [rowCount=2.0, cpu=5.0, memory=0.0, io=0.0,
> network=4.0], id = 23507
> IgniteTableScan(table=[[PUBLIC, PRODUCTS]],
> tableId=[feaccfde-5e54-4e25-a911-7f7015c9a81e], tableVer=[1], filters=[>($t0,
> 1)], projects=[[$t1]], requiredColumns=[{2, 5}]): rowcount = 1.0, cumulative
> cost = IgniteCost [rowCount=1.0, cpu=4.0, memory=0.0, io=0.0, network=0.0],
> id = 23504
> "
> {noformat}
> The root cause is that _QueryChecker_ uses "\n" as a line separator instead
> of "\r\n"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21280) Add DATA_PAGE_FRAGMENTED_UPDATE_RECORD WAL record type placeholder
[ https://issues.apache.org/jira/browse/IGNITE-21280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815739#comment-17815739 ] Vyacheslav Koptilin edited comment on IGNITE-21280 at 2/8/24 3:59 PM: -- However, I understand your point. There is no need to add such "reserved" wal record types. Perhaps, it makes sense to clearly state in class that any experimental and 3rd party types should use their range that uses ids starting from 1000, for example. It will allow us to keep the original types clean and safe. was (Author: slava.koptilin): However, I understand your point. There is no need to add such "reserved" wal record types. Perhaps, it makes sense to clearly state in class that any experimental and 3rd party types should use their range that that uses ids starting from 1000, for example. It will allow us to keep the original types clean and safe. > Add DATA_PAGE_FRAGMENTED_UPDATE_RECORD WAL record type placeholder > -- > > Key: IGNITE-21280 > URL: https://issues.apache.org/jira/browse/IGNITE-21280 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Reserve new WAL type for encrypted DATA_PAGE_FRAGMENTED_UPDATE_RECORD record. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21280) Add DATA_PAGE_FRAGMENTED_UPDATE_RECORD WAL record type placeholder
[ https://issues.apache.org/jira/browse/IGNITE-21280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815739#comment-17815739 ] Vyacheslav Koptilin commented on IGNITE-21280: -- However, I understand your point. There is no need to add such "reserved" wal record types. Perhaps, it makes sense to clearly state in class that any experimental and 3rd party types should use their range that that uses ids starting from 1000, for example. It will allow us to keep the original types clean and safe. > Add DATA_PAGE_FRAGMENTED_UPDATE_RECORD WAL record type placeholder > -- > > Key: IGNITE-21280 > URL: https://issues.apache.org/jira/browse/IGNITE-21280 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Reserve new WAL type for encrypted DATA_PAGE_FRAGMENTED_UPDATE_RECORD record. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21280) Add DATA_PAGE_FRAGMENTED_UPDATE_RECORD WAL record type placeholder
[ https://issues.apache.org/jira/browse/IGNITE-21280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815729#comment-17815729 ] Vyacheslav Koptilin commented on IGNITE-21280: -- Hello [~nizhikov] , First of all, I am sorry for the late reply. The introduced WAL record can be used for implementing partial updates on an entry like updating time-to-live value https://issues.apache.org/jira/browse/IGNITE-14326 In this case, we don't need to update the whole entry, it requires to re-write only 8 bytes in the same place (I mean 1 or 2 data pages that contain the value). For now, such in-place updates are prohibited. > Add DATA_PAGE_FRAGMENTED_UPDATE_RECORD WAL record type placeholder > -- > > Key: IGNITE-21280 > URL: https://issues.apache.org/jira/browse/IGNITE-21280 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Reserve new WAL type for encrypted DATA_PAGE_FRAGMENTED_UPDATE_RECORD record. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20448) Implement strategies for failure handling
[ https://issues.apache.org/jira/browse/IGNITE-20448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20448: - Fix Version/s: 3.0.0-beta2 > Implement strategies for failure handling > - > > Key: IGNITE-20448 > URL: https://issues.apache.org/jira/browse/IGNITE-20448 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Need to implement the following strategies for failure handling: > - StopNodeFailureHandler This handler should stop the node in case of a > critical error > - StopNodeOrHaltFailureHandler This handler should try to stop the node. If > the node cannot be stopped during a timeout, then the JVM process should be > stopped forcibly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
