[jira] [Updated] (IGNITE-21617) Update to Gradle 8.6
[ https://issues.apache.org/jira/browse/IGNITE-21617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21617: --- Reviewer: Mikhail Pochatkin > Update to Gradle 8.6 > > > Key: IGNITE-21617 > URL: https://issues.apache.org/jira/browse/IGNITE-21617 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We need this to fully support Java 21 (with the currently used Gradle 7.x, > builds fail on the TC). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21630) Cluster falls apart on topology change when DNS service is unavailable
[
https://issues.apache.org/jira/browse/IGNITE-21630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822422#comment-17822422
]
Ignite TC Bot commented on IGNITE-21630:
{panel:title=Branch: [pull/11260/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11260/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7765945buildTypeId=IgniteTests24Java8_RunAll]
> Cluster falls apart on topology change when DNS service is unavailable
> ---
>
> Key: IGNITE-21630
> URL: https://issues.apache.org/jira/browse/IGNITE-21630
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Requests to DNS service performed synchroniously by some critical discovery
> threads. Timeout for such requests can't be controlled by java code (see
> [https://bugs.openjdk.org/browse/JDK-6450279]). This leads to segmentation of
> nodes and falling apart cluster.
> For example, stack of {{tcp-disco-msg-worker}} thread with request to DNS
> service:
> {noformat}
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1330)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1283)
> at java.net.InetAddress.getAllByName(InetAddress.java:1199)
> at java.net.InetAddress.getAllByName(InetAddress.java:1127)
> at java.net.InetAddress.getByName(InetAddress.java:1077)
> at java.net.InetSocketAddress.(InetSocketAddress.java:220)
> at
> org.apache.ignite.internal.util.IgniteUtils.createResolved(IgniteUtils.java:9829)
> at
> org.apache.ignite.internal.util.IgniteUtils.toSocketAddresses(IgniteUtils.java:9792)
> at
> org.apache.ignite.internal.util.IgniteUtils.toSocketAddresses(IgniteUtils.java:9770)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNode.socketAddresses(TcpDiscoveryNode.java:392)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.getNodeAddresses(TcpDiscoverySpi.java:1267)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.interruptPing(ServerImpl.java:985)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$6800(ServerImpl.java:206)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeLeftMessage(ServerImpl.java:5433)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:3221)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2894)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21638) Remove doNotTrackState from extractParserTemplate Gradle task
[ https://issues.apache.org/jira/browse/IGNITE-21638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21638: --- Description: When running a build (./gradlew clean build -x test -x integrationTest) with Gradle 8.6 (8.5 as well) on Windows, this results in the following: > Task :ignite-sql-engine:extractParserTemplate FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':ignite-sql-engine:extractParserTemplate'. > Cannot access a file in the destination directory. Copying to a directory > which contains unreadable content is not supported. Declare the task as > untracked by using Task.doNotTrackState(). For more information, please refer > to > https://docs.gradle.org/8.6/userguide/incremental_build.html#sec:disable-state-tracking > in the Gradle documentation. > Failed to create MD5 hash for file content. As a work-around, doNotTrackState was used to disable state tracking for the offending task, as suggested in the Gradle docs (to which the link in the failure explanation points). This needs to be investigated and fixed properly. On Linux it works fine, so the workaround is Windows-only. > Remove doNotTrackState from extractParserTemplate Gradle task > - > > Key: IGNITE-21638 > URL: https://issues.apache.org/jira/browse/IGNITE-21638 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When running a build (./gradlew clean build -x test -x integrationTest) with > Gradle 8.6 (8.5 as well) on Windows, this results in the following: > > > Task :ignite-sql-engine:extractParserTemplate FAILED > FAILURE: Build failed with an exception. > * What went wrong: > Execution failed for task ':ignite-sql-engine:extractParserTemplate'. > > Cannot access a file in the destination directory. Copying to a directory > > which contains unreadable content is not supported. Declare the task as > > untracked by using Task.doNotTrackState(). For more information, please > > refer to > > https://docs.gradle.org/8.6/userguide/incremental_build.html#sec:disable-state-tracking > > in the Gradle documentation. > > Failed to create MD5 hash for file content. > > As a work-around, doNotTrackState was used to disable state tracking for the > offending task, as suggested in the Gradle docs (to which the link in the > failure explanation points). This needs to be investigated and fixed properly. > On Linux it works fine, so the workaround is Windows-only. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21640) Exchange with ClusterNode instances on handshake
[ https://issues.apache.org/jira/browse/IGNITE-21640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21640: --- Description: To make it possible to implement IGNITE-20296, we need a guarantee that a channel has ClusterNode corresponding to its other side before any message is received. The easiest way to achieve this is to exchange with ClusterNode instances during a handshake. > Exchange with ClusterNode instances on handshake > > > Key: IGNITE-21640 > URL: https://issues.apache.org/jira/browse/IGNITE-21640 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > To make it possible to implement IGNITE-20296, we need a guarantee that a > channel has ClusterNode corresponding to its other side before any message is > received. The easiest way to achieve this is to exchange with ClusterNode > instances during a handshake. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21640) Exchange with ClusterNode instances on handshake
[ https://issues.apache.org/jira/browse/IGNITE-21640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21640: --- Epic Link: IGNITE-21188 > Exchange with ClusterNode instances on handshake > > > Key: IGNITE-21640 > URL: https://issues.apache.org/jira/browse/IGNITE-21640 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > To make it possible to implement IGNITE-20296, we need a guarantee that a > channel has ClusterNode corresponding to its other side before any message is > received. The easiest way to achieve this is to exchange with ClusterNode > instances during a handshake. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21640) Exchange with ClusterNode instances on handshake
Roman Puchkovskiy created IGNITE-21640: -- Summary: Exchange with ClusterNode instances on handshake Key: IGNITE-21640 URL: https://issues.apache.org/jira/browse/IGNITE-21640 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21635) NPE in IndexUpdateHandler
[
https://issues.apache.org/jira/browse/IGNITE-21635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-21635:
-
Fix Version/s: 3.0.0-beta2
> NPE in IndexUpdateHandler
> -
>
> Key: IGNITE-21635
> URL: https://issues.apache.org/jira/browse/IGNITE-21635
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: NPE_in_IndexUpdateHandler.patch
>
>
> See attached reproducer. After restart, node got into invalid state after
> hitting NPE during recovery.
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.table.distributed.index.IndexUpdateHandler.buildIndex(IndexUpdateHandler.java:174)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$handleBuildIndexCommand$9(PartitionListener.java:547)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.lambda$runConsistently$0(PersistentPageMemoryMvPartitionStorage.java:148)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.AbstractPageMemoryMvPartitionStorage.busy(AbstractPageMemoryMvPartitionStorage.java:749)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.runConsistently(PersistentPageMemoryMvPartitionStorage.java:138)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.ThreadAssertingMvPartitionStorage.runConsistently(ThreadAssertingMvPartitionStorage.java:48)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.snapshot.outgoing.SnapshotAwarePartitionDataStorage.runConsistently(SnapshotAwarePartitionDataStorage.java:76)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.handleBuildIndexCommand(PartitionListener.java:532)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$onWrite$1(PartitionListener.java:212)
> ~[main/:?]
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> [?:?]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21639) Server after kill does not start and stuck on election
Igor created IGNITE-21639:
-
Summary: Server after kill does not start and stuck on election
Key: IGNITE-21639
URL: https://issues.apache.org/jira/browse/IGNITE-21639
Project: Ignite
Issue Type: Improvement
Components: general, networking, platforms
Affects Versions: 3.0.0-beta1
Reporter: Igor
Attachments:
poc-tester-SERVER-192.168.1.117-id-0-2024-02-29-22-56-11-client.log.0
*Steps to reproduce:*
# Start the 3 nodes cluster on different machine each (not in docker).
# Insert about 500 000 rows across 500 tables. Replication is 3.
# Kill one node.
# Start killed node.
*Expected:*
The node is started, joined to the cluster and works normally.
Actual:
The node stucks on starting with repeating messages like this:
{code:java}
2024-02-29 23:06:21:261 +0300
[INFO][%poc-tester-SERVER-192.168.1.117-id-0%JRaft-ElectionTimer-18][NodeImpl]
Unsuccessful election round number 128
2024-02-29 23:06:21:261 +0300
[INFO][%poc-tester-SERVER-192.168.1.117-id-0%JRaft-ElectionTimer-18][NodeImpl]
Node <154_part_24/poc-tester-SERVER-192.168.1.117-id-0> term 3 start preVote.
2024-02-29 23:06:21:282 +0300
[ERROR][%poc-tester-SERVER-192.168.1.117-id-0%JRaft-FSMCaller-Disruptor_stripe_5-0][StripedDisruptor]
Handle disruptor event error
[name=%poc-tester-SERVER-192.168.1.117-id-0%JRaft-FSMCaller-Disruptor-,
event=org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTask@efb699b,
hasHandler=false]
java.lang.AssertionError: Safe time reordering detected
[current=112016525904248838, proposed=112016523364991002]
at
org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$onWrite$1(PartitionListener.java:169)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
at
org.apache.ignite.internal.table.distributed.raft.PartitionListener.onWrite(PartitionListener.java:159)
at
org.apache.ignite.internal.raft.server.impl.JraftServerImpl$DelegatingStateMachine.onApply(JraftServerImpl.java:674)
at
org.apache.ignite.raft.jraft.core.FSMCallerImpl.doApplyTasks(FSMCallerImpl.java:557)
at
org.apache.ignite.raft.jraft.core.FSMCallerImpl.doCommitted(FSMCallerImpl.java:525)
at
org.apache.ignite.raft.jraft.core.FSMCallerImpl.runApplyTask(FSMCallerImpl.java:444)
at
org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTaskHandler.onEvent(FSMCallerImpl.java:136)
at
org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTaskHandler.onEvent(FSMCallerImpl.java:130)
at
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:266)
at
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:231)
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
at java.base/java.lang.Thread.run(Thread.java:829){code}
[^poc-tester-SERVER-192.168.1.117-id-0-2024-02-29-22-56-11-client.log.0]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21637) Possibility of integer overflow in page eviction trackers
[
https://issues.apache.org/jira/browse/IGNITE-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21637:
---
Summary: Possibility of integer overflow in page eviction trackers (was:
Integer overflow in page eviction trackers)
> Possibility of integer overflow in page eviction trackers
> -
>
> Key: IGNITE-21637
> URL: https://issues.apache.org/jira/browse/IGNITE-21637
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Critical
> Labels: ise
>
> Ignite Node can fail with segmentation violation because of integer overflow
> when eviction policy is used and large amount pages is allocated.
> One of the problematic places: {{Random2LruPageEvictionTracker#touchPage}}
> [1]. In this place we can get incorrect offset value when {{trackingIdx}} is
> more than {{Integer.MAX_VALUE / 8}}:
> {{trackingArrPtr (long) + trackingIdx (int) * 8}}.
> #
> https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21637) Integer overflow in page eviction trackers
[
https://issues.apache.org/jira/browse/IGNITE-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21637:
---
Description:
Ignite Node can fail with segmentation violation because of integer overflow
when eviction policy is used and large amount pages is allocated.
One of the problematic places: {{Random2LruPageEvictionTracker#touchPage}} [1].
In this place we can get incorrect offset value when {{trackingIdx}} is more
than {{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
was:
Ignite Node can fail with segmentation violation because of integer overflow
when eviction policy is used and large amount pages is allocated.
One of the problematic places: {{Random2LruPageEvictionTracker#touchPage}} [1].
In this place we can get incorrect address value when {{trackingIdx}} is more
than {{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
> Integer overflow in page eviction trackers
> --
>
> Key: IGNITE-21637
> URL: https://issues.apache.org/jira/browse/IGNITE-21637
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Critical
> Labels: ise
>
> Ignite Node can fail with segmentation violation because of integer overflow
> when eviction policy is used and large amount pages is allocated.
> One of the problematic places: {{Random2LruPageEvictionTracker#touchPage}}
> [1]. In this place we can get incorrect offset value when {{trackingIdx}} is
> more than {{Integer.MAX_VALUE / 8}}:
> {{trackingArrPtr (long) + trackingIdx (int) * 8}}.
> #
> https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21637) Integer overflow in page eviction trackers
[
https://issues.apache.org/jira/browse/IGNITE-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21637:
---
Description:
Ignite Node can fail with segmentation violation because of integer overflow
when eviction policy is used and large amount pages is allocated.
One of the problematic places: {{Random2LruPageEvictionTracker#touchPage}} [1].
In this place we can get incorrect address value when {{trackingIdx}} is more
than {{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
was:
Ignite Node can fail with segmentation violation because of integer overflow
when eviction policy is used and large amount pages is allocated.
One of the problematic places: {{Random2LruPageEvictionTracker#touchPage}} [1].
In this place we can get incorrect value when {{trackingIdx}} is more than
{{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
> Integer overflow in page eviction trackers
> --
>
> Key: IGNITE-21637
> URL: https://issues.apache.org/jira/browse/IGNITE-21637
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Critical
> Labels: ise
>
> Ignite Node can fail with segmentation violation because of integer overflow
> when eviction policy is used and large amount pages is allocated.
> One of the problematic places: {{Random2LruPageEvictionTracker#touchPage}}
> [1]. In this place we can get incorrect address value when {{trackingIdx}} is
> more than {{Integer.MAX_VALUE / 8}}:
> {{trackingArrPtr (long) + trackingIdx (int) * 8}}.
> #
> https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21637) Integer overflow in page eviction trackers
[
https://issues.apache.org/jira/browse/IGNITE-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21637:
---
Description:
Ignite Node can fail with segmentation violation because of integer overflow
when eviction policy is used and large amount pages is allocated.
One of the problematic places: {{Random2LruPageEvictionTracker#touchPage}} [1].
In this place we can get incorrect value when {{trackingIdx}} is more than
{{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
was:
Ignite Node can fail with segmentation violation because of integer overflow
when eviction policy is used and large amount pages is allocated.
One of the problematic places {{Random2LruPageEvictionTracker#touchPage}} [1]
where we can get incorrect value when {{trackingIdx}} is more than
{{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
> Integer overflow in page eviction trackers
> --
>
> Key: IGNITE-21637
> URL: https://issues.apache.org/jira/browse/IGNITE-21637
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Critical
> Labels: ise
>
> Ignite Node can fail with segmentation violation because of integer overflow
> when eviction policy is used and large amount pages is allocated.
> One of the problematic places: {{Random2LruPageEvictionTracker#touchPage}}
> [1]. In this place we can get incorrect value when {{trackingIdx}} is more
> than {{Integer.MAX_VALUE / 8}}:
> {{trackingArrPtr (long) + trackingIdx (int) * 8}}.
> #
> https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21637) Integer overflow in page eviction trackers
[
https://issues.apache.org/jira/browse/IGNITE-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21637:
---
Description:
Ignite Node can fail with segmentation violation because of integer overflow
when eviction policy is used and large amount pages is allocated.
One of the problematic places {{Random2LruPageEvictionTracker#touchPage}} [1]
where we can get incorrect value when {{trackingIdx}} is more than
{{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
was:
Ignite Node can fail with segmentation violation because of integer overflow
when eviction policy is used and large amount pages is allocated.
One of the problematic places [1] where we can get incorrect value when
{{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
> Integer overflow in page eviction trackers
> --
>
> Key: IGNITE-21637
> URL: https://issues.apache.org/jira/browse/IGNITE-21637
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Critical
> Labels: ise
>
> Ignite Node can fail with segmentation violation because of integer overflow
> when eviction policy is used and large amount pages is allocated.
> One of the problematic places {{Random2LruPageEvictionTracker#touchPage}} [1]
> where we can get incorrect value when {{trackingIdx}} is more than
> {{Integer.MAX_VALUE / 8}}:
> {{trackingArrPtr (long) + trackingIdx (int) * 8}}.
> #
> https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21637) Integer overflow in page eviction trackers
[
https://issues.apache.org/jira/browse/IGNITE-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21637:
---
Description:
Ignite Node can fail with segmentation violation because of integer overflow
when eviction policy is used and large amount pages is allocated.
One of the problematic places [1] where we can get incorrect value when
{{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
was:
Ignite Node can fail with segmentation violation because of integer overflow
when eviction policy is used and large amount pages is allocated.
One of the problematic places [1] where we can geе incorrect value when
{{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
> Integer overflow in page eviction trackers
> --
>
> Key: IGNITE-21637
> URL: https://issues.apache.org/jira/browse/IGNITE-21637
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Critical
> Labels: ise
>
> Ignite Node can fail with segmentation violation because of integer overflow
> when eviction policy is used and large amount pages is allocated.
> One of the problematic places [1] where we can get incorrect value when
> {{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
> {{trackingArrPtr (long) + trackingIdx (int) * 8}}.
> #
> https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21637) Integer overflow in page eviction trackers
[
https://issues.apache.org/jira/browse/IGNITE-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21637:
---
Description:
Ignite Node can fail with segmentation violation when eviction policy is used
and large amount pages is allocated because of integer overflow.
One of the problematic places [1] where we can geе incorrect value when
{{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
was:
Ignite Node can fail with segmentation violation in case if eviction policy is
used and large amount of allocated pages because of integer overflow.
One of the problematic places [1] where we can ge incorrect value when
{{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
> Integer overflow in page eviction trackers
> --
>
> Key: IGNITE-21637
> URL: https://issues.apache.org/jira/browse/IGNITE-21637
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Critical
> Labels: ise
>
> Ignite Node can fail with segmentation violation when eviction policy is used
> and large amount pages is allocated because of integer overflow.
> One of the problematic places [1] where we can geе incorrect value when
> {{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
> {{trackingArrPtr (long) + trackingIdx (int) * 8}}.
> #
> https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21638) Remove doNotTrackState from extractParserTemplate Gradle task
Roman Puchkovskiy created IGNITE-21638: -- Summary: Remove doNotTrackState from extractParserTemplate Gradle task Key: IGNITE-21638 URL: https://issues.apache.org/jira/browse/IGNITE-21638 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21637) Integer overflow in page eviction trackers
[
https://issues.apache.org/jira/browse/IGNITE-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21637:
---
Description:
Ignite Node can fail with segmentation violation because of integer overflow
when eviction policy is used and large amount pages is allocated.
One of the problematic places [1] where we can geе incorrect value when
{{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
was:
Ignite Node can fail with segmentation violation when eviction policy is used
and large amount pages is allocated because of integer overflow.
One of the problematic places [1] where we can geе incorrect value when
{{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
> Integer overflow in page eviction trackers
> --
>
> Key: IGNITE-21637
> URL: https://issues.apache.org/jira/browse/IGNITE-21637
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Critical
> Labels: ise
>
> Ignite Node can fail with segmentation violation because of integer overflow
> when eviction policy is used and large amount pages is allocated.
> One of the problematic places [1] where we can geе incorrect value when
> {{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
> {{trackingArrPtr (long) + trackingIdx (int) * 8}}.
> #
> https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21637) Integer overflow in page eviction trackers
[
https://issues.apache.org/jira/browse/IGNITE-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21637:
---
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Integer overflow in page eviction trackers
> --
>
> Key: IGNITE-21637
> URL: https://issues.apache.org/jira/browse/IGNITE-21637
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Critical
> Labels: ise
>
> Ignite Node can fail with segmentation violation in case if eviction policy
> is used and large amount of allocated pages because of integer overflow.
> One of the problematic places [1] where we can ge incorrect value when
> {{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
> {{trackingArrPtr (long) + trackingIdx (int) * 8}}.
> #
> https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21637) Integer overflow in page eviction trackers
[
https://issues.apache.org/jira/browse/IGNITE-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21637:
---
Description:
Ignite Node can fail with segmentation violation in case if eviction policy is
used and large amount of allocated pages because of integer overflow.
One of the problematic places [1] where we can ge incorrect value when
{{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
was:
Ignite Node can fail with segmentation violation in case if eviction policy is
used and large amount of allocated pages because of integer overflow.
One of the problematic places [1] where we can ge incorrect value when
{{trackingIdx}} is more than Integer.MAX_VALUE / 8:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
> Integer overflow in page eviction trackers
> --
>
> Key: IGNITE-21637
> URL: https://issues.apache.org/jira/browse/IGNITE-21637
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Critical
> Labels: ise
>
> Ignite Node can fail with segmentation violation in case if eviction policy
> is used and large amount of allocated pages because of integer overflow.
> One of the problematic places [1] where we can ge incorrect value when
> {{trackingIdx}} is more than {{Integer.MAX_VALUE / 8}}:
> {{trackingArrPtr (long) + trackingIdx (int) * 8}}.
> #
> https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21637) Integer overflow in page eviction trackers
[
https://issues.apache.org/jira/browse/IGNITE-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21637:
---
Description:
Ignite Node can fail with segmentation violation in case if eviction policy is
used and large amount of allocated pages because of integer overflow.
One of the problematic places [1] where we can ge incorrect value when
{{trackingIdx}} is more than Integer.MAX_VALUE / 8:
{{trackingArrPtr (long) + trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
was:
Ignite Node can fail with segmentation violation in case if eviction policy is
used and large amount of allocated pages because of integer overflow.
One of the problematic places [1] where we can ge incorrect value when
{{trackingIdx}} is more than Integer.MAX_VALUE / 8: {{trackingArrPtr (long) +
trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
> Integer overflow in page eviction trackers
> --
>
> Key: IGNITE-21637
> URL: https://issues.apache.org/jira/browse/IGNITE-21637
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Critical
> Labels: ise
>
> Ignite Node can fail with segmentation violation in case if eviction policy
> is used and large amount of allocated pages because of integer overflow.
> One of the problematic places [1] where we can ge incorrect value when
> {{trackingIdx}} is more than Integer.MAX_VALUE / 8:
> {{trackingArrPtr (long) + trackingIdx (int) * 8}}.
> #
> https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21637) Integer overflow in page eviction trackers
Ilya Shishkov created IGNITE-21637:
--
Summary: Integer overflow in page eviction trackers
Key: IGNITE-21637
URL: https://issues.apache.org/jira/browse/IGNITE-21637
Project: Ignite
Issue Type: Bug
Reporter: Ilya Shishkov
Ignite Node can fail with segmentation violation in case if eviction policy is
used and large amount of allocated pages because of integer overflow.
One of the problematic places [1] where we can ge incorrect value when
{{trackingIdx}} is more than Integer.MAX_VALUE / 8: {{trackingArrPtr (long) +
trackingIdx (int) * 8}}.
#
https://github.com/apache/ignite/blob/5ad698dab9835f6e6efb6a8b12da34515bd78349/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/evict/Random2LruPageEvictionTracker.java#L95
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21635) NPE in IndexUpdateHandler
[
https://issues.apache.org/jira/browse/IGNITE-21635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-21635:
-
Epic Link: IGNITE-20782
> NPE in IndexUpdateHandler
> -
>
> Key: IGNITE-21635
> URL: https://issues.apache.org/jira/browse/IGNITE-21635
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Attachments: NPE_in_IndexUpdateHandler.patch
>
>
> See attached reproducer. After restart, node got into invalid state after
> hitting NPE during recovery.
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.table.distributed.index.IndexUpdateHandler.buildIndex(IndexUpdateHandler.java:174)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$handleBuildIndexCommand$9(PartitionListener.java:547)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.lambda$runConsistently$0(PersistentPageMemoryMvPartitionStorage.java:148)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.AbstractPageMemoryMvPartitionStorage.busy(AbstractPageMemoryMvPartitionStorage.java:749)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.runConsistently(PersistentPageMemoryMvPartitionStorage.java:138)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.ThreadAssertingMvPartitionStorage.runConsistently(ThreadAssertingMvPartitionStorage.java:48)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.snapshot.outgoing.SnapshotAwarePartitionDataStorage.runConsistently(SnapshotAwarePartitionDataStorage.java:76)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.handleBuildIndexCommand(PartitionListener.java:532)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$onWrite$1(PartitionListener.java:212)
> ~[main/:?]
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> [?:?]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21635) NPE in IndexUpdateHandler
[
https://issues.apache.org/jira/browse/IGNITE-21635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-21635:
Assignee: Kirill Tkalenko
> NPE in IndexUpdateHandler
> -
>
> Key: IGNITE-21635
> URL: https://issues.apache.org/jira/browse/IGNITE-21635
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Attachments: NPE_in_IndexUpdateHandler.patch
>
>
> See attached reproducer. After restart, node got into invalid state after
> hitting NPE during recovery.
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.table.distributed.index.IndexUpdateHandler.buildIndex(IndexUpdateHandler.java:174)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$handleBuildIndexCommand$9(PartitionListener.java:547)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.lambda$runConsistently$0(PersistentPageMemoryMvPartitionStorage.java:148)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.AbstractPageMemoryMvPartitionStorage.busy(AbstractPageMemoryMvPartitionStorage.java:749)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.runConsistently(PersistentPageMemoryMvPartitionStorage.java:138)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.ThreadAssertingMvPartitionStorage.runConsistently(ThreadAssertingMvPartitionStorage.java:48)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.snapshot.outgoing.SnapshotAwarePartitionDataStorage.runConsistently(SnapshotAwarePartitionDataStorage.java:76)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.handleBuildIndexCommand(PartitionListener.java:532)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$onWrite$1(PartitionListener.java:212)
> ~[main/:?]
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> [?:?]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21550) ignite-cdc doesn't expose metrics via push metric exporters
[ https://issues.apache.org/jira/browse/IGNITE-21550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-21550: Ignite Flags: (was: Docs Required,Release Notes Required) > ignite-cdc doesn't expose metrics via push metric exporters > --- > > Key: IGNITE-21550 > URL: https://issues.apache.org/jira/browse/IGNITE-21550 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 0.5h > Remaining Estimate: 0h > > For example cdc-related metric are not exposed via the > OpenCensusMetricExporterSpi -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21550) ignite-cdc doesn't expose metrics via push metric exporters
[ https://issues.apache.org/jira/browse/IGNITE-21550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-21550: Fix Version/s: 2.17 > ignite-cdc doesn't expose metrics via push metric exporters > --- > > Key: IGNITE-21550 > URL: https://issues.apache.org/jira/browse/IGNITE-21550 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 0.5h > Remaining Estimate: 0h > > For example cdc-related metric are not exposed via the > OpenCensusMetricExporterSpi -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21550) ignite-cdc doesn't expose metrics via push metric exporters
[
https://issues.apache.org/jira/browse/IGNITE-21550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822155#comment-17822155
]
Ignite TC Bot commented on IGNITE-21550:
{panel:title=Branch: [pull/11248/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11248/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 2{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7765376]]
* {color:#013220}IgnitePdsTestSuite2:
CdcPushMetricsExporterTest.testPushMetricsExporter - PASSED{color}
{color:#8b}Disk Page Compressions 2{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7765420]]
* {color:#013220}IgnitePdsCompressionTestSuite2:
CdcPushMetricsExporterTest.testPushMetricsExporter - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7765424buildTypeId=IgniteTests24Java8_RunAll]
> ignite-cdc doesn't expose metrics via push metric exporters
> ---
>
> Key: IGNITE-21550
> URL: https://issues.apache.org/jira/browse/IGNITE-21550
> Project: Ignite
> Issue Type: Task
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For example cdc-related metric are not exposed via the
> OpenCensusMetricExporterSpi
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21636) Code cleanup
Vladimir Steshin created IGNITE-21636: - Summary: Code cleanup Key: IGNITE-21636 URL: https://issues.apache.org/jira/browse/IGNITE-21636 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Removing of unused 'mvccEnabled', codestyle fixex, +abbreviations, finals and etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21635) NPE in IndexUpdateHandler
Konstantin Orlov created IGNITE-21635:
-
Summary: NPE in IndexUpdateHandler
Key: IGNITE-21635
URL: https://issues.apache.org/jira/browse/IGNITE-21635
Project: Ignite
Issue Type: Bug
Reporter: Konstantin Orlov
Attachments: NPE_in_IndexUpdateHandler.patch
See attached reproducer. After restart, node got into invalid state after
hitting NPE during recovery.
{code}
java.lang.NullPointerException: null
at
org.apache.ignite.internal.table.distributed.index.IndexUpdateHandler.buildIndex(IndexUpdateHandler.java:174)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$handleBuildIndexCommand$9(PartitionListener.java:547)
~[main/:?]
at
org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.lambda$runConsistently$0(PersistentPageMemoryMvPartitionStorage.java:148)
~[main/:?]
at
org.apache.ignite.internal.storage.pagememory.mv.AbstractPageMemoryMvPartitionStorage.busy(AbstractPageMemoryMvPartitionStorage.java:749)
~[main/:?]
at
org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.runConsistently(PersistentPageMemoryMvPartitionStorage.java:138)
~[main/:?]
at
org.apache.ignite.internal.storage.ThreadAssertingMvPartitionStorage.runConsistently(ThreadAssertingMvPartitionStorage.java:48)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.raft.snapshot.outgoing.SnapshotAwarePartitionDataStorage.runConsistently(SnapshotAwarePartitionDataStorage.java:76)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.raft.PartitionListener.handleBuildIndexCommand(PartitionListener.java:532)
~[main/:?]
at
org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$onWrite$1(PartitionListener.java:212)
~[main/:?]
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
[?:?]
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21635) NPE in IndexUpdateHandler
[
https://issues.apache.org/jira/browse/IGNITE-21635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-21635:
--
Attachment: NPE_in_IndexUpdateHandler.patch
> NPE in IndexUpdateHandler
> -
>
> Key: IGNITE-21635
> URL: https://issues.apache.org/jira/browse/IGNITE-21635
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Attachments: NPE_in_IndexUpdateHandler.patch
>
>
> See attached reproducer. After restart, node got into invalid state after
> hitting NPE during recovery.
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.table.distributed.index.IndexUpdateHandler.buildIndex(IndexUpdateHandler.java:174)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$handleBuildIndexCommand$9(PartitionListener.java:547)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.lambda$runConsistently$0(PersistentPageMemoryMvPartitionStorage.java:148)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.AbstractPageMemoryMvPartitionStorage.busy(AbstractPageMemoryMvPartitionStorage.java:749)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.runConsistently(PersistentPageMemoryMvPartitionStorage.java:138)
> ~[main/:?]
> at
> org.apache.ignite.internal.storage.ThreadAssertingMvPartitionStorage.runConsistently(ThreadAssertingMvPartitionStorage.java:48)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.snapshot.outgoing.SnapshotAwarePartitionDataStorage.runConsistently(SnapshotAwarePartitionDataStorage.java:76)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.handleBuildIndexCommand(PartitionListener.java:532)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$onWrite$1(PartitionListener.java:212)
> ~[main/:?]
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> [?:?]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21634) NPE in HeapLockManager
[
https://issues.apache.org/jira/browse/IGNITE-21634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-21634:
--
Issue Type: Bug (was: Improvement)
> NPE in HeapLockManager
> --
>
> Key: IGNITE-21634
> URL: https://issues.apache.org/jira/browse/IGNITE-21634
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> Caused by: java.lang.NullPointerException at
> org.apache.ignite.internal.tx.impl.HeapLockManager.lambda$lockState$4(HeapLockManager.java:297)
> ~[main/:?] at
> java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> ~[?:?] at
> org.apache.ignite.internal.tx.impl.HeapLockManager.lockState(HeapLockManager.java:291)
> ~[main/:?] at
> org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:172)
> ~[main/:?] at
> org.apache.ignite.internal.table.distributed.SortedIndexLocker.lambda$locksForInsert$4(SortedIndexLocker.java:169)
> ~[main/:?] at
> java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> ~[?:?] ... 29 more{code}
> on the line {{v.markedForRemove = false;}}
> {code:java}
> private LockState lockState(LockKey key) {
> int h = spread(key.hashCode());
> int index = h & (slots.length - 1);
> LockState[] res = new LockState[1];
> locks.compute(key, (k, v) -> {
> if (v == null) {
> if (empty.isEmpty()) {
> res[0] = slots[index];
> } else {
> v = empty.poll();
> v.markedForRemove = false;
> v.key = k;
> res[0] = v;
> }
> } else {
> res[0] = v;
> }
> return v;
> });
> return res[0];
> } {code}
> The problem can be reproduced on main(71b4fb34) with following test
> (probably, fsync should be turned off):
> {code}
> @Test
> void test() {
> sql("CREATE TABLE test("
> + "c1 INT PRIMARY KEY, c2 INT, c3 INT, c4 INT, c5 INT,"
> + "c6 INT, c7 INT, c8 INT, c9 INT, c10 INT)"
> );
> for (int i = 2; i <= 10; i++) {
> sql(format("CREATE INDEX c{}_idx ON test (c{})", i, i));
> }
> sql("INSERT INTO test"
> + " SELECT x as c1, x as c2, x as c3, x as c4, x as c5, "
> + "x as c6, x as c7, x as c8, x as c9, x as c10"
> + " FROM TABLE (system_range(1, 10))");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21634) NPE in HeapLockManager
[
https://issues.apache.org/jira/browse/IGNITE-21634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-21634:
--
Description:
{code:java}
Caused by: java.lang.NullPointerException at
org.apache.ignite.internal.tx.impl.HeapLockManager.lambda$lockState$4(HeapLockManager.java:297)
~[main/:?] at
java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
~[?:?] at
org.apache.ignite.internal.tx.impl.HeapLockManager.lockState(HeapLockManager.java:291)
~[main/:?] at
org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:172)
~[main/:?] at
org.apache.ignite.internal.table.distributed.SortedIndexLocker.lambda$locksForInsert$4(SortedIndexLocker.java:169)
~[main/:?] at
java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
~[?:?] ... 29 more{code}
on the line {{v.markedForRemove = false;}}
{code:java}
private LockState lockState(LockKey key) {
int h = spread(key.hashCode());
int index = h & (slots.length - 1);
LockState[] res = new LockState[1];
locks.compute(key, (k, v) -> {
if (v == null) {
if (empty.isEmpty()) {
res[0] = slots[index];
} else {
v = empty.poll();
v.markedForRemove = false;
v.key = k;
res[0] = v;
}
} else {
res[0] = v;
}
return v;
});
return res[0];
} {code}
The problem can be reproduced on main(71b4fb34) with following test (probably,
fsync should be turned off):
{code}
@Test
void test() {
sql("CREATE TABLE test("
+ "c1 INT PRIMARY KEY, c2 INT, c3 INT, c4 INT, c5 INT,"
+ "c6 INT, c7 INT, c8 INT, c9 INT, c10 INT)"
);
for (int i = 2; i <= 10; i++) {
sql(format("CREATE INDEX c{}_idx ON test (c{})", i, i));
}
sql("INSERT INTO test"
+ " SELECT x as c1, x as c2, x as c3, x as c4, x as c5, "
+ "x as c6, x as c7, x as c8, x as c9, x as c10"
+ " FROM TABLE (system_range(1, 10))");
}
{code}
was:
{code:java}
Caused by: java.lang.NullPointerException at
org.apache.ignite.internal.tx.impl.HeapLockManager.lambda$lockState$4(HeapLockManager.java:297)
~[main/:?] at
java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
~[?:?] at
org.apache.ignite.internal.tx.impl.HeapLockManager.lockState(HeapLockManager.java:291)
~[main/:?] at
org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:172)
~[main/:?] at
org.apache.ignite.internal.table.distributed.SortedIndexLocker.lambda$locksForInsert$4(SortedIndexLocker.java:169)
~[main/:?] at
java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
~[?:?] ... 29 more{code}
on the line {{v.markedForRemove = false;}}
{code:java}
private LockState lockState(LockKey key) {
int h = spread(key.hashCode());
int index = h & (slots.length - 1);
LockState[] res = new LockState[1];
locks.compute(key, (k, v) -> {
if (v == null) {
if (empty.isEmpty()) {
res[0] = slots[index];
} else {
v = empty.poll();
v.markedForRemove = false;
v.key = k;
res[0] = v;
}
} else {
res[0] = v;
}
return v;
});
return res[0];
} {code}
> NPE in HeapLockManager
> --
>
> Key: IGNITE-21634
> URL: https://issues.apache.org/jira/browse/IGNITE-21634
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> Caused by: java.lang.NullPointerException at
> org.apache.ignite.internal.tx.impl.HeapLockManager.lambda$lockState$4(HeapLockManager.java:297)
> ~[main/:?] at
> java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> ~[?:?] at
> org.apache.ignite.internal.tx.impl.HeapLockManager.lockState(HeapLockManager.java:291)
> ~[main/:?] at
> org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:172)
> ~[main/:?] at
> org.apache.ignite.internal.table.distributed.SortedIndexLocker.lambda$locksForInsert$4(SortedIndexLocker.java:169)
> ~[main/:?] at
> java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> ~[?:?] ... 29 more{code}
> on the line {{v.markedForRemove = false;}}
> {code:java}
> private LockState lockState(LockKey key) {
> int h = spread(key.hashCode());
> int index = h & (slots.length - 1);
> LockState[] res = new LockState[1];
> locks.compute(key, (k, v) -> {
> if (v == null) {
> if (empty.isEmpty()) {
> res[0] =
[jira] [Updated] (IGNITE-21634) NPE in HeapLockManager
[
https://issues.apache.org/jira/browse/IGNITE-21634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21634:
--
Description:
{code:java}
Caused by: java.lang.NullPointerException at
org.apache.ignite.internal.tx.impl.HeapLockManager.lambda$lockState$4(HeapLockManager.java:297)
~[main/:?] at
java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
~[?:?] at
org.apache.ignite.internal.tx.impl.HeapLockManager.lockState(HeapLockManager.java:291)
~[main/:?] at
org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:172)
~[main/:?] at
org.apache.ignite.internal.table.distributed.SortedIndexLocker.lambda$locksForInsert$4(SortedIndexLocker.java:169)
~[main/:?] at
java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
~[?:?] ... 29 more{code}
on the line {{v.markedForRemove = false;}}
{code:java}
private LockState lockState(LockKey key) {
int h = spread(key.hashCode());
int index = h & (slots.length - 1);
LockState[] res = new LockState[1];
locks.compute(key, (k, v) -> {
if (v == null) {
if (empty.isEmpty()) {
res[0] = slots[index];
} else {
v = empty.poll();
v.markedForRemove = false;
v.key = k;
res[0] = v;
}
} else {
res[0] = v;
}
return v;
});
return res[0];
} {code}
was:
{code:java}
Caused by: java.lang.NullPointerException at
org.apache.ignite.internal.tx.impl.HeapLockManager.lambda$lockState$4(HeapLockManager.java:297)
~[main/:?] at
java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
~[?:?] at
org.apache.ignite.internal.tx.impl.HeapLockManager.lockState(HeapLockManager.java:291)
~[main/:?] at
org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:172)
~[main/:?] at
org.apache.ignite.internal.table.distributed.SortedIndexLocker.lambda$locksForInsert$4(SortedIndexLocker.java:169)
~[main/:?] at
java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
~[?:?] ... 29 more{code}
> NPE in HeapLockManager
> --
>
> Key: IGNITE-21634
> URL: https://issues.apache.org/jira/browse/IGNITE-21634
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> Caused by: java.lang.NullPointerException at
> org.apache.ignite.internal.tx.impl.HeapLockManager.lambda$lockState$4(HeapLockManager.java:297)
> ~[main/:?] at
> java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> ~[?:?] at
> org.apache.ignite.internal.tx.impl.HeapLockManager.lockState(HeapLockManager.java:291)
> ~[main/:?] at
> org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:172)
> ~[main/:?] at
> org.apache.ignite.internal.table.distributed.SortedIndexLocker.lambda$locksForInsert$4(SortedIndexLocker.java:169)
> ~[main/:?] at
> java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> ~[?:?] ... 29 more{code}
> on the line {{v.markedForRemove = false;}}
> {code:java}
> private LockState lockState(LockKey key) {
> int h = spread(key.hashCode());
> int index = h & (slots.length - 1);
> LockState[] res = new LockState[1];
> locks.compute(key, (k, v) -> {
> if (v == null) {
> if (empty.isEmpty()) {
> res[0] = slots[index];
> } else {
> v = empty.poll();
> v.markedForRemove = false;
> v.key = k;
> res[0] = v;
> }
> } else {
> res[0] = v;
> }
> return v;
> });
> return res[0];
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21634) NPE in HeapLockManager
Denis Chudov created IGNITE-21634:
-
Summary: NPE in HeapLockManager
Key: IGNITE-21634
URL: https://issues.apache.org/jira/browse/IGNITE-21634
Project: Ignite
Issue Type: Improvement
Reporter: Denis Chudov
{code:java}
Caused by: java.lang.NullPointerException at
org.apache.ignite.internal.tx.impl.HeapLockManager.lambda$lockState$4(HeapLockManager.java:297)
~[main/:?] at
java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
~[?:?] at
org.apache.ignite.internal.tx.impl.HeapLockManager.lockState(HeapLockManager.java:291)
~[main/:?] at
org.apache.ignite.internal.tx.impl.HeapLockManager.acquire(HeapLockManager.java:172)
~[main/:?] at
org.apache.ignite.internal.table.distributed.SortedIndexLocker.lambda$locksForInsert$4(SortedIndexLocker.java:169)
~[main/:?] at
java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
~[?:?] ... 29 more{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21284) Internal API for manual raft group configuration update
[ https://issues.apache.org/jira/browse/IGNITE-21284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-21284: - Reviewer: Kirill Tkalenko > Internal API for manual raft group configuration update > --- > > Key: IGNITE-21284 > URL: https://issues.apache.org/jira/browse/IGNITE-21284 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 4h 50m > Remaining Estimate: 0h > > We need an API (with implementation) that's analogous to > "reset-lost-partitions", but with the ability to reuse living minority of > nodes. > This API should gather the states of partitions, identify healthy peers, and > use them as a new raft group configuration (through the update of > assignments). > We have to make sure that node with latest log index will become a leader, so > we will have to propagate desired minimum for log index in assignments and > use it during the voting. > h2. What's implemented > "resetPartitions" operation in distributed zone manager. It identifies > partitions where only a minority of nodes is online (thus they won't be able > to execute "changePeersAsync"), and writes a "forced pending assignments" for > them. > Forced assignment excludes stable nodes, that are not present in pending > assignment, from a new raft group configuration. It also performs a > "resetPeers" operation on alive nodes from the stable assignment. > Complete loss of all nodes from stable assignments is not yet implemented, at > least one node is required to be elected as a leader. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21284) Internal API for manual raft group configuration update
[ https://issues.apache.org/jira/browse/IGNITE-21284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822121#comment-17822121 ] Kirill Tkalenko commented on IGNITE-21284: -- Looks good. > Internal API for manual raft group configuration update > --- > > Key: IGNITE-21284 > URL: https://issues.apache.org/jira/browse/IGNITE-21284 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 4h 50m > Remaining Estimate: 0h > > We need an API (with implementation) that's analogous to > "reset-lost-partitions", but with the ability to reuse living minority of > nodes. > This API should gather the states of partitions, identify healthy peers, and > use them as a new raft group configuration (through the update of > assignments). > We have to make sure that node with latest log index will become a leader, so > we will have to propagate desired minimum for log index in assignments and > use it during the voting. > h2. What's implemented > "resetPartitions" operation in distributed zone manager. It identifies > partitions where only a minority of nodes is online (thus they won't be able > to execute "changePeersAsync"), and writes a "forced pending assignments" for > them. > Forced assignment excludes stable nodes, that are not present in pending > assignment, from a new raft group configuration. It also performs a > "resetPeers" operation on alive nodes from the stable assignment. > Complete loss of all nodes from stable assignments is not yet implemented, at > least one node is required to be elected as a leader. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21253) Implement a counter for number of rebalancing tables inside the zone
[ https://issues.apache.org/jira/browse/IGNITE-21253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822120#comment-17822120 ] Vladislav Pyatkov commented on IGNITE-21253: Merged e701d0709f42a3219fdce5e12fd425d0981123e2 > Implement a counter for number of rebalancing tables inside the zone > - > > Key: IGNITE-21253 > URL: https://issues.apache.org/jira/browse/IGNITE-21253 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Time Spent: 1h 50m > Remaining Estimate: 0h > > *Motivation* > According to comment we need to switch zone assignments, only when all zone > tables finish their rebalances. > To implement this behaviour we need to implement the metastorage counter of > tables, which will be decreased on every successfull table rebalance. > *Definition of done* > - Counter of zone tables created on the rebalance start and decreased with > every successfull table rebalance > *Implementation notes* > - on pending update we set the counter in metastore (if it is not exist). > other tables can't be added because of "avoid table creation during the > rebalance" ticket. > - on the rebalance done instead of the current logic we decrease the counter > (with compareAndSet). > - the separate listener on every node listen to the counters and when it > decreased to 0 - do the usual logic with planned->pending, pending->stable > and etc. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21633) Get rid of RemotelyTriggeredResourceRegistry#remoteHostsToResources
Denis Chudov created IGNITE-21633: - Summary: Get rid of RemotelyTriggeredResourceRegistry#remoteHostsToResources Key: IGNITE-21633 URL: https://issues.apache.org/jira/browse/IGNITE-21633 Project: Ignite Issue Type: Improvement Reporter: Denis Chudov TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21525) Java Client: Clean up IEP-54 leftovers
[ https://issues.apache.org/jira/browse/IGNITE-21525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822117#comment-17822117 ] Igor Sapego commented on IGNITE-21525: -- Looks good to me. > Java Client: Clean up IEP-54 leftovers > -- > > Key: IGNITE-21525 > URL: https://issues.apache.org/jira/browse/IGNITE-21525 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement IGNITE-19744 for Java Client and server counterpart. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21525) Java Client: Clean up IEP-54 leftovers
[ https://issues.apache.org/jira/browse/IGNITE-21525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822112#comment-17822112 ] Pavel Tupitsyn commented on IGNITE-21525: - [~isapego] [~korlov] please review. > Java Client: Clean up IEP-54 leftovers > -- > > Key: IGNITE-21525 > URL: https://issues.apache.org/jira/browse/IGNITE-21525 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement IGNITE-19744 for Java Client and server counterpart. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20373) Fix IO threading model
[ https://issues.apache.org/jira/browse/IGNITE-20373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822098#comment-17822098 ] Roman Puchkovskiy commented on IGNITE-20373: Thanks! > Fix IO threading model > -- > > Key: IGNITE-20373 > URL: https://issues.apache.org/jira/browse/IGNITE-20373 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3, ignite3_performance, threading > Fix For: 3.0.0-beta2 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently IO is resubmitted to inboundExecutor for further processing (even > there are corner cases then a message handler called in IO thread) > It makes message processing essentially single threaded and introduces > additional lag due to message transition to additional queue. > addMessageHandler should be extended with a 3-d argument: a pool for > submitting a callback for execution, or an executorSelector like in jraft. > inboundExecutor should be changed to striped, use more than one thread, and > serve messages without explicit executor. Delivery guaranties should be > preserved: if a message A is send before B, B can't be processed on a > receiver before A. A stripe is defined by sender-receiver pair (or can be > user defined - TBD) > outboundExecutor also looks like a contention point - need to be addressed as > well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20373) Fix IO threading model
[ https://issues.apache.org/jira/browse/IGNITE-20373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822099#comment-17822099 ] Roman Puchkovskiy commented on IGNITE-20373: Stripization of the Inbound pool is split to IGNITE-21626. Same for the Outbound thread: IGNITE-21627 > Fix IO threading model > -- > > Key: IGNITE-20373 > URL: https://issues.apache.org/jira/browse/IGNITE-20373 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3, ignite3_performance, threading > Fix For: 3.0.0-beta2 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently IO is resubmitted to inboundExecutor for further processing (even > there are corner cases then a message handler called in IO thread) > It makes message processing essentially single threaded and introduces > additional lag due to message transition to additional queue. > addMessageHandler should be extended with a 3-d argument: a pool for > submitting a callback for execution, or an executorSelector like in jraft. > inboundExecutor should be changed to striped, use more than one thread, and > serve messages without explicit executor. Delivery guaranties should be > preserved: if a message A is send before B, B can't be processed on a > receiver before A. A stripe is defined by sender-receiver pair (or can be > user defined - TBD) > outboundExecutor also looks like a contention point - need to be addressed as > well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21632) Upgrade PMD up to latest version
Viacheslav Blinov created IGNITE-21632: -- Summary: Upgrade PMD up to latest version Key: IGNITE-21632 URL: https://issues.apache.org/jira/browse/IGNITE-21632 Project: Ignite Issue Type: Improvement Reporter: Viacheslav Blinov Assignee: Viacheslav Blinov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21631) Downgrade msgpack to 0.8.24
[ https://issues.apache.org/jira/browse/IGNITE-21631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822080#comment-17822080 ] Roman Puchkovskiy commented on IGNITE-21631: Thanks! > Downgrade msgpack to 0.8.24 > --- > > Key: IGNITE-21631 > URL: https://issues.apache.org/jira/browse/IGNITE-21631 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > After commit > [https://github.com/apache/ignite-3/commit/1b85f8fe87a79caf9e88926f5d859cf01ade12b5] > an attempt to create a shadowjar fails. The following command > n ./gradlew build publishToMavenLocal --exclude-task test --exclude-task > integrationTest --exclude-task check --exclude-task > :platforms:cmakeConfigureOdbc --exclude-task :platforms:cmakeBuildOdbc > results in the following exception: > java.lang.IllegalArgumentException: Unsupported class file major version 65 > when run on Java 11. > This means that either new msgpack or one of its dependencies is built with > targetVersion=21. > The highest version that works is 0.8.24, so it makes sense to downgrade to > it for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20296) Make a network message handler that would be able to accept ClusterNode as a sender
[
https://issues.apache.org/jira/browse/IGNITE-20296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy reassigned IGNITE-20296:
--
Assignee: Roman Puchkovskiy
> Make a network message handler that would be able to accept ClusterNode as a
> sender
> ---
>
> Key: IGNITE-20296
> URL: https://issues.apache.org/jira/browse/IGNITE-20296
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> With {{MessagingService}} we have an ability to send message using
> {{ClusterNode}} to specify a recipient. But in {{NetworkMessageHandler}} we
> have only ability to receive consistent id of a sender. However, in some
> cases we need node id (for example, knowing that there is no node we the
> given id in a cluster, allows us to not send message there at all, because
> this node has left the topology at least once since it had sent this message
> and therefore this node lost its volatile state)
> Also, the node id should go along with consistent id, so
> {color:#172b4d}{{ClusterNode}} {color}as the argument type is preferred.
> *Definition of done*
> The following interface is available:
> {code:java}
> public interface NetworkMessageHandler {
> /**
> * Method that gets invoked when a network message is received.
> *
> * @param message Message, which was received from the cluster.
> * @param sender Sender node.
> * @param correlationId Correlation id. Used to track correspondence
> between requests and responses. Can be {@code null} if the received
> * message is not a request from a {@link MessagingService#invoke}
> method from another node.
> */
> void onReceived(NetworkMessage message, ClusterNode sender, @Nullable
> Long correlationId);
> } {code}
> Also, the {{MessagingService}} is able to accept an object implementing this
> interface as a message handler.
> *Implementation notes*
> The ClusterNode passed as a sender should have a node id which the sender
> node had at the moment the message was sent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-21631) Downgrade msgpack to 0.8.24
[ https://issues.apache.org/jira/browse/IGNITE-21631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-21631. - Resolution: Fixed > Downgrade msgpack to 0.8.24 > --- > > Key: IGNITE-21631 > URL: https://issues.apache.org/jira/browse/IGNITE-21631 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > After commit > [https://github.com/apache/ignite-3/commit/1b85f8fe87a79caf9e88926f5d859cf01ade12b5] > an attempt to create a shadowjar fails. The following command > n ./gradlew build publishToMavenLocal --exclude-task test --exclude-task > integrationTest --exclude-task check --exclude-task > :platforms:cmakeConfigureOdbc --exclude-task :platforms:cmakeBuildOdbc > results in the following exception: > java.lang.IllegalArgumentException: Unsupported class file major version 65 > when run on Java 11. > This means that either new msgpack or one of its dependencies is built with > targetVersion=21. > The highest version that works is 0.8.24, so it makes sense to downgrade to > it for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21631) Downgrade msgpack to 0.8.24
[ https://issues.apache.org/jira/browse/IGNITE-21631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822074#comment-17822074 ] Pavel Tupitsyn commented on IGNITE-21631: - Merged to main: 71b4fb3478f412dba6536948e749f36ca9fd4460 [~rpuch] thank you! > Downgrade msgpack to 0.8.24 > --- > > Key: IGNITE-21631 > URL: https://issues.apache.org/jira/browse/IGNITE-21631 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > After commit > [https://github.com/apache/ignite-3/commit/1b85f8fe87a79caf9e88926f5d859cf01ade12b5] > an attempt to create a shadowjar fails. The following command > n ./gradlew build publishToMavenLocal --exclude-task test --exclude-task > integrationTest --exclude-task check --exclude-task > :platforms:cmakeConfigureOdbc --exclude-task :platforms:cmakeBuildOdbc > results in the following exception: > java.lang.IllegalArgumentException: Unsupported class file major version 65 > when run on Java 11. > This means that either new msgpack or one of its dependencies is built with > targetVersion=21. > The highest version that works is 0.8.24, so it makes sense to downgrade to > it for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21585) Disable catalog compaction
[ https://issues.apache.org/jira/browse/IGNITE-21585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-21585: -- Fix Version/s: 3.0.0-beta2 > Disable catalog compaction > -- > > Key: IGNITE-21585 > URL: https://issues.apache.org/jira/browse/IGNITE-21585 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Catalog compaction is not synchronized with transactions on nodes. > There are a bunch of issues: > * We expect Catalog compaction should be called for minimal LWM on all the > nodes. But LWM is node-local value. > * Recovery RW transaction may require old catalog version to get list of > indexes, that should be updated. > * incoming snapshot may require outdated version of catalog in some cases. > * LWM wait for RO transaction, but not RW. > So, > 1. Let's just do nothing with catalog history on compaction. > 2. Let's node update some key in the metastorage and put it's id. Make node > will react on it's own updates only. On the key update event, node should > trigger destroy event for table/index, which are under the LWM. > We can't trigger local events instead, because we need a causality token for > VV in several components. > 2. Fix recovery procedure if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21631) Downgrade msgpack to 0.8.24
Roman Puchkovskiy created IGNITE-21631: -- Summary: Downgrade msgpack to 0.8.24 Key: IGNITE-21631 URL: https://issues.apache.org/jira/browse/IGNITE-21631 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 After commit [https://github.com/apache/ignite-3/commit/1b85f8fe87a79caf9e88926f5d859cf01ade12b5] an attempt to create a shadowjar fails. The following command n ./gradlew build publishToMavenLocal --exclude-task test --exclude-task integrationTest --exclude-task check --exclude-task :platforms:cmakeConfigureOdbc --exclude-task :platforms:cmakeBuildOdbc results in the following exception: java.lang.IllegalArgumentException: Unsupported class file major version 65 when run on Java 11. This means that either new msgpack or one of its dependencies is built with targetVersion=21. The highest version that works is 0.8.24, so it makes sense to downgrade to it for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21630) Cluster falls apart on topology change when DNS service is unavailable
Aleksey Plekhanov created IGNITE-21630:
--
Summary: Cluster falls apart on topology change when DNS service
is unavailable
Key: IGNITE-21630
URL: https://issues.apache.org/jira/browse/IGNITE-21630
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Requests to DNS service performed synchroniously by some critical discovery
threads. Timeout for such requests can't be controlled by java code (see
[https://bugs.openjdk.org/browse/JDK-6450279]). This leads to segmentation of
nodes and falling apart cluster.
For example, stack of {{tcp-disco-msg-worker}} thread with request to DNS
service:
{noformat}
at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1330)
at java.net.InetAddress.getAllByName0(InetAddress.java:1283)
at java.net.InetAddress.getAllByName(InetAddress.java:1199)
at java.net.InetAddress.getAllByName(InetAddress.java:1127)
at java.net.InetAddress.getByName(InetAddress.java:1077)
at java.net.InetSocketAddress.(InetSocketAddress.java:220)
at
org.apache.ignite.internal.util.IgniteUtils.createResolved(IgniteUtils.java:9829)
at
org.apache.ignite.internal.util.IgniteUtils.toSocketAddresses(IgniteUtils.java:9792)
at
org.apache.ignite.internal.util.IgniteUtils.toSocketAddresses(IgniteUtils.java:9770)
at
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNode.socketAddresses(TcpDiscoveryNode.java:392)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.getNodeAddresses(TcpDiscoverySpi.java:1267)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.interruptPing(ServerImpl.java:985)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.access$6800(ServerImpl.java:206)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeLeftMessage(ServerImpl.java:5433)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:3221)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2894)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21609) Avoid using versioned values for non-versioned objects
[ https://issues.apache.org/jira/browse/IGNITE-21609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-21609: -- Fix Version/s: 3.0.0-beta2 (was: 3.0) > Avoid using versioned values for non-versioned objects > -- > > Key: IGNITE-21609 > URL: https://issues.apache.org/jira/browse/IGNITE-21609 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > As of now, TableManager/IndexManager misuses VersionedValue while holding > non-versioned objects, e.g. table instances, partitions, assignments and etc. > Actually, we need > 1. the latest value, but not a history, which is size of 10 entries by > default. > 2. a future for synchronization purposes with ongoing metastorage operation. > Also, VV requires a metastorage token for update. > Local operations, like table/index destruction, do NOT have any token and are > executed out of metastorage context, because such operations should block > metastorage and further metadata elovution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21437) Add listenAddress configuration setting
[ https://issues.apache.org/jira/browse/IGNITE-21437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis updated IGNITE-21437: --- Summary: Add listenAddress configuration setting (was: Add bindHost configuration setting) > Add listenAddress configuration setting > --- > > Key: IGNITE-21437 > URL: https://issues.apache.org/jira/browse/IGNITE-21437 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Currently, we do not choose any specific interface when binding, so we bind > to all interfaces. > bindHost (we should think whether this is the best name and choose another if > not) should be added to NetworkConfigurationSchema to allow to choose a local > interface to which to bind. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21623) Test fails ItTxDistributedTestThreeNodesThreeReplicas.testBatchSinglePartitionGet
[
https://issues.apache.org/jira/browse/IGNITE-21623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822006#comment-17822006
]
Vladislav Pyatkov commented on IGNITE-21623:
Here is the test history
https://ci.ignite.apache.org/test/530545554222388187?currentProjectId=ApacheIgnite3xGradle_Test_IntegrationTests=true
> Test fails
> ItTxDistributedTestThreeNodesThreeReplicas.testBatchSinglePartitionGet
> -
>
> Key: IGNITE-21623
> URL: https://issues.apache.org/jira/browse/IGNITE-21623
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Table_20271.log (1).zip
>
>
> The test fails very rarely, but this is a violation of transaction
> guarantees. This test fails to get committed entries:
> {code}
> for (Tuple tuple : accountRecordsView.getAll(null, keys.stream().map(k ->
> makeKey(k)).collect(toList( {
> assertEquals(100., tuple.doubleValue("balance"));
> }
> {code}
> Instead, NPE is received:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.table.TxAbstractTest.testBatchSinglePartitionGet(TxAbstractTest.java:2274)
> 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)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21629) Add TLSv1_3 to o.a.i.client.SslProtocol
[ https://issues.apache.org/jira/browse/IGNITE-21629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21629: Description: *TLSv1_3* will be used automatically when supported by the JDK if you keep the default *SslProtocol.TLS* in *ClientConfiguration*. However, it is not possible to specify explicitly - we should add a enum entry to *SslProtocol*. > Add TLSv1_3 to o.a.i.client.SslProtocol > --- > > Key: IGNITE-21629 > URL: https://issues.apache.org/jira/browse/IGNITE-21629 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Pavel Tupitsyn >Priority: Major > Fix For: 2.17 > > > *TLSv1_3* will be used automatically when supported by the JDK if you keep > the default *SslProtocol.TLS* in *ClientConfiguration*. However, it is not > possible to specify explicitly - we should add a enum entry to *SslProtocol*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21629) Add TLSv1_3 to o.a.i.client.SslProtocol
Pavel Tupitsyn created IGNITE-21629: --- Summary: Add TLSv1_3 to o.a.i.client.SslProtocol Key: IGNITE-21629 URL: https://issues.apache.org/jira/browse/IGNITE-21629 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Pavel Tupitsyn Fix For: 2.17 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21611) Sending in a snapshot for BUILDING indexes the next RowId to build on a full state transfer
[ https://issues.apache.org/jira/browse/IGNITE-21611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-21611: Assignee: Kirill Tkalenko > Sending in a snapshot for BUILDING indexes the next RowId to build on a full > state transfer > --- > > Key: IGNITE-21611 > URL: https://issues.apache.org/jira/browse/IGNITE-21611 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > For consistency, we need to send in a snapshot for all indexes in status > BUILDING their next *RowId* to build > (*org.apache.ignite.internal.storage.index.IndexStorage#getNextRowIdToBuild*). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (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
]
Vladislav Pyatkov resolved IGNITE-21541.
Resolution: Duplicate
> 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] [Commented] (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:comment-tabpanel=17821989#comment-17821989
]
Vladislav Pyatkov commented on IGNITE-21541:
The issue with thread switching in the replica manager is also fixed in
IGNITE-20373.
> 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)
