[jira] [Updated] (IGNITE-18075) Improve snapshot creation check of the streaming updates.
[ https://issues.apache.org/jira/browse/IGNITE-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-18075: -- Summary: Improve snapshot creation check of the streaming updates. (was: Improve snapshot creation check for the streaming updates.) > Improve snapshot creation check of the streaming updates. > - > > Key: IGNITE-18075 > URL: https://issues.apache.org/jira/browse/IGNITE-18075 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > > The snapshot warning of concurrent DataStreamer updates might be extended > with quick partitions checking (like counters and size) to cover the case > when streamer failed or canceled before the snapshot creation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18076) Store snapshot creation warnings.
[ https://issues.apache.org/jira/browse/IGNITE-18076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-18076: -- Labels: ise (was: ) > Store snapshot creation warnings. > - > > Key: IGNITE-18076 > URL: https://issues.apache.org/jira/browse/IGNITE-18076 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > > We could store warnings of snapshot creation process (probably in the > snapshot metals) and show them at snapshot validation/restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18076) Store snapshot creation warnings.
Vladimir Steshin created IGNITE-18076: - Summary: Store snapshot creation warnings. Key: IGNITE-18076 URL: https://issues.apache.org/jira/browse/IGNITE-18076 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin We could store warnings of snapshot creation process (probably in the snapshot metals) and show them at snapshot validation/restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18075) Improve snapshot creation check for the streaming updates.
Vladimir Steshin created IGNITE-18075: - Summary: Improve snapshot creation check for the streaming updates. Key: IGNITE-18075 URL: https://issues.apache.org/jira/browse/IGNITE-18075 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin The snapshot warning of concurrent DataStreamer updates might be extended with quick partitions checking (like counters and size) to cover the case when streamer failed or canceled before the snapshot creation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18075) Improve snapshot creation check for the streaming updates.
[ https://issues.apache.org/jira/browse/IGNITE-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-18075: -- Labels: ise (was: ) > Improve snapshot creation check for the streaming updates. > -- > > Key: IGNITE-18075 > URL: https://issues.apache.org/jira/browse/IGNITE-18075 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Priority: Major > Labels: ise > > The snapshot warning of concurrent DataStreamer updates might be extended > with quick partitions checking (like counters and size) to cover the case > when streamer failed or canceled before the snapshot creation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18074) Cluster fail during restart with "lock hold by current process"
[
https://issues.apache.org/jira/browse/IGNITE-18074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov updated IGNITE-18074:
Fix Version/s: 3.0.0-beta2
> Cluster fail during restart with "lock hold by current process"
> ---
>
> Key: IGNITE-18074
> URL: https://issues.apache.org/jira/browse/IGNITE-18074
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> To reproduce the issue try to start {{ItSqlLogicTest}} with restart policy
> {{FOLDER}} ({{@SqlLogicTestEnvironment(scriptsRoot =
> "src/integrationTest/sql", restart = RestartMode.FOLDER}}).
> After a number of tests, the cluster will try to restart and will fail with
> {code:java}
> 2022-11-02 16:46:17:120 +0300 [INFO][vault1][ConfigurationRegistry] Failed to
> notify configuration listener
> org.apache.ignite.internal.configuration.storage.StorageException: Could not
> create transaction state storage for the table TEST
> at
> org.apache.ignite.internal.tx.storage.state.rocksdb.TxStateRocksDbTableStorage.start(TxStateRocksDbTableStorage.java:228)
> at
> org.apache.ignite.internal.table.distributed.TableManager.createTxStateTableStorage(TableManager.java:1097)
> at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1036)
> at
> org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:546)
> at
> org.apache.ignite.internal.table.distributed.TableManager$1.onCreate(TableManager.java:453)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyPublicListeners(ConfigurationNotifier.java:492)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$1.visitNamedListNode(ConfigurationNotifier.java:205)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$1.visitNamedListNode(ConfigurationNotifier.java:128)
> at
> org.apache.ignite.internal.schema.configuration.TablesNode.traverseChildren(Unknown
> Source)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyListeners(ConfigurationNotifier.java:128)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyListeners(ConfigurationNotifier.java:90)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistry$2.visitInnerNode(ConfigurationRegistry.java:310)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistry$2.visitInnerNode(ConfigurationRegistry.java:292)
> at
> org.apache.ignite.internal.configuration.SuperRoot.traverseChildren(SuperRoot.java:103)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistry.notificator(ConfigurationRegistry.java:292)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.lambda$updateFromListener$9(ConfigurationChanger.java:596)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1742)
> 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: org.rocksdb.RocksDBException: lock hold by current process,
> acquire time 1667396766 acquiring thread 140316046616320:
> target/work/ItSqlLogicTest/static_2241337451960107/sqllogic0/db/tx-state-1/LOCK:
> No locks available
> at org.rocksdb.RocksDB.open(Native Method)
> at org.rocksdb.RocksDB.open(RocksDB.java:307)
> at
> org.apache.ignite.internal.tx.storage.state.rocksdb.TxStateRocksDbTableStorage.start(TxStateRocksDbTableStorage.java:224)
> ... 21 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18074) Cluster fail during restart with "lock hold by current process"
[
https://issues.apache.org/jira/browse/IGNITE-18074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov reassigned IGNITE-18074:
---
Assignee: Semyon Danilov
> Cluster fail during restart with "lock hold by current process"
> ---
>
> Key: IGNITE-18074
> URL: https://issues.apache.org/jira/browse/IGNITE-18074
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
>
> To reproduce the issue try to start {{ItSqlLogicTest}} with restart policy
> {{FOLDER}} ({{@SqlLogicTestEnvironment(scriptsRoot =
> "src/integrationTest/sql", restart = RestartMode.FOLDER}}).
> After a number of tests, the cluster will try to restart and will fail with
> {code:java}
> 2022-11-02 16:46:17:120 +0300 [INFO][vault1][ConfigurationRegistry] Failed to
> notify configuration listener
> org.apache.ignite.internal.configuration.storage.StorageException: Could not
> create transaction state storage for the table TEST
> at
> org.apache.ignite.internal.tx.storage.state.rocksdb.TxStateRocksDbTableStorage.start(TxStateRocksDbTableStorage.java:228)
> at
> org.apache.ignite.internal.table.distributed.TableManager.createTxStateTableStorage(TableManager.java:1097)
> at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1036)
> at
> org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:546)
> at
> org.apache.ignite.internal.table.distributed.TableManager$1.onCreate(TableManager.java:453)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyPublicListeners(ConfigurationNotifier.java:492)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$1.visitNamedListNode(ConfigurationNotifier.java:205)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$1.visitNamedListNode(ConfigurationNotifier.java:128)
> at
> org.apache.ignite.internal.schema.configuration.TablesNode.traverseChildren(Unknown
> Source)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyListeners(ConfigurationNotifier.java:128)
> at
> org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyListeners(ConfigurationNotifier.java:90)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistry$2.visitInnerNode(ConfigurationRegistry.java:310)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistry$2.visitInnerNode(ConfigurationRegistry.java:292)
> at
> org.apache.ignite.internal.configuration.SuperRoot.traverseChildren(SuperRoot.java:103)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistry.notificator(ConfigurationRegistry.java:292)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.lambda$updateFromListener$9(ConfigurationChanger.java:596)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1742)
> 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: org.rocksdb.RocksDBException: lock hold by current process,
> acquire time 1667396766 acquiring thread 140316046616320:
> target/work/ItSqlLogicTest/static_2241337451960107/sqllogic0/db/tx-state-1/LOCK:
> No locks available
> at org.rocksdb.RocksDB.open(Native Method)
> at org.rocksdb.RocksDB.open(RocksDB.java:307)
> at
> org.apache.ignite.internal.tx.storage.state.rocksdb.TxStateRocksDbTableStorage.start(TxStateRocksDbTableStorage.java:224)
> ... 21 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17734) CorruptedFreeListException after upgrade to 2.13.0 and JDK17
[ https://issues.apache.org/jira/browse/IGNITE-17734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17628059#comment-17628059 ] YuJue Li commented on IGNITE-17734: --- The issue is not exist in Ignite 2.12 + JDK17. So, the issue is Ignite 2.13's bug. > CorruptedFreeListException after upgrade to 2.13.0 and JDK17 > > > Key: IGNITE-17734 > URL: https://issues.apache.org/jira/browse/IGNITE-17734 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.13 > Environment: JDK17, IGNITE 2.13.0 >Reporter: Lopata >Priority: Minor > Attachments: stacktrace.txt > > > After migration to Ignite version 2.13.0 from 2.12.0 we are getting following > error: > org.apache.ignite.internal.processors.cache.persistence.freelist.CorruptedFreeListException: > Failed to insert data row > caused by: > Caused by: java.lang.IllegalStateException: Tail not found: 0 > > Full stack trace is in attachment. Along with the Ignite version upgrade, we > are updating Java from 11 to 17. There have been no other changes in our code > or IGNITE configurations. The error occurs after a few hours of running and > then occurs for every store. > Can you help us to to solve this problem. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17734) CorruptedFreeListException after upgrade to 2.13.0 and JDK17
[ https://issues.apache.org/jira/browse/IGNITE-17734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YuJue Li updated IGNITE-17734: -- Priority: Major (was: Minor) > CorruptedFreeListException after upgrade to 2.13.0 and JDK17 > > > Key: IGNITE-17734 > URL: https://issues.apache.org/jira/browse/IGNITE-17734 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.13 > Environment: JDK17, IGNITE 2.13.0 >Reporter: Lopata >Priority: Major > Attachments: stacktrace.txt > > > After migration to Ignite version 2.13.0 from 2.12.0 we are getting following > error: > org.apache.ignite.internal.processors.cache.persistence.freelist.CorruptedFreeListException: > Failed to insert data row > caused by: > Caused by: java.lang.IllegalStateException: Tail not found: 0 > > Full stack trace is in attachment. Along with the Ignite version upgrade, we > are updating Java from 11 to 17. There have been no other changes in our code > or IGNITE configurations. The error occurs after a few hours of running and > then occurs for every store. > Can you help us to to solve this problem. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17995) Idle_verify must print broken partitions list
[
https://issues.apache.org/jira/browse/IGNITE-17995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627890#comment-17627890
]
Ignite TC Bot commented on IGNITE-17995:
{panel:title=Branch: [pull/10359/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10359/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=6886908buildTypeId=IgniteTests24Java8_RunAll]
> Idle_verify must print broken partitions list
> -
>
> Key: IGNITE-17995
> URL: https://issues.apache.org/jira/browse/IGNITE-17995
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, idle_verify provides per partition information, but not just a set
> of broken partitions.
> So, additional actions is necessary to get the list required by consistency
> repair tool.
> {noformat}
> idle_verify task was executed with the following args: caches=[],
> excluded=[], cacheFilter=[DEFAULT]
> idle_verify check has finished, found XXX conflict partitions:
> [counterConflicts=0, hashConflicts=XXX]
> Hash conflicts:
> Conflict partition: PartitionKeyV2 [grpId=CacheGroup1,
> grpName=CacheGroup1Cache, partId=600]
> ...
> Control utility [ver. XXX]
> 2021 Copyright(C) Apache Software Foundation
> User: xxx
> Time: XXX
>
>
>
> Command [CACHE] finished with code: 0
> Control utility has completed execution at: XXX
> Execution time: XXX ms
> {noformat}
> Let's, in addition to detailed view, provide such lists.
> Something like:
> {noformat}
> Total:
> CacheGroup1 (18/1024)
> 1,7,42,987,99
> CacheGroup2 (15/1024)
> 5,14,17,850,900
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18074) Cluster fail during restart with "lock hold by current process"
Konstantin Orlov created IGNITE-18074:
-
Summary: Cluster fail during restart with "lock hold by current
process"
Key: IGNITE-18074
URL: https://issues.apache.org/jira/browse/IGNITE-18074
Project: Ignite
Issue Type: Bug
Reporter: Konstantin Orlov
To reproduce the issue try to start {{ItSqlLogicTest}} with restart policy
{{FOLDER}} ({{@SqlLogicTestEnvironment(scriptsRoot = "src/integrationTest/sql",
restart = RestartMode.FOLDER}}).
After a number of tests, the cluster will try to restart and will fail with
{code:java}
2022-11-02 16:46:17:120 +0300 [INFO][vault1][ConfigurationRegistry] Failed to
notify configuration listener
org.apache.ignite.internal.configuration.storage.StorageException: Could not
create transaction state storage for the table TEST
at
org.apache.ignite.internal.tx.storage.state.rocksdb.TxStateRocksDbTableStorage.start(TxStateRocksDbTableStorage.java:228)
at
org.apache.ignite.internal.table.distributed.TableManager.createTxStateTableStorage(TableManager.java:1097)
at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1036)
at
org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:546)
at
org.apache.ignite.internal.table.distributed.TableManager$1.onCreate(TableManager.java:453)
at
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyPublicListeners(ConfigurationNotifier.java:492)
at
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$1.visitNamedListNode(ConfigurationNotifier.java:205)
at
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$1.visitNamedListNode(ConfigurationNotifier.java:128)
at
org.apache.ignite.internal.schema.configuration.TablesNode.traverseChildren(Unknown
Source)
at
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyListeners(ConfigurationNotifier.java:128)
at
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyListeners(ConfigurationNotifier.java:90)
at
org.apache.ignite.internal.configuration.ConfigurationRegistry$2.visitInnerNode(ConfigurationRegistry.java:310)
at
org.apache.ignite.internal.configuration.ConfigurationRegistry$2.visitInnerNode(ConfigurationRegistry.java:292)
at
org.apache.ignite.internal.configuration.SuperRoot.traverseChildren(SuperRoot.java:103)
at
org.apache.ignite.internal.configuration.ConfigurationRegistry.notificator(ConfigurationRegistry.java:292)
at
org.apache.ignite.internal.configuration.ConfigurationChanger.lambda$updateFromListener$9(ConfigurationChanger.java:596)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1742)
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: org.rocksdb.RocksDBException: lock hold by current process, acquire
time 1667396766 acquiring thread 140316046616320:
target/work/ItSqlLogicTest/static_2241337451960107/sqllogic0/db/tx-state-1/LOCK:
No locks available
at org.rocksdb.RocksDB.open(Native Method)
at org.rocksdb.RocksDB.open(RocksDB.java:307)
at
org.apache.ignite.internal.tx.storage.state.rocksdb.TxStateRocksDbTableStorage.start(TxStateRocksDbTableStorage.java:224)
... 21 more
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18073) Add indexes to for full rebalance without losing user data in MvPartitionStorage on receiver
Kirill Tkalenko created IGNITE-18073: Summary: Add indexes to for full rebalance without losing user data in MvPartitionStorage on receiver Key: IGNITE-18073 URL: https://issues.apache.org/jira/browse/IGNITE-18073 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 Indexes were forgotten in the API from IGNITE-18021. We also need to fix the test implementation and tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18058) .NET: Thin 3.0: Socket read never times out
[ https://issues.apache.org/jira/browse/IGNITE-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627818#comment-17627818 ] Pavel Tupitsyn commented on IGNITE-18058: - Merged to main: 0fd6cfce899cfba159d2f11f165b62309c4d2609 > .NET: Thin 3.0: Socket read never times out > --- > > Key: IGNITE-18058 > URL: https://issues.apache.org/jira/browse/IGNITE-18058 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > If the server does not respond, we hang forever in > *ClientSocket.ReceiveBytesAsync*. > We have *IgniteClientConfiguration.SocketTimeout*, but it is not actually > used anywhere. > While most client operations can take any amount of time (data retrieval and > update, etc), some operations should complete within the timeout: > * Handshake > * Heartbeat -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17775) Invalid data in network buffers causes message deserialization errors and messages loss
[
https://issues.apache.org/jira/browse/IGNITE-17775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627764#comment-17627764
]
Roman Puchkovskiy commented on IGNITE-17775:
For now, we only make the behavior more consistent (throw a
{{NetworkConfigurationException}} for negative group/messageType as well).
Further development might happen in IGNITE-18072
> Invalid data in network buffers causes message deserialization errors and
> messages loss
> ---
>
> Key: IGNITE-17775
> URL: https://issues.apache.org/jira/browse/IGNITE-17775
> Project: Ignite
> Issue Type: Bug
> Components: networking
>Reporter: Denis Chudov
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
>
> h3. TL;DR
> Message serialization registry behavior is inconsistent, it either throws an
> AssertionError or NetworkConfigurationException if factory is not found.
> There should be only one. This will simplify debugging situations where one
> forgot to register a factory in the registry, as it's the case in the problem
> below. There's no actual bug in messaging and mentioned exception is
> impossible to get in normal circumstances.
> h3. Original description
> In some tests I observe network messages' deserialization errors and timeout
> exceptions while waiting for response. In some cases there is negative group
> type of the message, and this causes error:
> {code:java}
> java.lang.AssertionError: message type must not be negative, messageType=-5376
> at
> org.apache.ignite.network.MessageSerializationRegistryImpl.getFactory(MessageSerializationRegistryImpl.java:77)
> at
> org.apache.ignite.network.MessageSerializationRegistryImpl.createDeserializer(MessageSerializationRegistryImpl.java:102)
> at
> org.apache.ignite.internal.network.serialization.SerializationService.createDeserializer(SerializationService.java:68)
> at
> org.apache.ignite.internal.network.serialization.PerSessionSerializationService.createMessageDeserializer(PerSessionSerializationService.java:109)
> at
> org.apache.ignite.internal.network.netty.InboundDecoder.decode(InboundDecoder.java:89)
> at
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:507)
> at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:446)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> {code}
> When the group or message type is positive but not existing, there should be
> a NetworkConfigurationException but it's not displayed in logs, however, it
> causes TimeoutExceptions because of messages loss.
> This reproduces in
> [https://github.com/gridgain/apache-ignite-3/tree/ignite-17523-2] in
> ItTablesApiTest#testGetTableFromLaggedNode
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17930) Add javadoc plugin to gradle build
[ https://issues.apache.org/jira/browse/IGNITE-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627748#comment-17627748 ] Aleksandr commented on IGNITE-17930: The standard approach to generate javadoc for Gradle projects is `javadoc` task that is provided by the java plugin. Now this task cannot be applied to the sources because it has multiple failures caused by the linter. Fixing this might introduce a lot of changes into the source code. Merging those changes into beta1 branch might be difficult now. But there is an option that could disable the linter. Another issue with this plugin is that it could not generate aggregated javadoc for multiple Gradle project. For this purpose, the `io.freefair.aggregate-javadoc` could be used. But in this case, we cannot disable the linter because of the bug in this plugin. I would suggest using the existing maven javadoc generation task for beta1, fixing all linter issues in the main branch, and after that using aggregated javadoc task provided by gradle. > Add javadoc plugin to gradle build > -- > > Key: IGNITE-17930 > URL: https://issues.apache.org/jira/browse/IGNITE-17930 > Project: Ignite > Issue Type: Task > Components: build >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Maven build allows us to generate Javadoc from sources but Gradle does not. > We have to add Javadoc generation task to the Gradle build and adjust > DEVNOTES.md. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18072) Help diagnose situations when a sender sends an incomplete message
Roman Puchkovskiy created IGNITE-18072: -- Summary: Help diagnose situations when a sender sends an incomplete message Key: IGNITE-18072 URL: https://issues.apache.org/jira/browse/IGNITE-18072 Project: Ignite Issue Type: Improvement Components: networking Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 The following scenario is possible. # Due to a misconfiguration, some required serializer is not registered # A message starts to be written, namely its groupId and messageTypeId are written # Now we try to write the message (probably we write some part of it), but this fails with an exception due to a missing serializer. So the message is only partly written # Next message is written successfully # The receiver tries to read first message. It has no idea that only part of it is written, so it also consumes the beginning of the next message. The first message is read incorrectly, but we don't know this yet # The receiver tries to read second message (starting somewhere in the middle of its bytes). This usually causes an assertion of an exception due to a missing groupId/messageTypeId, or, if we have (bad) luck, this can lead to reading a wrong message (that was never sent) # Sooner or later, an exception happens on the receiving side, but its message will be misleading This might make diagnosing 'what happened' by looking at the receiver's logs problematic. We could add an additional step: before writing the message groupId+messageTypeId, visit the message (including its parts) and check that all serializers are registered. If not, write some special marker (like short -1) followed by groupId+messageTypeId and nothing more for this message (then throw an exception). The receiving side will be able to interpret this as 'no serializer' situation and log an appropriate diagnostic message before throing an exception. This situation mostly happens at development time, so we could only enable this additional screening step when we are in the development mode (for example, when assertions are enabled). This could also relate to rolling upgrades. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17648) Extract striped executor from memory restore to separate class
[
https://issues.apache.org/jira/browse/IGNITE-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627738#comment-17627738
]
Ignite TC Bot commented on IGNITE-17648:
{panel:title=Branch: [pull/10353/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10353/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6877990buildTypeId=IgniteTests24Java8_RunAll]
> Extract striped executor from memory restore to separate class
> ---
>
> Key: IGNITE-17648
> URL: https://issues.apache.org/jira/browse/IGNITE-17648
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-89, ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Extract striped executor for applying WAL entries from
> GridCacheDatabaseSharedManager#performBinaryMemoryRestore to separate class.
> Then it will be possible to re-use this executor for restoring incremental
> snapshot.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627715#comment-17627715
]
Anton Vinogradov edited comment on IGNITE-17865 at 11/2/22 1:53 PM:
[~slava.koptilin]
{code:java}
Starting rebalance routine [cache, topVer=AffinityTopologyVersion [topVer=4,
minorTopVer=0], supplier=d822f1cd-f36e-4be3-bb4c-c7a80b70,
fullPartitions=[0-511], histPartitions=[], rebalanceId=1]
{code}
1) 0-511 will never happen. Even 0-4,9-15,etc.
It's imposible to have sequence longer than 3 in real world.
Such optimisation does nothing heplful in real world.
2) How are you going to search for partition's 433 fate in this case?
3) As to the property.
Okey, you turned it on. Sh*t happened, and we're now at question number 2.
Let's get rid of this.
was (Author: av):
[~slava.koptilin]
{code:java}
Starting rebalance routine [cache, topVer=AffinityTopologyVersion [topVer=4,
minorTopVer=0], supplier=d822f1cd-f36e-4be3-bb4c-c7a80b70,
fullPartitions=[0-511], histPartitions=[], rebalanceId=1]
{code}
1) 0-511 will never happen. Even 0-4,9-15,etc.
It's imposible to have sequence longer than 3 in real world.
Such optimisation does nothing heplful in real world.
2) How are you going to search for partition's 433 fate in this case?
3) As to the property.
Okey, you turned it on. Sh*t happened, and we're now at question number 2.
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Attachments: replicated.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:#ff}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:#ff}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
> Partition ranges are formed in _GridToStringBuilder#compact_ method, which is
> used to log of partition lists (except one place with exception and tests).
> Below are such places (without usages in tests):
> # {_}GridClientPartitionTopology#resetOwners{_}:
> [L1311|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1311],
>
> [L1312|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1312]
> (WARN)
> # {_}GridDhtPartitionDemander#handleSupplyMessage{_}:
> [L561|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L561]
> (ERROR)
> # {_}GridDhtPartitionDemander.RebalanceFuture#requestPartitions0{_}:
> [L1434|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1434],
>
> [L1435|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1435]
> (INFO)
> # {_}GridDhtPartitionsExchangeFuture#printPartitionRebalancingFully{_}:
>
[jira] [Reopened] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov reopened IGNITE-17916: > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: important, ise > Fix For: 2.15 > > Time Spent: 1.5h > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to *break > changes* of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17916: --- Fix Version/s: (was: 2.15) > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: important, ise > Time Spent: 1.5h > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to *break > changes* of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627715#comment-17627715
]
Anton Vinogradov edited comment on IGNITE-17865 at 11/2/22 1:39 PM:
[~slava.koptilin]
{code:java}
Starting rebalance routine [cache, topVer=AffinityTopologyVersion [topVer=4,
minorTopVer=0], supplier=d822f1cd-f36e-4be3-bb4c-c7a80b70,
fullPartitions=[0-511], histPartitions=[], rebalanceId=1]
{code}
1) 0-511 will never happen. Even 0-4,9-15,etc.
It's imposible to have sequence longer than 3 in real world.
Such optimisation does nothing heplful in real world.
2) How are you going to search for partition's 433 fate in this case?
3) As to the property.
Okey, you turned it on. Sh*t happened, and we're now at question number 2.
was (Author: av):
[~slava.koptilin]
{code:java}
Starting rebalance routine [cache, topVer=AffinityTopologyVersion [topVer=4,
minorTopVer=0], supplier=d822f1cd-f36e-4be3-bb4c-c7a80b70,
fullPartitions=[0-511], histPartitions=[], rebalanceId=1]
{code}
1) 0-511 will never happen. Even 0-4,9-15,etc.
It's imposible to have sequence longer than 3 in real world.
Such optimisation does nothing heplful in real world.
2) How are you going to serch for partition's 433 fate in this case?
3) As to the property.
Okey, you turned it on. Sh*t happened, and we're now at question number 2.
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Attachments: replicated.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:#ff}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:#ff}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
> Partition ranges are formed in _GridToStringBuilder#compact_ method, which is
> used to log of partition lists (except one place with exception and tests).
> Below are such places (without usages in tests):
> # {_}GridClientPartitionTopology#resetOwners{_}:
> [L1311|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1311],
>
> [L1312|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1312]
> (WARN)
> # {_}GridDhtPartitionDemander#handleSupplyMessage{_}:
> [L561|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L561]
> (ERROR)
> # {_}GridDhtPartitionDemander.RebalanceFuture#requestPartitions0{_}:
> [L1434|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1434],
>
> [L1435|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1435]
> (INFO)
> # {_}GridDhtPartitionsExchangeFuture#printPartitionRebalancingFully{_}:
>
[jira] [Commented] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627715#comment-17627715
]
Anton Vinogradov commented on IGNITE-17865:
---
[~slava.koptilin]
{code:java}
Starting rebalance routine [cache, topVer=AffinityTopologyVersion [topVer=4,
minorTopVer=0], supplier=d822f1cd-f36e-4be3-bb4c-c7a80b70,
fullPartitions=[0-511], histPartitions=[], rebalanceId=1]
{code}
1) 0-511 will never happen. Even 0-4,9-15,etc.
It's imposible to have sequence longer than 3 in real world.
Such optimisation does nothing heplful in real world.
2) How are you going to serch for partition's 433 fate in this case?
3) As to the property.
Okey, you turned it on. Sh*t happened, and we're now at question number 2.
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Attachments: replicated.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:#ff}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:#ff}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
> Partition ranges are formed in _GridToStringBuilder#compact_ method, which is
> used to log of partition lists (except one place with exception and tests).
> Below are such places (without usages in tests):
> # {_}GridClientPartitionTopology#resetOwners{_}:
> [L1311|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1311],
>
> [L1312|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1312]
> (WARN)
> # {_}GridDhtPartitionDemander#handleSupplyMessage{_}:
> [L561|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L561]
> (ERROR)
> # {_}GridDhtPartitionDemander.RebalanceFuture#requestPartitions0{_}:
> [L1434|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1434],
>
> [L1435|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1435]
> (INFO)
> # {_}GridDhtPartitionsExchangeFuture#printPartitionRebalancingFully{_}:
> [L4282|https://github.com/apache/ignite/blob/bc843a5b40a6da0e2bfcb77857bea499ab9a4512/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java#L4282]
> (INFO)
> # {_}GridDhtPartitionSupplier#handleDemandMessage{_}:
> [L276|https://github.com/apache/ignite/blob/00988d20af19485585e98e885c610a704640c083/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionSupplier.java#L276]
> (DEBUG)
> # {_}GridDhtPartitionTopologyImpl#detectLostPartitions{_}:
> [L2281|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridDhtPartitionTopologyImpl.java#L2281]
> (WARN)
> #
[jira] [Updated] (IGNITE-18070) Design the process of having a single storage for a follower and a learner on the same node
[
https://issues.apache.org/jira/browse/IGNITE-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18070:
-
Description:
Secondary Storage consistency is going to be implemented through the Raft
Learners. However, there exists a challenge: what if a partition's Primary
Storage will be assigned to the same node as its Secondary Storage? This means
that both a follower and learner for the same partition will be hosted on a
single node with the same consistent ID. Currently JRaft is not able to
distinguish two nodes with the same consistent ID. There are two ways to solve
this problem:
# Use {{PeerId#idx}} functionality. This is a built-in JRaft mechanism to have
multiple Raft nodes on a single physical nodes.
# Use a single Raft node that will write into multiple storages.
While option 1 is easy and straightforward to implement, this ticket focuses on
investigation of the option 2. The second option has a priority because it is
potentially more effective: since there will be less Raft nodes, there will be
less network traffic. The main problem with this approach is when a leader or a
follower hosted on such physical node gets moved to a different physical node
(or two nodes get merged into one). We should check if this is technically
possible to implement.
> Design the process of having a single storage for a follower and a learner on
> the same node
> ---
>
> Key: IGNITE-18070
> URL: https://issues.apache.org/jira/browse/IGNITE-18070
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Secondary Storage consistency is going to be implemented through the Raft
> Learners. However, there exists a challenge: what if a partition's Primary
> Storage will be assigned to the same node as its Secondary Storage? This
> means that both a follower and learner for the same partition will be hosted
> on a single node with the same consistent ID. Currently JRaft is not able to
> distinguish two nodes with the same consistent ID. There are two ways to
> solve this problem:
> # Use {{PeerId#idx}} functionality. This is a built-in JRaft mechanism to
> have multiple Raft nodes on a single physical nodes.
> # Use a single Raft node that will write into multiple storages.
> While option 1 is easy and straightforward to implement, this ticket focuses
> on investigation of the option 2. The second option has a priority because it
> is potentially more effective: since there will be less Raft nodes, there
> will be less network traffic. The main problem with this approach is when a
> leader or a follower hosted on such physical node gets moved to a different
> physical node (or two nodes get merged into one). We should check if this is
> technically possible to implement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18070) Design the process of having a single storage for a follower and a learner on the same node
[
https://issues.apache.org/jira/browse/IGNITE-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18070:
-
Description:
Secondary Storage consistency is going to be implemented through the Raft
Learners. However, there exists a challenge: what if a partition's Primary
Storage will be assigned to the same node as its Secondary Storage? This means
that both a follower and learner for the same partition will be hosted on a
single node with the same consistent ID. Currently JRaft is not able to
distinguish two nodes with the same consistent ID. There are two ways to solve
this problem:
# Use {{PeerId#idx}} functionality. This is a built-in JRaft mechanism to have
multiple Raft nodes on a single physical nodes.
# Use a single Raft node that will write into multiple storages.
While option 1 is easy and straightforward to implement, this ticket focuses on
investigation of the option 2. The second option has a priority because it is
potentially more effective: since there will be less Raft nodes, there will be
less network traffic. The main problem with this approach is when a learner or
a follower hosted on such physical node gets moved to a different physical node
(or two nodes get merged into one). We should check if this is technically
possible to implement.
was:
Secondary Storage consistency is going to be implemented through the Raft
Learners. However, there exists a challenge: what if a partition's Primary
Storage will be assigned to the same node as its Secondary Storage? This means
that both a follower and learner for the same partition will be hosted on a
single node with the same consistent ID. Currently JRaft is not able to
distinguish two nodes with the same consistent ID. There are two ways to solve
this problem:
# Use {{PeerId#idx}} functionality. This is a built-in JRaft mechanism to have
multiple Raft nodes on a single physical nodes.
# Use a single Raft node that will write into multiple storages.
While option 1 is easy and straightforward to implement, this ticket focuses on
investigation of the option 2. The second option has a priority because it is
potentially more effective: since there will be less Raft nodes, there will be
less network traffic. The main problem with this approach is when a leader or a
follower hosted on such physical node gets moved to a different physical node
(or two nodes get merged into one). We should check if this is technically
possible to implement.
> Design the process of having a single storage for a follower and a learner on
> the same node
> ---
>
> Key: IGNITE-18070
> URL: https://issues.apache.org/jira/browse/IGNITE-18070
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Secondary Storage consistency is going to be implemented through the Raft
> Learners. However, there exists a challenge: what if a partition's Primary
> Storage will be assigned to the same node as its Secondary Storage? This
> means that both a follower and learner for the same partition will be hosted
> on a single node with the same consistent ID. Currently JRaft is not able to
> distinguish two nodes with the same consistent ID. There are two ways to
> solve this problem:
> # Use {{PeerId#idx}} functionality. This is a built-in JRaft mechanism to
> have multiple Raft nodes on a single physical nodes.
> # Use a single Raft node that will write into multiple storages.
> While option 1 is easy and straightforward to implement, this ticket focuses
> on investigation of the option 2. The second option has a priority because it
> is potentially more effective: since there will be less Raft nodes, there
> will be less network traffic. The main problem with this approach is when a
> learner or a follower hosted on such physical node gets moved to a different
> physical node (or two nodes get merged into one). We should check if this is
> technically possible to implement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18071) Thin 3.0: Add heartbeat timeout
[ https://issues.apache.org/jira/browse/IGNITE-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18071: Description: Close connection when the server does not respond to heartbeat in a specified time. > Thin 3.0: Add heartbeat timeout > --- > > Key: IGNITE-18071 > URL: https://issues.apache.org/jira/browse/IGNITE-18071 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Close connection when the server does not respond to heartbeat in a specified > time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18071) Thin 3.0: Add heartbeat timeout
[ https://issues.apache.org/jira/browse/IGNITE-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18071: Ignite Flags: (was: Docs Required,Release Notes Required) > Thin 3.0: Add heartbeat timeout > --- > > Key: IGNITE-18071 > URL: https://issues.apache.org/jira/browse/IGNITE-18071 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Close connection when the server does not respond to heartbeat in a specified > time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18071) Thin 3.0: Add heartbeat timeout
Pavel Tupitsyn created IGNITE-18071: --- Summary: Thin 3.0: Add heartbeat timeout Key: IGNITE-18071 URL: https://issues.apache.org/jira/browse/IGNITE-18071 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17995) Idle_verify must print broken partitions list
[
https://issues.apache.org/jira/browse/IGNITE-17995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627684#comment-17627684
]
Ilya Shishkov edited comment on IGNITE-17995 at 11/2/22 1:28 PM:
-
Extra TC runs (after test fixes) of ControlUtility [1], ControlUtility 2 [2]
and ControlUtility Zookeeper [3] suites. There is the only failure of
{{GridCommandHandlerDefragmentationTest#testDefragmentationStatus}} with 100%
failure rate [4].
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility/6886656?showRootCauses=true=true
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility2/6886658?showRootCauses=true=true=true
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6886660?showRootCauses=true=true
#
https://ci2.ignite.apache.org/test/-8869604011192050851?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true
was (Author: shishkovilja):
Extra control utility suite runs (after test fixes) of ControlUtility [1],
ControlUtility 2 [2] and ControlUtility Zookeeper [3] suites. There is the only
failure of {{GridCommandHandlerDefragmentationTest#testDefragmentationStatus}}
with 100% failure rate [4].
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility/6886656?showRootCauses=true=true
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility2/6886658?showRootCauses=true=true=true
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6886660?showRootCauses=true=true
#
https://ci2.ignite.apache.org/test/-8869604011192050851?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true
> Idle_verify must print broken partitions list
> -
>
> Key: IGNITE-17995
> URL: https://issues.apache.org/jira/browse/IGNITE-17995
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, idle_verify provides per partition information, but not just a set
> of broken partitions.
> So, additional actions is necessary to get the list required by consistency
> repair tool.
> {noformat}
> idle_verify task was executed with the following args: caches=[],
> excluded=[], cacheFilter=[DEFAULT]
> idle_verify check has finished, found XXX conflict partitions:
> [counterConflicts=0, hashConflicts=XXX]
> Hash conflicts:
> Conflict partition: PartitionKeyV2 [grpId=CacheGroup1,
> grpName=CacheGroup1Cache, partId=600]
> ...
> Control utility [ver. XXX]
> 2021 Copyright(C) Apache Software Foundation
> User: xxx
> Time: XXX
>
>
>
> Command [CACHE] finished with code: 0
> Control utility has completed execution at: XXX
> Execution time: XXX ms
> {noformat}
> Let's, in addition to detailed view, provide such lists.
> Something like:
> {noformat}
> Total:
> CacheGroup1 (18/1024)
> 1,7,42,987,99
> CacheGroup2 (15/1024)
> 5,14,17,850,900
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18058) .NET: Thin 3.0: Socket read never times out
[ https://issues.apache.org/jira/browse/IGNITE-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627703#comment-17627703 ] Igor Sapego commented on IGNITE-18058: -- [~ptupitsyn] looks good to me. > .NET: Thin 3.0: Socket read never times out > --- > > Key: IGNITE-18058 > URL: https://issues.apache.org/jira/browse/IGNITE-18058 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > If the server does not respond, we hang forever in > *ClientSocket.ReceiveBytesAsync*. > We have *IgniteClientConfiguration.SocketTimeout*, but it is not actually > used anywhere. > While most client operations can take any amount of time (data retrieval and > update, etc), some operations should complete within the timeout: > * Handshake > * Heartbeat -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17995) Idle_verify must print broken partitions list
[
https://issues.apache.org/jira/browse/IGNITE-17995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627698#comment-17627698
]
Ilya Shishkov commented on IGNITE-17995:
[~av], can you take a look, please?
> Idle_verify must print broken partitions list
> -
>
> Key: IGNITE-17995
> URL: https://issues.apache.org/jira/browse/IGNITE-17995
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, idle_verify provides per partition information, but not just a set
> of broken partitions.
> So, additional actions is necessary to get the list required by consistency
> repair tool.
> {noformat}
> idle_verify task was executed with the following args: caches=[],
> excluded=[], cacheFilter=[DEFAULT]
> idle_verify check has finished, found XXX conflict partitions:
> [counterConflicts=0, hashConflicts=XXX]
> Hash conflicts:
> Conflict partition: PartitionKeyV2 [grpId=CacheGroup1,
> grpName=CacheGroup1Cache, partId=600]
> ...
> Control utility [ver. XXX]
> 2021 Copyright(C) Apache Software Foundation
> User: xxx
> Time: XXX
>
>
>
> Command [CACHE] finished with code: 0
> Control utility has completed execution at: XXX
> Execution time: XXX ms
> {noformat}
> Let's, in addition to detailed view, provide such lists.
> Something like:
> {noformat}
> Total:
> CacheGroup1 (18/1024)
> 1,7,42,987,99
> CacheGroup2 (15/1024)
> 5,14,17,850,900
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17995) Idle_verify must print broken partitions list
[
https://issues.apache.org/jira/browse/IGNITE-17995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627684#comment-17627684
]
Ilya Shishkov commented on IGNITE-17995:
Extra control utility suite runs (after test fixes) of ControlUtility [1],
ControlUtility 2 [2] and ControlUtility Zookeeper [3] suites. There is the only
failure of {{GridCommandHandlerDefragmentationTest#testDefragmentationStatus}}
with 100% failure rate [4].
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility/6886656?showRootCauses=true=true
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility2/6886658?showRootCauses=true=true=true
#
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6886660?showRootCauses=true=true
#
https://ci2.ignite.apache.org/test/-8869604011192050851?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true
> Idle_verify must print broken partitions list
> -
>
> Key: IGNITE-17995
> URL: https://issues.apache.org/jira/browse/IGNITE-17995
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, idle_verify provides per partition information, but not just a set
> of broken partitions.
> So, additional actions is necessary to get the list required by consistency
> repair tool.
> {noformat}
> idle_verify task was executed with the following args: caches=[],
> excluded=[], cacheFilter=[DEFAULT]
> idle_verify check has finished, found XXX conflict partitions:
> [counterConflicts=0, hashConflicts=XXX]
> Hash conflicts:
> Conflict partition: PartitionKeyV2 [grpId=CacheGroup1,
> grpName=CacheGroup1Cache, partId=600]
> ...
> Control utility [ver. XXX]
> 2021 Copyright(C) Apache Software Foundation
> User: xxx
> Time: XXX
>
>
>
> Command [CACHE] finished with code: 0
> Control utility has completed execution at: XXX
> Execution time: XXX ms
> {noformat}
> Let's, in addition to detailed view, provide such lists.
> Something like:
> {noformat}
> Total:
> CacheGroup1 (18/1024)
> 1,7,42,987,99
> CacheGroup2 (15/1024)
> 5,14,17,850,900
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17957) Refactor RaftGroupServiceImpl
[
https://issues.apache.org/jira/browse/IGNITE-17957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627682#comment-17627682
]
Roman Puchkovskiy commented on IGNITE-17957:
The patch looks good to me
> Refactor RaftGroupServiceImpl
> -
>
> Key: IGNITE-17957
> URL: https://issues.apache.org/jira/browse/IGNITE-17957
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{RaftGroupServiceImpl}} is located in the wrong package: since this is our
> own class (not ported from JRaft), it should be located in the
> {{internal.raft}} package
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17995) Idle_verify must print broken partitions list
[
https://issues.apache.org/jira/browse/IGNITE-17995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627681#comment-17627681
]
Ignite TC Bot commented on IGNITE-17995:
{panel:title=Branch: [pull/10359/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10359/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=6883220buildTypeId=IgniteTests24Java8_RunAll]
> Idle_verify must print broken partitions list
> -
>
> Key: IGNITE-17995
> URL: https://issues.apache.org/jira/browse/IGNITE-17995
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, idle_verify provides per partition information, but not just a set
> of broken partitions.
> So, additional actions is necessary to get the list required by consistency
> repair tool.
> {noformat}
> idle_verify task was executed with the following args: caches=[],
> excluded=[], cacheFilter=[DEFAULT]
> idle_verify check has finished, found XXX conflict partitions:
> [counterConflicts=0, hashConflicts=XXX]
> Hash conflicts:
> Conflict partition: PartitionKeyV2 [grpId=CacheGroup1,
> grpName=CacheGroup1Cache, partId=600]
> ...
> Control utility [ver. XXX]
> 2021 Copyright(C) Apache Software Foundation
> User: xxx
> Time: XXX
>
>
>
> Command [CACHE] finished with code: 0
> Control utility has completed execution at: XXX
> Execution time: XXX ms
> {noformat}
> Let's, in addition to detailed view, provide such lists.
> Something like:
> {noformat}
> Total:
> CacheGroup1 (18/1024)
> 1,7,42,987,99
> CacheGroup2 (15/1024)
> 5,14,17,850,900
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-8801:
---
Flags: Important
Ignite Flags: Release Notes Required
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-17987) Temporarily exclude timestamp comparison in case of ABORTED to ABORTED txn state cas
[ https://issues.apache.org/jira/browse/IGNITE-17987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin resolved IGNITE-17987. -- Assignee: Alexander Lapin Resolution: Fixed Was implemented as part of https://issues.apache.org/jira/browse/IGNITE-17975 > Temporarily exclude timestamp comparison in case of ABORTED to ABORTED txn > state cas > > > Key: IGNITE-17987 > URL: https://issues.apache.org/jira/browse/IGNITE-17987 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18070) Design the process of having a single storage for a follower and a learner on the same node
[ https://issues.apache.org/jira/browse/IGNITE-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-18070: Assignee: Aleksandr Polovtcev > Design the process of having a single storage for a follower and a learner on > the same node > --- > > Key: IGNITE-18070 > URL: https://issues.apache.org/jira/browse/IGNITE-18070 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17924) Core distributions zones functionality.
[ https://issues.apache.org/jira/browse/IGNITE-17924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-17924: - Description: [IEP-97: Distribution Zones - Apache Ignite - Apache Software Foundation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97%3A+Distribution+Zones] > Core distributions zones functionality. > --- > > Key: IGNITE-17924 > URL: https://issues.apache.org/jira/browse/IGNITE-17924 > Project: Ignite > Issue Type: Epic >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > [IEP-97: Distribution Zones - Apache Ignite - Apache Software > Foundation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97%3A+Distribution+Zones] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18070) Design the process of having a single storage for a follower and a learner on the same node
Aleksandr Polovtcev created IGNITE-18070: Summary: Design the process of having a single storage for a follower and a learner on the same node Key: IGNITE-18070 URL: https://issues.apache.org/jira/browse/IGNITE-18070 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18069) Check incremental snapshot before restoring it
Maksim Timonin created IGNITE-18069: --- Summary: Check incremental snapshot before restoring it Key: IGNITE-18069 URL: https://issues.apache.org/jira/browse/IGNITE-18069 Project: Ignite Issue Type: Sub-task Reporter: Maksim Timonin Assignee: Maksim Timonin Incremental snapshot must be checked before restoring. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627669#comment-17627669
]
Julia Bakulina edited comment on IGNITE-8801 at 11/2/22 12:15 PM:
--
As from devlist as of 28/10/2022
https://lists.apache.org/thread/3wxpx2tw9xnn74139nkqopdom5mh6q74:
1. Revert deprecation IGNITE-17916 - reverted
2. Change default value in 2.15.
3. Notify users in release notes, an exception message - how to change the
behavior back.
was (Author: JIRAUSER294860):
As from devlist as of 28/10/2022:
1. Revert deprecation IGNITE-17916 - reverted
2. Change default value in 2.15.
3. Notify users in release notes, an exception message - how to change the
behavior back.
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-8801:
---
Fix Version/s: 2.15
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627669#comment-17627669
]
Julia Bakulina commented on IGNITE-8801:
As from devlist as of 28/10/2022:
1. Revert deprecation IGNITE-17916 - reverted
2. Change default value in 2.15.
3. Notify users in release notes, an exception message - how to change the
behavior back.
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627662#comment-17627662
]
Ilya Shishkov edited comment on IGNITE-17865 at 11/2/22 12:07 PM:
--
[~slava.koptilin],
{quote}
By the way, do we need to handle replicated caches in the same way as
partitioned?
{quote}
Yes, there are no significant difference in rebalance logging.
{quote}
Let's assume that we just add a new node, and so all partitions should be
rebalanced?
{quote}
It is actual only when second node enters the cluster. In other cases
rebalancing will be performed in a such manner as for partitioned caches with
different suppliers (at least for in-memory cases).
I checked it for 5 nodes with {{SqlJdbcExample}}, see [^replicated.txt] with
log messages of rebalancing.
was (Author: shishkovilja):
[~slava.koptilin],
{quote}
By the way, do we need to handle replicated caches in the same way as
partitioned?
{quote}
Yes, there are no significant difference in rebalance logging.
{code}
Let's assume that we just add a new node, and so all partitions should be
rebalanced?
{code}
It is actual only when second node enters the cluster. In other cases
rebalancing will be performed in a such manner as for partitioned caches with
different suppliers (at least for in-memory cases).
I checked it for 5 nodes with {{SqlJdbcExample}}, see [^replicated.txt] with
log messages of rebalancing.
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Attachments: replicated.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:#ff}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:#ff}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
> Partition ranges are formed in _GridToStringBuilder#compact_ method, which is
> used to log of partition lists (except one place with exception and tests).
> Below are such places (without usages in tests):
> # {_}GridClientPartitionTopology#resetOwners{_}:
> [L1311|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1311],
>
> [L1312|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1312]
> (WARN)
> # {_}GridDhtPartitionDemander#handleSupplyMessage{_}:
> [L561|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L561]
> (ERROR)
> # {_}GridDhtPartitionDemander.RebalanceFuture#requestPartitions0{_}:
> [L1434|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1434],
>
> [L1435|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1435]
> (INFO)
> # {_}GridDhtPartitionsExchangeFuture#printPartitionRebalancingFully{_}:
>
[jira] [Commented] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627662#comment-17627662
]
Ilya Shishkov commented on IGNITE-17865:
[~slava.koptilin],
{quote}
By the way, do we need to handle replicated caches in the same way as
partitioned?
{quote}
Yes, there are no significant difference in rebalance logging.
{code}
Let's assume that we just add a new node, and so all partitions should be
rebalanced?
{code}
It is actual only when second node enters the cluster. In other cases
rebalancing will be performed in a such manner as for partitioned caches with
different suppliers (at least for in-memory cases).
I checked it for 5 nodes with {{SqlJdbcExample}}, see [^replicated.txt] with
log messages of rebalancing.
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Attachments: replicated.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:#ff}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:#ff}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
> Partition ranges are formed in _GridToStringBuilder#compact_ method, which is
> used to log of partition lists (except one place with exception and tests).
> Below are such places (without usages in tests):
> # {_}GridClientPartitionTopology#resetOwners{_}:
> [L1311|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1311],
>
> [L1312|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1312]
> (WARN)
> # {_}GridDhtPartitionDemander#handleSupplyMessage{_}:
> [L561|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L561]
> (ERROR)
> # {_}GridDhtPartitionDemander.RebalanceFuture#requestPartitions0{_}:
> [L1434|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1434],
>
> [L1435|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1435]
> (INFO)
> # {_}GridDhtPartitionsExchangeFuture#printPartitionRebalancingFully{_}:
> [L4282|https://github.com/apache/ignite/blob/bc843a5b40a6da0e2bfcb77857bea499ab9a4512/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java#L4282]
> (INFO)
> # {_}GridDhtPartitionSupplier#handleDemandMessage{_}:
> [L276|https://github.com/apache/ignite/blob/00988d20af19485585e98e885c610a704640c083/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionSupplier.java#L276]
> (DEBUG)
> # {_}GridDhtPartitionTopologyImpl#detectLostPartitions{_}:
> [L2281|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridDhtPartitionTopologyImpl.java#L2281]
> (WARN)
> #
[jira] [Updated] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17865:
---
Attachment: replicated.txt
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Attachments: replicated.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:#ff}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:#ff}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
> Partition ranges are formed in _GridToStringBuilder#compact_ method, which is
> used to log of partition lists (except one place with exception and tests).
> Below are such places (without usages in tests):
> # {_}GridClientPartitionTopology#resetOwners{_}:
> [L1311|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1311],
>
> [L1312|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1312]
> (WARN)
> # {_}GridDhtPartitionDemander#handleSupplyMessage{_}:
> [L561|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L561]
> (ERROR)
> # {_}GridDhtPartitionDemander.RebalanceFuture#requestPartitions0{_}:
> [L1434|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1434],
>
> [L1435|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1435]
> (INFO)
> # {_}GridDhtPartitionsExchangeFuture#printPartitionRebalancingFully{_}:
> [L4282|https://github.com/apache/ignite/blob/bc843a5b40a6da0e2bfcb77857bea499ab9a4512/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java#L4282]
> (INFO)
> # {_}GridDhtPartitionSupplier#handleDemandMessage{_}:
> [L276|https://github.com/apache/ignite/blob/00988d20af19485585e98e885c610a704640c083/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionSupplier.java#L276]
> (DEBUG)
> # {_}GridDhtPartitionTopologyImpl#detectLostPartitions{_}:
> [L2281|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridDhtPartitionTopologyImpl.java#L2281]
> (WARN)
> # {_}GridDhtPartitionTopologyImpl#resetOwners{_}:
> [L2445|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridDhtPartitionTopologyImpl.java#L2445]
> (WARN)
> # {_}PartitionsEvictManager{_}: called in _#toString_ at
> [L254|https://github.com/apache/ignite/blob/9021f783e9453375482c9b255a42ca827e091daa/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/PartitionsEvictManager.java#L254],
> result used in _#showProgress_ at
>
[jira] [Created] (IGNITE-18068) Flaky test GridDrBinaryMarshallerTestSuite2:DrReceiverHubRestartSelfTest.testReceiverHubRestart
Yury Gerzhedovich created IGNITE-18068: -- Summary: Flaky test GridDrBinaryMarshallerTestSuite2:DrReceiverHubRestartSelfTest.testReceiverHubRestart Key: IGNITE-18068 URL: https://issues.apache.org/jira/browse/IGNITE-18068 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich The test [GridDrBinaryMarshallerTestSuite2:DrReceiverHubRestartSelfTest.testReceiverHubRestart|https://ggtc.gridgain.com/test/-7043116888680218123?currentProjectId=GridGain8_Test_EnterpriseUltimateEdition=%3Cdefault%3E] is flaky. Need to fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17986) SchemaManager recovery was broken after refactoring
[
https://issues.apache.org/jira/browse/IGNITE-17986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627651#comment-17627651
]
Evgeny Stanilovsky commented on IGNITE-17986:
-
[~Denis Chudov] [~maliev] can u make a review plz ?
> SchemaManager recovery was broken after refactoring
> ---
>
> Key: IGNITE-17986
> URL: https://issues.apache.org/jira/browse/IGNITE-17986
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Mirza Aliev
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While we unmuted tests from `ItIgniteNodeRestartTest`, we noticed that
> restart of the node seems to be broken.
> It seems, that after https://issues.apache.org/jira/browse/IGNITE-17702 was
> merged, some scenarios for a node recovery was broken. The root cause is
> highly likely connected to the fact, that in the {{SchemaManager#start}} we
> directly pass 0 to {{createSchema(0, tblId, tblName, desc).join();}}, which
> is incorrect. Also {{registriesVv.complete(0);}} seems to be incorrect.
> To reproduce the issue, run
> {{ItIgniteNodeRestartTest#testTwoNodesRestartDirect}} or
> {{ItIgniteInMemoryNodeRestartTest#inMemoryNodeRestartNotLeader}}
> and we can see that such lines are presented in the log:
> {noformat}
> Caused by: java.lang.AssertionError: Token must be greater than actual
> [token=0, actual=1]
> at
> org.apache.ignite.internal.causality.VersionedValue.checkToken(VersionedValue.java:597)
> {noformat}
> or
> {noformat}
> Caused by: java.lang.AssertionError: New token should be greater than current
> [current=1, new=1]
> at
> org.apache.ignite.internal.causality.VersionedValue.completeOnRevision(VersionedValue.java:481)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18067) Flaky test IgniteCacheQueryNodeFailTest.testNodeFailedReduceQuery
Yury Gerzhedovich created IGNITE-18067:
--
Summary: Flaky test
IgniteCacheQueryNodeFailTest.testNodeFailedReduceQuery
Key: IGNITE-18067
URL: https://issues.apache.org/jira/browse/IGNITE-18067
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Yury Gerzhedovich
The test
[IgniteBinarySimpleNameMapperCacheQueryTestSuite2:IgniteCacheQueryNodeFailTest.testNodeFailedReduceQuery|https://ggtc.gridgain.com/test/758645604019355804?currentProjectId=GridGain8_Test_CommunityEdition=%3Cdefault%3E]
is flaky. Need to fix it.
{code:java}
Ignite instance with this name has already been started:
near.IgniteCacheQueryNodeFailTest2 --- Stdout: --- class
org.apache.ignite.IgniteCheckedException: Ignite instance with this name has
already been started: near.IgniteCacheQueryNodeFailTest2at
org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1128)at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:634)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15328) Consistency recovery command (Read Repair via control.ch) should support cancellation
[
https://issues.apache.org/jira/browse/IGNITE-15328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-15328:
---
Labels: iep-31 ise (was: iep-31)
> Consistency recovery command (Read Repair via control.ch) should support
> cancellation
> -
>
> Key: IGNITE-15328
> URL: https://issues.apache.org/jira/browse/IGNITE-15328
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31, ise
> Fix For: 2.12
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> {{--kill}} command should support {{consistency}} flag.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15482) Read Repair should support binary objects
[
https://issues.apache.org/jira/browse/IGNITE-15482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-15482:
---
Labels: iep-31 ise (was: iep-31)
> Read Repair should support binary objects
> -
>
> Key: IGNITE-15482
> URL: https://issues.apache.org/jira/browse/IGNITE-15482
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: iep-31, ise
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Attempt to read object created with BinaryBuilder will cause an exception
> {noformat}
> [15:12:43] (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.near.consistency.GridNearReadRepairAbstractFuture$$Lambda$949/964371219@65140246[15:12:43]
> (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.near.consistency.GridNearReadRepairAbstractFuture$$Lambda$949/964371219@762f47bfclass
> org.apache.ignite.binary.BinaryInvalidTypeException:
> org.apache.ignite.TestValue
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:717)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1721)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:820)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:150)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:197)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:76)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:138)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1795)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.consistency.GridNearReadRepairCheckOnlyFuture.reduce(GridNearReadRepairCheckOnlyFuture.java:108)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.consistency.GridNearReadRepairAbstractFuture.onResult(GridNearReadRepairAbstractFuture.java:249)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundIdentityFuture.onDone(GridCacheCompoundIdentityFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.onDone(GridPartitionedGetFuture.java:158)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.onDone(GridPartitionedGetFuture.java:62)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:467)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:351)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:152)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:47)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:467)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter$AbstractMiniFuture.onResult(CacheDistributedGetFutureAdapter.java:571)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.onResult(CacheDistributedGetFutureAdapter.java:319)
>
[jira] [Updated] (IGNITE-15180) Read Repair should generate Event even when nothing fixed but broken (eg. atomics check).
[
https://issues.apache.org/jira/browse/IGNITE-15180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-15180:
---
Labels: iep-31 ise (was: iep-31)
> Read Repair should generate Event even when nothing fixed but broken (eg.
> atomics check).
> -
>
> Key: IGNITE-15180
> URL: https://issues.apache.org/jira/browse/IGNITE-15180
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31, ise
> Fix For: 2.12
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {{CacheConsistencyViolationEvent}} should be generated in addition to
> {{IgniteConsistencyViolationException}} but
> {{org.apache.ignite.events.CacheConsistencyViolationEvent#repairedEntries}}
> should be empty in this case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18058) .NET: Thin 3.0: Socket read never times out
[ https://issues.apache.org/jira/browse/IGNITE-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18058: Description: If the server does not respond, we hang forever in *ClientSocket.ReceiveBytesAsync*. We have *IgniteClientConfiguration.SocketTimeout*, but it is not actually used anywhere. While most client operations can take any amount of time (data retrieval and update, etc), some operations should complete within the timeout: * Handshake * Heartbeat was: If the server does not respond, we hang forever in *ClientSocket.ReceiveBytesAsync*. We have *IgniteClientConfiguration.SocketTimeout*, but it is not actually used anywhere. > .NET: Thin 3.0: Socket read never times out > --- > > Key: IGNITE-18058 > URL: https://issues.apache.org/jira/browse/IGNITE-18058 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > If the server does not respond, we hang forever in > *ClientSocket.ReceiveBytesAsync*. > We have *IgniteClientConfiguration.SocketTimeout*, but it is not actually > used anywhere. > While most client operations can take any amount of time (data retrieval and > update, etc), some operations should complete within the timeout: > * Handshake > * Heartbeat -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17912) Ducktape tests broken
[
https://issues.apache.org/jira/browse/IGNITE-17912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17912:
---
Labels: ise (was: )
> Ducktape tests broken
> -
>
> Key: IGNITE-17912
> URL: https://issues.apache.org/jira/browse/IGNITE-17912
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Several Ducktape tests broken after IGNITE-17736.
> {noformat}
> FAILED TESTS
> 1a94b6@ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_join.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> 1a94b6@ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_left.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> 1a94b6@ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> 1d1243@ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_left.backups=1.cache_count=1.entry_count=5.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
> 9d1550@ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_join.backups=1.cache_count=1.entry_count=5000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> dc8511@ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_join.backups=1.cache_count=1.entry_count=5000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
> f75167@ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_left.backups=1.cache_count=1.entry_count=5.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> fbd673@ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_join.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
> fbd673@ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_left.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
> fbd673@ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
> 43105a@ignitetest.tests.control_utility.consistency_test.ConsistencyTest.test_logging.ignite_version=ignite-dev
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18066) Restore all schemes on recovery for time travel requests purposes.
Evgeny Stanilovsky created IGNITE-18066:
---
Summary: Restore all schemes on recovery for time travel requests
purposes.
Key: IGNITE-18066
URL: https://issues.apache.org/jira/browse/IGNITE-18066
Project: Ignite
Issue Type: Improvement
Components: general
Affects Versions: 3.0.0-alpha5
Reporter: Evgeny Stanilovsky
Due to recovery of SchemaManager seems we need to restore and register all
schemes, i.e. like :
{noformat}
private SortedMap collectAllSchemas(UUID tblId) {
Cursor cur = metastorageMgr.prefix(schemaHistPrefix(tblId));
SortedMap schemes = new TreeMap<>();
for (Entry ent : cur) {
String key = ent.key().toString();
int descVer = extractVerFromSchemaKey(key);
schemes.put(descVer, ent.value());
}
return schemes;
}
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18046) .NET: Thin 3.0: Get and verify cluster id on connection
[ https://issues.apache.org/jira/browse/IGNITE-18046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18046: Release Note: .NET: Added cluster ID verification on handshake to avoid connecting one client to different clusters. (was: .NET: Verify cluster ID on handshake to avoid connecting one client to different clusters.) > .NET: Thin 3.0: Get and verify cluster id on connection > --- > > Key: IGNITE-18046 > URL: https://issues.apache.org/jira/browse/IGNITE-18046 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-90, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Client needs to get and verify cluster ID on handshake as described in > [IEP-90|https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle] > to make sure all servers it connects to are from the same cluster. This is > especially important during connection restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18046) .NET: Thin 3.0: Get and verify cluster id on connection
[ https://issues.apache.org/jira/browse/IGNITE-18046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18046: Release Note: .NET: Verify cluster ID on handshake to avoid connecting one client to different clusters. > .NET: Thin 3.0: Get and verify cluster id on connection > --- > > Key: IGNITE-18046 > URL: https://issues.apache.org/jira/browse/IGNITE-18046 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-90, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Client needs to get and verify cluster ID on handshake as described in > [IEP-90|https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle] > to make sure all servers it connects to are from the same cluster. This is > especially important during connection restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17690) Thin 3.0: Get and verify cluster id on connection
[ https://issues.apache.org/jira/browse/IGNITE-17690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17690: Release Note: Java client: Added cluster ID verification on handshake to avoid connecting one client to different clusters. > Thin 3.0: Get and verify cluster id on connection > - > > Key: IGNITE-17690 > URL: https://issues.apache.org/jira/browse/IGNITE-17690 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-90, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Client need to get and verify cluster ID on handshake as described in > [IEP-90|https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle] > to make sure all servers it connects to are from the same cluster. This is > especially important during connection restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18046) .NET: Thin 3.0: Get and verify cluster id on connection
[ https://issues.apache.org/jira/browse/IGNITE-18046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627614#comment-17627614 ] Pavel Tupitsyn commented on IGNITE-18046: - Merged to main: b2b75c730d40bddf7897beeb144afe39fe49d7b5 > .NET: Thin 3.0: Get and verify cluster id on connection > --- > > Key: IGNITE-18046 > URL: https://issues.apache.org/jira/browse/IGNITE-18046 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-90, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Client needs to get and verify cluster ID on handshake as described in > [IEP-90|https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle] > to make sure all servers it connects to are from the same cluster. This is > especially important during connection restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18059) .NET: Thin 3.0: Error codes should be constants
[
https://issues.apache.org/jira/browse/IGNITE-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627612#comment-17627612
]
Pavel Tupitsyn commented on IGNITE-18059:
-
Merged to main: 9a0f86cad7c9a3bc6f0cf13c79afc29964fa631d
> .NET: Thin 3.0: Error codes should be constants
> ---
>
> Key: IGNITE-18059
> URL: https://issues.apache.org/jira/browse/IGNITE-18059
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, error codes in generated *ErrorGroups* class are *static readonly
> int*, because we calculate them at runtime with *GetFullCode*.
> However, this prevents pattern matching. The following does not work:
> {code}
> if (e is IgniteClientConnectionException { Code:
> ErrorGroups.Client.ClusterIdMismatch })
> {
> ...
> }
> {code}
> Compiler error: *[CS0150] A constant value is expected*.
> Since we use code generation, it is easy to compute error codes at compile
> time and use constants to make things nicer for the users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17997) Whitespaces at the end are ignored during string comparison
[
https://issues.apache.org/jira/browse/IGNITE-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627610#comment-17627610
]
Yury Gerzhedovich commented on IGNITE-17997:
[~akhitrin] , in case we agree that's not a bug let's close the ticket.
> Whitespaces at the end are ignored during string comparison
> ---
>
> Key: IGNITE-17997
> URL: https://issues.apache.org/jira/browse/IGNITE-17997
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3
>
> In 3.0.0-Beta-1:
> {code:java}
> sql-cli> select 'a' = 'a' as t1, 'a' = 'b' as t2, 'a' = 'a ' as t3, 'a' = '
> a' as t4;
> ╔══╤═══╤══╤═══╗
> ║ T1 │ T2 │ T3 │ T4 ║
> ╠══╪═══╪══╪═══╣
> ║ true │ false │ true │ false ║
> ╚══╧═══╧══╧═══╝
> {code}
> Tests T1, T2, and T4 show correct behavior. But in test T2 we see that string
> 'a' is considered being equal to string 'a ' (same string but with
> arbitrary amount of whitespaces at the end). This is incorrect behavior.
> This issue may have the same nature as IGNITE-17996, but it's just a
> hypothesis.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17996) Strange behavior of SQL CASE expression
[
https://issues.apache.org/jira/browse/IGNITE-17996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627611#comment-17627611
]
Yury Gerzhedovich commented on IGNITE-17996:
[~akhitrin] , in case we agree that's not a bug let's close the ticket.
> Strange behavior of SQL CASE expression
> ---
>
> Key: IGNITE-17996
> URL: https://issues.apache.org/jira/browse/IGNITE-17996
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3
>
> I observe strange behavior in the next scenario:
>
> {code:java}
> sql-cli> create table xx (f1 int primary key);
> Updated 0 rows.
> sql-cli> insert into xx values (1);
> Updated 1 rows.
> sql-cli> insert into xx values (2);
> Updated 1 rows.
> sql-cli> select f1, case when f1 < 2 then 'foo' else 'barbar' end as s,
> length(case when f1 < 2 then 'foo' else 'barbar' end) as ls from xx;
> ╔╤╤╗
> ║ F1 │ S │ LS ║
> ╠╪╪╣
> ║ 2 │ barbar │ 6 ║
> ╟┼┼╢
> ║ 1 │ foo │ 6 ║
> ╚╧╧╝
> {code}
> I expect `CASE` to return 'foo' value, but de-facto it returns 'foo '
> ('foo' with 3 whitespaces at the end). Seems like this should be fixed.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18059) .NET: Thin 3.0: Error codes should be constants
[
https://issues.apache.org/jira/browse/IGNITE-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627591#comment-17627591
]
Igor Sapego commented on IGNITE-18059:
--
[~ptupitsyn] looks good to me
> .NET: Thin 3.0: Error codes should be constants
> ---
>
> Key: IGNITE-18059
> URL: https://issues.apache.org/jira/browse/IGNITE-18059
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, error codes in generated *ErrorGroups* class are *static readonly
> int*, because we calculate them at runtime with *GetFullCode*.
> However, this prevents pattern matching. The following does not work:
> {code}
> if (e is IgniteClientConnectionException { Code:
> ErrorGroups.Client.ClusterIdMismatch })
> {
> ...
> }
> {code}
> Compiler error: *[CS0150] A constant value is expected*.
> Since we use code generation, it is easy to compute error codes at compile
> time and use constants to make things nicer for the users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17029) Implement Consistent Cut algorithm
[ https://issues.apache.org/jira/browse/IGNITE-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17029: Description: Consistent Cut is algorithm for finding Points In Time for Recovering (PITR). Such points must guarantee transactional consistency over whole cluster. Algorithm description: [https://cwiki.apache.org/confluence/display/IGNITE/Consistent+Cut] was: Consistent Cut is algorithm for finding Points In Time for Recovering (PITR). Such points must guarantee transactional consistency over whole cluster. Algorithm description: https://cwiki.apache.org/confluence/display/IGNITE/Consistent+Cut > Implement Consistent Cut algorithm > -- > > Key: IGNITE-17029 > URL: https://issues.apache.org/jira/browse/IGNITE-17029 > Project: Ignite > Issue Type: Sub-task >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89, ise > Time Spent: 2h 40m > Remaining Estimate: 0h > > Consistent Cut is algorithm for finding Points In Time for Recovering (PITR). > Such points must guarantee transactional consistency over whole cluster. > Algorithm description: > [https://cwiki.apache.org/confluence/display/IGNITE/Consistent+Cut] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627581#comment-17627581
]
Maksim Timonin commented on IGNITE-8801:
Link to devlist
[https://lists.apache.org/thread/3wxpx2tw9xnn74139nkqopdom5mh6q74]
Let's make this ticket now.
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627580#comment-17627580 ] Maksim Timonin commented on IGNITE-17916: - reverted. after discussion on devlist. Decide just to change defualt https://issues.apache.org/jira/browse/IGNITE-8801 Delist discussion: https://lists.apache.org/thread/3wxpx2tw9xnn74139nkqopdom5mh6q74 > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: important, ise > Fix For: 2.15 > > Time Spent: 1.5h > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to *break > changes* of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18046) .NET: Thin 3.0: Get and verify cluster id on connection
[ https://issues.apache.org/jira/browse/IGNITE-18046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627579#comment-17627579 ] Igor Sapego commented on IGNITE-18046: -- [~ptupitsyn] looks good to me. > .NET: Thin 3.0: Get and verify cluster id on connection > --- > > Key: IGNITE-18046 > URL: https://issues.apache.org/jira/browse/IGNITE-18046 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-90, ignite-3 > Fix For: 3.0.0-beta2 > > > Client needs to get and verify cluster ID on handshake as described in > [IEP-90|https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle] > to make sure all servers it connects to are from the same cluster. This is > especially important during connection restoration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17814) JRaft API should operate with Peers based on consistent ID
[ https://issues.apache.org/jira/browse/IGNITE-17814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-17814: - Fix Version/s: 3.0.0-beta2 > JRaft API should operate with Peers based on consistent ID > --- > > Key: IGNITE-17814 > URL: https://issues.apache.org/jira/browse/IGNITE-17814 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > When starting a Raft service, a list of peers is required, which are > identified by host-port pairs. However, Ignite nodes are identified by their > consistent IDs, which requires an intermediate step of resolving consistent > IDs into addresses. This is problematic, because a particular node may be > offline and, therefore, impossible to resolve. It is proposed to use peers > that are based on consistent IDs instead and move the handling of offline > nodes into the Raft infrastructure. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-16865) ItIgniteNodeRestartTest#changeConfigurationOnStartTest is failing
[ https://issues.apache.org/jira/browse/IGNITE-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-16865: Assignee: Aleksandr Polovtcev > ItIgniteNodeRestartTest#changeConfigurationOnStartTest is failing > - > > Key: IGNITE-16865 > URL: https://issues.apache.org/jira/browse/IGNITE-16865 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > The source of the problem lies in the fact that an ignite node restarted with > different server port considers itself another node. Before shared log > storage was introduced, it was not reading old raft log at all, after shared > log storage it reads old raft log sees its previous self in the configuration > with different "name" and fails as it's not the part of the group now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-16373) Investigate possibility to remove sending by address in messaging service
[ https://issues.apache.org/jira/browse/IGNITE-16373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-16373: Assignee: Aleksandr Polovtcev > Investigate possibility to remove sending by address in messaging service > - > > Key: IGNITE-16373 > URL: https://issues.apache.org/jira/browse/IGNITE-16373 > Project: Ignite > Issue Type: Task >Reporter: Semyon Danilov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > ATM MessagingService can send messages not only using ClusterNode, but > NetworkAddress. This allows RAFT to send messages to the nodes that are not > in the cluster yet. Although it's convenient for RAFT server, the API is not > very clean and this effectively separates raft from the cluster topology. We > need to investigate the possibility to glue raft and cluster together -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16865) ItIgniteNodeRestartTest#changeConfigurationOnStartTest is failing
[ https://issues.apache.org/jira/browse/IGNITE-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-16865: - Ignite Flags: (was: Docs Required,Release Notes Required) > ItIgniteNodeRestartTest#changeConfigurationOnStartTest is failing > - > > Key: IGNITE-16865 > URL: https://issues.apache.org/jira/browse/IGNITE-16865 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > The source of the problem lies in the fact that an ignite node restarted with > different server port considers itself another node. Before shared log > storage was introduced, it was not reading old raft log at all, after shared > log storage it reads old raft log sees its previous self in the configuration > with different "name" and fails as it's not the part of the group now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18065) ItIgniteNodeRestartTest#testTwoNodesRestartReverse fails
Aleksandr Polovtcev created IGNITE-18065: Summary: ItIgniteNodeRestartTest#testTwoNodesRestartReverse fails Key: IGNITE-18065 URL: https://issues.apache.org/jira/browse/IGNITE-18065 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev We need to investigate and identify, why this test fails -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627564#comment-17627564
]
Vyacheslav Koptilin commented on IGNITE-17865:
--
By the way, do we need to handle replicated caches in the same way as
partitioned?
Let's assume that we just add a new node, and so all partitions should be
rebalanced?
{code:java}
Starting rebalance routine [cache, topVer=AffinityTopologyVersion [topVer=4,
minorTopVer=0], supplier=d822f1cd-f36e-4be3-bb4c-c7a80b70,
fullPartitions=[0-511], histPartitions=[], rebalanceId=1]
{code}
In that case _fullPartitions=[0-511]_ looks much better than
_fullPartitions=[0, 1, 2, 3, ... , 511]_
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:#ff}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:#ff}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
> Partition ranges are formed in _GridToStringBuilder#compact_ method, which is
> used to log of partition lists (except one place with exception and tests).
> Below are such places (without usages in tests):
> # {_}GridClientPartitionTopology#resetOwners{_}:
> [L1311|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1311],
>
> [L1312|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1312]
> (WARN)
> # {_}GridDhtPartitionDemander#handleSupplyMessage{_}:
> [L561|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L561]
> (ERROR)
> # {_}GridDhtPartitionDemander.RebalanceFuture#requestPartitions0{_}:
> [L1434|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1434],
>
> [L1435|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1435]
> (INFO)
> # {_}GridDhtPartitionsExchangeFuture#printPartitionRebalancingFully{_}:
> [L4282|https://github.com/apache/ignite/blob/bc843a5b40a6da0e2bfcb77857bea499ab9a4512/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java#L4282]
> (INFO)
> # {_}GridDhtPartitionSupplier#handleDemandMessage{_}:
> [L276|https://github.com/apache/ignite/blob/00988d20af19485585e98e885c610a704640c083/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionSupplier.java#L276]
> (DEBUG)
> # {_}GridDhtPartitionTopologyImpl#detectLostPartitions{_}:
> [L2281|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridDhtPartitionTopologyImpl.java#L2281]
> (WARN)
> # {_}GridDhtPartitionTopologyImpl#resetOwners{_}:
>
[jira] [Commented] (IGNITE-17029) Implement Consistent Cut algorithm
[
https://issues.apache.org/jira/browse/IGNITE-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627557#comment-17627557
]
Ignite TC Bot commented on IGNITE-17029:
{panel:title=Branch: [pull/10314/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10314/head] Base: [master] : New Tests
(320)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6884021]]
* {color:#013220}IgniteBasicTestSuite: GridFuncSelfTest.testMapEqNotOrdered -
PASSED{color}
{color:#8b}Snapshots{color} [[tests
319|https://ci.ignite.apache.org/viewLog.html?buildId=6884112]]
* {color:#013220}IgniteSnapshotTestSuite:
ConsistentCutTwoBackupMessagesBlockingTest.testMultipleCases[txNodeBlk=PRIMARY,
cutBlkAt=AFTER_VERSION_UPDATE, nodeBlk=BACKUP, blkMsgCls=class
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxPrepareResponse]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
ConsistentCutTwoBackupMessagesBlockingTest.testMultipleCases[txNodeBlk=PRIMARY,
cutBlkAt=AFTER_VERSION_UPDATE, nodeBlk=BACKUP, blkMsgCls=class
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxPrepareRequest]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
ConsistentCutTwoBackupMessagesBlockingTest.testMultipleCases[txNodeBlk=PRIMARY,
cutBlkAt=AFTER_VERSION_UPDATE, nodeBlk=BACKUP, blkMsgCls=class
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishResponse]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
ConsistentCutTwoBackupMessagesBlockingTest.testMultipleCases[txNodeBlk=PRIMARY,
cutBlkAt=AFTER_VERSION_UPDATE, nodeBlk=BACKUP, blkMsgCls=class
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishRequest]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
ConsistentCutTwoBackupMessagesBlockingTest.testMultipleCases[txNodeBlk=PRIMARY,
cutBlkAt=BEFORE_VERSION_UPDATE, nodeBlk=BACKUP, blkMsgCls=class
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareRequest]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
ConsistentCutTwoBackupMessagesBlockingTest.testMultipleCases[txNodeBlk=PRIMARY,
cutBlkAt=BEFORE_VERSION_UPDATE, nodeBlk=BACKUP, blkMsgCls=class
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishResponse]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
ConsistentCutTwoBackupMessagesBlockingTest.testMultipleCases[txNodeBlk=PRIMARY,
cutBlkAt=BEFORE_VERSION_UPDATE, nodeBlk=BACKUP, blkMsgCls=class
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxFinishRequest]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
ConsistentCutTwoBackupMessagesBlockingTest.testMultipleCases[txNodeBlk=PRIMARY,
cutBlkAt=BEFORE_VERSION_UPDATE, nodeBlk=BACKUP, blkMsgCls=class
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareResponse]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
ConsistentCutTwoBackupMessagesBlockingTest.testMultipleCases[txNodeBlk=PRIMARY,
cutBlkAt=BEFORE_VERSION_UPDATE, nodeBlk=BACKUP, blkMsgCls=class
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxPrepareRequest]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
ConsistentCutTwoBackupMessagesBlockingTest.testMultipleCases[txNodeBlk=PRIMARY,
cutBlkAt=NONE, nodeBlk=BACKUP, blkMsgCls=class
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxFinishRequest]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
ConsistentCutTwoBackupMessagesBlockingTest.testMultipleCases[txNodeBlk=PRIMARY,
cutBlkAt=BEFORE_VERSION_UPDATE, nodeBlk=BACKUP, blkMsgCls=class
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishRequest]
- PASSED{color}
... and 308 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6884131buildTypeId=IgniteTests24Java8_RunAll]
> Implement Consistent Cut algorithm
> --
>
> Key: IGNITE-17029
> URL: https://issues.apache.org/jira/browse/IGNITE-17029
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-89, ise
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Consistent Cut is algorithm for finding Points In Time for Recovering (PITR).
> Such points must guarantee transactional consistency over whole cluster.
> Algorithm description:
> https://cwiki.apache.org/confluence/display/IGNITE/Consistent+Cut
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627550#comment-17627550
]
Vyacheslav Koptilin edited comment on IGNITE-17865 at 11/2/22 9:13 AM:
---
Hello [~shishkovilja],
??Could we add extra system property to turning on/off the optimization? WDYT???
Yet another system property... I mean I am not a fan of system properties :)
OK, let's go move forward with a new property.
I left one comment to your pull request. Please take a look.
was (Author: slava.koptilin):
Hello [~shishkovilja],
??Could we add extra system property to turning on/off the optimization? WDYT?
??
Yet another system property... I mean I am not a fan of system properties :)
OK, let's go move forward with a new property.
I left one comment to your pull request. Please take a look.
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:#ff}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:#ff}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
> Partition ranges are formed in _GridToStringBuilder#compact_ method, which is
> used to log of partition lists (except one place with exception and tests).
> Below are such places (without usages in tests):
> # {_}GridClientPartitionTopology#resetOwners{_}:
> [L1311|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1311],
>
> [L1312|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1312]
> (WARN)
> # {_}GridDhtPartitionDemander#handleSupplyMessage{_}:
> [L561|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L561]
> (ERROR)
> # {_}GridDhtPartitionDemander.RebalanceFuture#requestPartitions0{_}:
> [L1434|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1434],
>
> [L1435|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1435]
> (INFO)
> # {_}GridDhtPartitionsExchangeFuture#printPartitionRebalancingFully{_}:
> [L4282|https://github.com/apache/ignite/blob/bc843a5b40a6da0e2bfcb77857bea499ab9a4512/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java#L4282]
> (INFO)
> # {_}GridDhtPartitionSupplier#handleDemandMessage{_}:
> [L276|https://github.com/apache/ignite/blob/00988d20af19485585e98e885c610a704640c083/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionSupplier.java#L276]
> (DEBUG)
> # {_}GridDhtPartitionTopologyImpl#detectLostPartitions{_}:
>
[jira] [Commented] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627550#comment-17627550
]
Vyacheslav Koptilin commented on IGNITE-17865:
--
Hello [~shishkovilja],
??Could we add extra system property to turning on/off the optimization? WDYT???
Yet another system property... I mean I am not a fan of system properties :)
OK, let's go move forward with a new property.
I left one comment to your pull request. Please take a look.
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:#ff}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:#ff}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
> Partition ranges are formed in _GridToStringBuilder#compact_ method, which is
> used to log of partition lists (except one place with exception and tests).
> Below are such places (without usages in tests):
> # {_}GridClientPartitionTopology#resetOwners{_}:
> [L1311|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1311],
>
> [L1312|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1312]
> (WARN)
> # {_}GridDhtPartitionDemander#handleSupplyMessage{_}:
> [L561|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L561]
> (ERROR)
> # {_}GridDhtPartitionDemander.RebalanceFuture#requestPartitions0{_}:
> [L1434|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1434],
>
> [L1435|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1435]
> (INFO)
> # {_}GridDhtPartitionsExchangeFuture#printPartitionRebalancingFully{_}:
> [L4282|https://github.com/apache/ignite/blob/bc843a5b40a6da0e2bfcb77857bea499ab9a4512/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java#L4282]
> (INFO)
> # {_}GridDhtPartitionSupplier#handleDemandMessage{_}:
> [L276|https://github.com/apache/ignite/blob/00988d20af19485585e98e885c610a704640c083/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionSupplier.java#L276]
> (DEBUG)
> # {_}GridDhtPartitionTopologyImpl#detectLostPartitions{_}:
> [L2281|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridDhtPartitionTopologyImpl.java#L2281]
> (WARN)
> # {_}GridDhtPartitionTopologyImpl#resetOwners{_}:
> [L2445|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridDhtPartitionTopologyImpl.java#L2445]
> (WARN)
> # {_}PartitionsEvictManager{_}: called in _#toString_
[jira] [Comment Edited] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627550#comment-17627550
]
Vyacheslav Koptilin edited comment on IGNITE-17865 at 11/2/22 9:12 AM:
---
Hello [~shishkovilja],
??Could we add extra system property to turning on/off the optimization? WDYT?
??
Yet another system property... I mean I am not a fan of system properties :)
OK, let's go move forward with a new property.
I left one comment to your pull request. Please take a look.
was (Author: slava.koptilin):
Hello [~shishkovilja],
??Could we add extra system property to turning on/off the optimization? WDYT???
Yet another system property... I mean I am not a fan of system properties :)
OK, let's go move forward with a new property.
I left one comment to your pull request. Please take a look.
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:#ff}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:#ff}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
> Partition ranges are formed in _GridToStringBuilder#compact_ method, which is
> used to log of partition lists (except one place with exception and tests).
> Below are such places (without usages in tests):
> # {_}GridClientPartitionTopology#resetOwners{_}:
> [L1311|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1311],
>
> [L1312|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1312]
> (WARN)
> # {_}GridDhtPartitionDemander#handleSupplyMessage{_}:
> [L561|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L561]
> (ERROR)
> # {_}GridDhtPartitionDemander.RebalanceFuture#requestPartitions0{_}:
> [L1434|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1434],
>
> [L1435|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1435]
> (INFO)
> # {_}GridDhtPartitionsExchangeFuture#printPartitionRebalancingFully{_}:
> [L4282|https://github.com/apache/ignite/blob/bc843a5b40a6da0e2bfcb77857bea499ab9a4512/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java#L4282]
> (INFO)
> # {_}GridDhtPartitionSupplier#handleDemandMessage{_}:
> [L276|https://github.com/apache/ignite/blob/00988d20af19485585e98e885c610a704640c083/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionSupplier.java#L276]
> (DEBUG)
> # {_}GridDhtPartitionTopologyImpl#detectLostPartitions{_}:
>
[jira] [Created] (IGNITE-18064) Initial SQL support analysis for Optional features
Yury Gerzhedovich created IGNITE-18064: -- Summary: Initial SQL support analysis for Optional features Key: IGNITE-18064 URL: https://issues.apache.org/jira/browse/IGNITE-18064 Project: Ignite Issue Type: Task Components: sql Reporter: Yury Gerzhedovich Assignee: Yury Gerzhedovich Need to analyze SQL standard and check which Optional features SQL engine in Apache Ignite 3.0 support and which not. As a result, it requires append already created document in https://issues.apache.org/jira/browse/IGNITE-17928 As basis standard let's use ISO/IEC 9075 2016 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18063) MessageService should use conistent IDs instead of node IDs
[
https://issues.apache.org/jira/browse/IGNITE-18063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-18063:
-
Description: For some reason {{MessageService}} class and its users (e.g.
`InternalTable#assignments`) use node IDs, which can change if a node is
restarted (and lead to unknown and untested bugs). This also leads to
ineffective code in the implementation, because it has to scan over the whole
topology to find a node by its ID. Instead, these classes should operate with
consistent IDs.
> MessageService should use conistent IDs instead of node IDs
> ---
>
> Key: IGNITE-18063
> URL: https://issues.apache.org/jira/browse/IGNITE-18063
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> For some reason {{MessageService}} class and its users (e.g.
> `InternalTable#assignments`) use node IDs, which can change if a node is
> restarted (and lead to unknown and untested bugs). This also leads to
> ineffective code in the implementation, because it has to scan over the whole
> topology to find a node by its ID. Instead, these classes should operate with
> consistent IDs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17928) Initial SQL support analysis for Mandatory features
[ https://issues.apache.org/jira/browse/IGNITE-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17928: --- Description: Need to analyze SQL standard and check which Mandatory features SQL engine in Apache Ignite 3.0 support and which not. As a result, it requires create a document with proposed structure: feature id, feature name, sub feature id, sub feature name, is supported, link to existing tests, comments As basis standard let's use ISO/IEC 9075 2016 Support of Optional features will be investigated under separate ticket was: Need to analyze SQL standard and check which features SQL engine in Apache Ignite 3.0 support and which not. As a result, it requires create a document with proposed structure: feature id, feature name, sub feature id, sub feature name, is supported, link to existing tests, comments As basis standard let's use ISO/IEC 9075 2016 > Initial SQL support analysis for Mandatory features > --- > > Key: IGNITE-17928 > URL: https://issues.apache.org/jira/browse/IGNITE-17928 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Need to analyze SQL standard and check which Mandatory features SQL engine in > Apache Ignite 3.0 support and which not. > As a result, it requires create a document with proposed structure: > feature id, feature name, sub feature id, sub feature name, is supported, > link to existing tests, comments > As basis standard let's use ISO/IEC 9075 2016 > Support of Optional features will be investigated under separate ticket -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17928) Initial SQL support analysis for Mandatory features
[ https://issues.apache.org/jira/browse/IGNITE-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17928: --- Summary: Initial SQL support analysis for Mandatory features (was: SQL support analysis) > Initial SQL support analysis for Mandatory features > --- > > Key: IGNITE-17928 > URL: https://issues.apache.org/jira/browse/IGNITE-17928 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Need to analyze SQL standard and check which features SQL engine in Apache > Ignite 3.0 support and which not. > As a result, it requires create a document with proposed structure: > feature id, feature name, sub feature id, sub feature name, is supported, > link to existing tests, comments > As basis standard let's use ISO/IEC 9075 2016 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18063) MessageService should use conistent IDs instead of node IDs
Aleksandr Polovtcev created IGNITE-18063: Summary: MessageService should use conistent IDs instead of node IDs Key: IGNITE-18063 URL: https://issues.apache.org/jira/browse/IGNITE-18063 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17733) Change lock manager implementation
[ https://issues.apache.org/jira/browse/IGNITE-17733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-17733: - Summary: Change lock manager implementation (was: Chnage lock manager implementation) > Change lock manager implementation > -- > > Key: IGNITE-17733 > URL: https://issues.apache.org/jira/browse/IGNITE-17733 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > *Motivation:* > Lock manager should be based on _Wait-Die_ deadlock resolution strategy by > default. The conception is implemented in > [POC|https://github.com/ascherbakoff/ai3-txn-mvp]. > Since current implementation has another resolution strategy, some tests will > become failing. All those test should to be fixed as a part of the ticket. > *Definition of Done:* > Required to replace implementation of _HeapLockManager_ to [_Lock_ > |https://github.com/ascherbakoff/ai3-txn-mvp/blob/main/src/main/java/com/ascherbakoff/ai3/lock/Lock.java] > and adjusted API. > Hence, the lock resolution strategy is changed, it leads to failing of tests > from _AbstractLockManagerTest_ and _TxAbstractTest_. These failings have to > be fixed. > Property IGNITE_ALL_LOCK_TYPES_ARE_USED should be removed. > *Workaround:* > Until, this issue does not be fixed, we use lock only on primary keys. This > behavior is turned by property IGNITE_ALL_LOCK_TYPES_ARE_USED. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18062) [ducktests] TransactionsTests.test_tx_info is broken
[
https://issues.apache.org/jira/browse/IGNITE-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-18062:
-
Labels: ducktests (was: )
> [ducktests] TransactionsTests.test_tx_info is broken
>
>
> Key: IGNITE-18062
> URL: https://issues.apache.org/jira/browse/IGNITE-18062
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
> Attachments: logs.tgz
>
>
> *control_utility.tx_test.TransactionsTests.test_tx_info* test fails after
> changes in control.sh logging (IGNITE-18010)
> {noformat}
> Traceback (most recent call last):
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 133, in run
> data = self.run_test()
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 197, in run_test
> return self.test_context.function(self.test)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/mark/_mark.py",
> line 429, in wrapper
> return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/utils/_mark.py",
> line 233, in extended_test
> test_result = func(self, *args, **kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/tests/control_utility/tx_test.py",
> line 62, in test_tx_info
> assert res.xid == pick_tx.xid
> AttributeError: 'NoneType' object has no attribute 'xid'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18062) [ducktests] TransactionsTests.test_tx_info is broken
[
https://issues.apache.org/jira/browse/IGNITE-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-18062:
-
Attachment: logs.tgz
> [ducktests] TransactionsTests.test_tx_info is broken
>
>
> Key: IGNITE-18062
> URL: https://issues.apache.org/jira/browse/IGNITE-18062
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Priority: Minor
> Attachments: logs.tgz
>
>
> *control_utility.tx_test.TransactionsTests.test_tx_info* test fails after
> changes in control.sh logging (IGNITE-18010)
> {noformat}
> Traceback (most recent call last):
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 133, in run
> data = self.run_test()
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 197, in run_test
> return self.test_context.function(self.test)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/mark/_mark.py",
> line 429, in wrapper
> return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/utils/_mark.py",
> line 233, in extended_test
> test_result = func(self, *args, **kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/tests/control_utility/tx_test.py",
> line 62, in test_tx_info
> assert res.xid == pick_tx.xid
> AttributeError: 'NoneType' object has no attribute 'xid'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18062) [ducktests] TransactionsTests.test_tx_info is broken
Sergey Korotkov created IGNITE-18062:
Summary: [ducktests] TransactionsTests.test_tx_info is broken
Key: IGNITE-18062
URL: https://issues.apache.org/jira/browse/IGNITE-18062
Project: Ignite
Issue Type: Test
Reporter: Sergey Korotkov
*control_utility.tx_test.TransactionsTests.test_tx_info* test fails after
changes in control.sh logging (IGNITE-18010)
{noformat}
Traceback (most recent call last):
File
"/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
line 133, in run
data = self.run_test()
File
"/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
line 197, in run_test
return self.test_context.function(self.test)
File
"/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/mark/_mark.py",
line 429, in wrapper
return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs)
File
"/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/utils/_mark.py",
line 233, in extended_test
test_result = func(self, *args, **kwargs)
File
"/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/tests/control_utility/tx_test.py",
line 62, in test_tx_info
assert res.xid == pick_tx.xid
AttributeError: 'NoneType' object has no attribute 'xid'
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17930) Add javadoc plugin to gradle build
[ https://issues.apache.org/jira/browse/IGNITE-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-17930: -- Assignee: Aleksandr (was: Mikhail Pochatkin) > Add javadoc plugin to gradle build > -- > > Key: IGNITE-17930 > URL: https://issues.apache.org/jira/browse/IGNITE-17930 > Project: Ignite > Issue Type: Task > Components: build >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Maven build allows us to generate Javadoc from sources but Gradle does not. > We have to add Javadoc generation task to the Gradle build and adjust > DEVNOTES.md. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17771) Get rid of internal classes in API module.
[ https://issues.apache.org/jira/browse/IGNITE-17771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627514#comment-17627514 ] Yury Gerzhedovich commented on IGNITE-17771: [~amashenkov] , LGTM. Thanks for the contribution! > Get rid of internal classes in API module. > -- > > Key: IGNITE-17771 > URL: https://issues.apache.org/jira/browse/IGNITE-17771 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3, tech-debt > Time Spent: 40m > Remaining Estimate: 0h > > Let's move 2 internal classes from ignite-api module. > # org.apache.ignite.internal.sql.ResultSetImpl > # org.apache.ignite.internal.sql.SqlColumnTypeConverter > h3. Motivation. > ResultSetImpl is just a wrapper over asynchronous resultset and was > introduced to avoid unwanted code duplication as it is used in 2 modules > (client and sql-engine). > However, we may want to convert exception in different ways on clients and in > embedded mode. So, having 2 similar implementations look acceptable. > SqlColumnTypeConverter is utility class with a single static method, which > converts SqlColumnType -> Java class. We can get rid of the class and add > SqlColumnType.toJavaType() method instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18061) Design placement driver
[ https://issues.apache.org/jira/browse/IGNITE-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-18061: - Description: h3. Motivation Well, requirements are a bit hazy. Placement driver should definitely: * Provide engine for primary replica selection and failover. * Either itself of, indirectly through replicas, generate notifications about primary replica change. * Answer the question of primary replica placement(mapping to the ClusterNode), and corresponding lease interval in assumption that there'll be leases. * Answer the question of non-primary replicas placment. * Answer the question about replication group state. Is majority available? Is replication(raft) server up and running for the particular replica? etc. h3. Definition of Done * Requirements to the placement driver are clear. * The contract of the placement driver and its area of responsibility is defined. * Aforementioned contract meets all known requirements. * Design is ready. was: h3. Motivation Well, requirements are a bit hazy. Placement driver should definitely: * Provide engine for primary replica selection and failover. * Either itself of, indirectly through replicas, generate notifications about primary replica change. * Answer the question of primary replica placement(mapping to the ClusterNode), and corresponding lease interval in assumption that there'll be leases. * Answer the question of non-primary replicas placment. * Answer the question about replication group state. Is majority available? Is replication(raft) server up and running for the particular replica? etc. h3. Definition of Done * The contract of the placement driver and its area of responsibility is defined. * Aforementioned contract covers meets all known requirements. * Design is ready. > Design placement driver > --- > > Key: IGNITE-18061 > URL: https://issues.apache.org/jira/browse/IGNITE-18061 > Project: Ignite > Issue Type: New Feature >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > Well, requirements are a bit hazy. Placement driver should definitely: > * Provide engine for primary replica selection and failover. > * Either itself of, indirectly through replicas, generate notifications > about primary replica change. > * Answer the question of primary replica placement(mapping to the > ClusterNode), and corresponding lease interval in assumption that there'll be > leases. > * Answer the question of non-primary replicas placment. > * Answer the question about replication group state. Is majority available? > Is replication(raft) server up and running for the particular replica? etc. > h3. Definition of Done > * Requirements to the placement driver are clear. > * The contract of the placement driver and its area of responsibility is > defined. > * Aforementioned contract meets all known requirements. > * Design is ready. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18061) Design placement driver
Alexander Lapin created IGNITE-18061: Summary: Design placement driver Key: IGNITE-18061 URL: https://issues.apache.org/jira/browse/IGNITE-18061 Project: Ignite Issue Type: New Feature Reporter: Alexander Lapin Assignee: Alexander Lapin h3. Motivation Well, requirements are a bit hazy. Placement driver should definitely: * Provide engine for primary replica selection and failover. * Either itself of, indirectly through replicas, generate notifications about primary replica change. * Answer the question of primary replica placement(mapping to the ClusterNode), and corresponding lease interval in assumption that there'll be leases. * Answer the question of non-primary replicas placment. * Answer the question about replication group state. Is majority available? Is replication(raft) server up and running for the particular replica? etc. h3. Definition of Done * The contract of the placement driver and its area of responsibility is defined. * Aforementioned contract covers meets all known requirements. * Design is ready. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18060) Prepare design and tickets breakdown for rebalance over replicas
Alexander Lapin created IGNITE-18060:
Summary: Prepare design and tickets breakdown for rebalance over
replicas
Key: IGNITE-18060
URL: https://issues.apache.org/jira/browse/IGNITE-18060
Project: Ignite
Issue Type: New Feature
Reporter: Alexander Lapin
Assignee: Kirill Gusakov
h3. Motivation
Current rebalance design specified in
{code:java}
ignite-3/modules/table/tech-notes/rebalance.md {code}
is a bit complicated. The good news is that it can be simplified using the
following mechanics:
* Meta storage over learners, meaning that every cluster node will have meta
storage locally.
* Rebalance over replicas, meaning that there will be useful abstraction of
(at most) single actor in replication group, better known as primary replica.
* Meta storage over version values, meaning that it'll be possible to
eliminate the requirement of single-threaded meta storage watch, that, among
other things, will also eliminate watch-redeployment procedure.
All in all, given ticket is only about over replicas part. So, it's required to
prototype and design new rebalance algorithm on top of at most single actor
invariant. Among the key potential difficulties, I would highlight the
following set:
* Stale triggers. Primary replica that manages rebalance could still be
notified about stale updates, that will required ms invokes over trigger
revision.
* It's required to take into consideration in-memory replicas switch logic.
h3. Definition of Done
* Either new design along with tickets breakdown for rebalance over replicas
(at most single actor) is ready or list of substantial arguments that the use
of replicas does not simplify the rebalancing algorithm is provided.
* Proposed replica based logic should be simple, it's not worth to waste time
for micro enhancements. In that case we should consider system table as an
alternative.
* Thus high level design of rebalance over system table is also expected. All
in all we should compare whether it's easier to have (ms based, replica based)
approach or implement system tables and build rebalance logic on top of it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18059) .NET: Thin 3.0: Error codes should be constants
[
https://issues.apache.org/jira/browse/IGNITE-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18059:
Ignite Flags: (was: Docs Required,Release Notes Required)
> .NET: Thin 3.0: Error codes should be constants
> ---
>
> Key: IGNITE-18059
> URL: https://issues.apache.org/jira/browse/IGNITE-18059
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, error codes in generated *ErrorGroups* class are *static readonly
> int*, because we calculate them at runtime with *GetFullCode*.
> However, this prevents pattern matching. The following does not work:
> {code}
> if (e is IgniteClientConnectionException { Code:
> ErrorGroups.Client.ClusterIdMismatch })
> {
> ...
> }
> {code}
> Compiler error: *[CS0150] A constant value is expected*.
> Since we use code generation, it is easy to compute error codes at compile
> time and use constants to make things nicer for the users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18059) .NET: Thin 3.0: Error codes should be constants
[
https://issues.apache.org/jira/browse/IGNITE-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18059:
Description:
Currently, error codes in generated *ErrorGroups* class are *static readonly
int*, because we calculate them at runtime with *GetFullCode*.
However, this prevents pattern matching. The following does not work:
{code}
if (e is IgniteClientConnectionException { Code:
ErrorGroups.Client.ClusterIdMismatch })
{
...
}
{code}
Compiler error: *[CS0150] A constant value is expected*.
Since we use code generation, it is easy to compute error codes at compile time
and use constants to make things nicer for the users.
> .NET: Thin 3.0: Error codes should be constants
> ---
>
> Key: IGNITE-18059
> URL: https://issues.apache.org/jira/browse/IGNITE-18059
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, error codes in generated *ErrorGroups* class are *static readonly
> int*, because we calculate them at runtime with *GetFullCode*.
> However, this prevents pattern matching. The following does not work:
> {code}
> if (e is IgniteClientConnectionException { Code:
> ErrorGroups.Client.ClusterIdMismatch })
> {
> ...
> }
> {code}
> Compiler error: *[CS0150] A constant value is expected*.
> Since we use code generation, it is easy to compute error codes at compile
> time and use constants to make things nicer for the users.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18059) .NET: Thin 3.0: Error codes should be constants
Pavel Tupitsyn created IGNITE-18059: --- Summary: .NET: Thin 3.0: Error codes should be constants Key: IGNITE-18059 URL: https://issues.apache.org/jira/browse/IGNITE-18059 Project: Ignite Issue Type: Improvement Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18058) .NET: Thin 3.0: Socket read never times out
[ https://issues.apache.org/jira/browse/IGNITE-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18058: Labels: .NET ignite-3 (was: ignite-3) > .NET: Thin 3.0: Socket read never times out > --- > > Key: IGNITE-18058 > URL: https://issues.apache.org/jira/browse/IGNITE-18058 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > If the server does not respond, we hang forever in > *ClientSocket.ReceiveBytesAsync*. > We have *IgniteClientConfiguration.SocketTimeout*, but it is not actually > used anywhere. -- This message was sent by Atlassian Jira (v8.20.10#820010)
