[jira] [Created] (IGNITE-20314) Ignite Java documentation missing required --add-opens
Patrick Peralta created IGNITE-20314:
Summary: Ignite Java documentation missing required --add-opens
Key: IGNITE-20314
URL: https://issues.apache.org/jira/browse/IGNITE-20314
Project: Ignite
Issue Type: Improvement
Components: documentation
Affects Versions: 2.15
Reporter: Patrick Peralta
As indicated in IGNITE-17658,
{{--add-opens=java.base/java.lang.invoke=ALL-UNNAMED}} is required to serialize
lambdas.
However this flag is not included in the Java 17 section of the Ignite Java
Quick Start guide: [https://ignite.apache.org/docs/latest/quick-start/java]
Please add this so that Ignite users that require serialization of lambdas
(such as scan query filters and entry processors) don't run into this problem:
{code:java}
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final java.lang.Class java.lang.invoke.SerializedLambda.capturingClass
accessible: module java.base does not "opens java.lang.invoke" to unnamed
module @41a4555e
at
java.base/java.lang.reflect.AccessibleObject.throwInaccessibleObjectException(AccessibleObject.java:387)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:363)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:311)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:181)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:175)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.(BinaryClassDescriptor.java:354)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.(BinaryClassDescriptor.java:156)
at
org.apache.ignite.internal.binary.BinaryContext.createDescriptorForClass(BinaryContext.java:675)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:633)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:182)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:227)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:152)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
at
org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:84)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
at
org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10873)
... 22 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20300) Metastorage command reordering wrt Safe Time on Raft Group entry
[ https://issues.apache.org/jira/browse/IGNITE-20300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760575#comment-17760575 ] Roman Puchkovskiy commented on IGNITE-20300: Thanks! > Metastorage command reordering wrt Safe Time on Raft Group entry > > > Key: IGNITE-20300 > URL: https://issues.apache.org/jira/browse/IGNITE-20300 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Safe time is updated on write commands just before they are added to JRaft's > LogManager. But this is done in many threads and there is no enough > synchronization, so it's possible that a command with a higher timestamp gets > linearized before a command with a lower timestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20299) Creating a cache with an unknown data region name causes total unrecoverable failure of the grid
[ https://issues.apache.org/jira/browse/IGNITE-20299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760136#comment-17760136 ] Raymond Wilson edited comment on IGNITE-20299 at 8/30/23 6:31 PM: -- I think persistence is an important aspect for this issue as it is on restart that the grid complains that it cannot (a) start the incorrectly created cache (which raises the question as to why it is still known about if creation of it was unsuccessful) and (b) fails to initialise the persisted caches. The cache folder for the incorrectly create cache is also constructed which indicates that the grid has somehow accepted the cache as a valid new cache while at the same time throwing the exchange process exception, all of which indicates the validation of the parameters for the new cache is not enforcing the requirement for the data region to be known. was (Author: rpwilson): I think persistence is an important for this issue as it is on restart that the grid complains that it cannot (a) start the incorrectly created cache (which raises the question as to why it is still known about if creation of it was unsuccessful) and (b) fails to initialise the persisted caches. The cache folder for the incorrectly create cache is also constructed which indicates that the grid has somehow accepted the cache as a valid new cache while at the same time throwing the exchange process exception, all of which indicates the validation of the parameters for the new cache is not enforcing the requirement for the data region to be known. > Creating a cache with an unknown data region name causes total unrecoverable > failure of the grid > > > Key: IGNITE-20299 > URL: https://issues.apache.org/jira/browse/IGNITE-20299 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.15 > Environment: Observed in: > C# client and grid running on Linux in a container > C# client and grid running on Windows > >Reporter: Raymond Wilson >Priority: Major > > Using the Ignite C# client. > > Given a running grid, having a client (and perhaps server) node in the grid > attempt to create a cache using a DataRegionName that does not exist in the > grid causes immediate failure in the client node with the following log > output. > > 2023-08-27 17:08:48,520 [44] INF [ImmutableClientServer] Completed > partition exchange [localNode=15122bd7-bf81-44e6-a548-e70dbd9334c0, > exchange=GridDhtPartitionsExchangeFuture [topVer=AffinityTopologyVersion > [topVer=15, minorTopVer=0], evt=NODE_FAILED, evtNode=TcpDiscoveryNode > [id=9d5ed68d-38bb-447d-aed5-189f52660716, > consistentId=9d5ed68d-38bb-447d-aed5-189f52660716, addrs=ArrayList > [127.0.0.1], sockAddrs=null, discPort=0, order=8, intOrder=8, > lastExchangeTime=1693112858024, loc=false, ver=2.15.0#20230425-sha1:f98f7f35, > isClient=true], rebalanced=false, done=true, newCrdFut=null], > topVer=AffinityTopologyVersion [topVer=15, minorTopVer=0]] > 2023-08-27 17:08:48,520 [44] INF [ImmutableClientServer] Exchange timings > [startVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], > resVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], stage="Waiting in > exchange queue" (14850 ms), stage="Exchange parameters initialization" (2 > ms), stage="Determine exchange type" (3 ms), stage="Exchange done" (4 ms), > stage="Total time" (14859 ms)] > 2023-08-27 17:08:48,522 [44] INF [ImmutableClientServer] Exchange longest > local stages [startVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], > resVer=AffinityTopologyVersion [topVer=15, minorTopVer=0]] > 2023-08-27 17:08:48,524 [44] INF [ImmutableClientServer] Finished exchange > init [topVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], crd=false] > 2023-08-27 17:08:48,525 [44] INF [ImmutableClientServer] > AffinityTopologyVersion [topVer=15, minorTopVer=0], evt=NODE_FAILED, > evtNode=9d5ed68d-38bb-447d-aed5-189f52660716, client=true] > Unhandled exception: Apache.Ignite.Core.Cache.CacheException: class > org.apache.ignite.IgniteCheckedException: Failed to complete exchange process. > ---> Apache.Ignite.Core.Common.IgniteException: Failed to complete exchange > process. > ---> Apache.Ignite.Core.Common.JavaException: javax.cache.CacheException: > class org.apache.ignite.IgniteCheckedException: Failed to complete exchange > process. > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1272) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache0(IgniteKernal.java:2278) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2242) > at >
[jira] [Updated] (IGNITE-20299) Creating a cache with an unknown data region name causes total unrecoverable failure of the grid
[ https://issues.apache.org/jira/browse/IGNITE-20299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Wilson updated IGNITE-20299: Description: Using the Ignite C# client. Given a running grid, having a client (and perhaps server) node in the grid attempt to create a cache using a DataRegionName that does not exist in the grid causes immediate failure in the client node with the following log output. 2023-08-27 17:08:48,520 [44] INF [ImmutableClientServer] Completed partition exchange [localNode=15122bd7-bf81-44e6-a548-e70dbd9334c0, exchange=GridDhtPartitionsExchangeFuture [topVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], evt=NODE_FAILED, evtNode=TcpDiscoveryNode [id=9d5ed68d-38bb-447d-aed5-189f52660716, consistentId=9d5ed68d-38bb-447d-aed5-189f52660716, addrs=ArrayList [127.0.0.1], sockAddrs=null, discPort=0, order=8, intOrder=8, lastExchangeTime=1693112858024, loc=false, ver=2.15.0#20230425-sha1:f98f7f35, isClient=true], rebalanced=false, done=true, newCrdFut=null], topVer=AffinityTopologyVersion [topVer=15, minorTopVer=0]] 2023-08-27 17:08:48,520 [44] INF [ImmutableClientServer] Exchange timings [startVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], resVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], stage="Waiting in exchange queue" (14850 ms), stage="Exchange parameters initialization" (2 ms), stage="Determine exchange type" (3 ms), stage="Exchange done" (4 ms), stage="Total time" (14859 ms)] 2023-08-27 17:08:48,522 [44] INF [ImmutableClientServer] Exchange longest local stages [startVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], resVer=AffinityTopologyVersion [topVer=15, minorTopVer=0]] 2023-08-27 17:08:48,524 [44] INF [ImmutableClientServer] Finished exchange init [topVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], crd=false] 2023-08-27 17:08:48,525 [44] INF [ImmutableClientServer] AffinityTopologyVersion [topVer=15, minorTopVer=0], evt=NODE_FAILED, evtNode=9d5ed68d-38bb-447d-aed5-189f52660716, client=true] Unhandled exception: Apache.Ignite.Core.Cache.CacheException: class org.apache.ignite.IgniteCheckedException: Failed to complete exchange process. ---> Apache.Ignite.Core.Common.IgniteException: Failed to complete exchange process. ---> Apache.Ignite.Core.Common.JavaException: javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: Failed to complete exchange process. at org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1272) at org.apache.ignite.internal.IgniteKernal.getOrCreateCache0(IgniteKernal.java:2278) at org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2242) at org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutObject(PlatformProcessorImpl.java:643) at org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79) Caused by: class org.apache.ignite.IgniteCheckedException: Failed to complete exchange process. at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createExchangeException(GridDhtPartitionsExchangeFuture.java:3709) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendExchangeFailureMessage(GridDhtPartitionsExchangeFuture.java:3737) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3832) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3813) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1796) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:1053) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3348) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3182) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) at java.base/java.lang.Thread.run(Thread.java:829) Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to initialize exchange locally [locNodeId=e9325b04-00fa-452e-9796-989b47b860ea] at
[jira] [Commented] (IGNITE-19902) Client tx partition awareness
[ https://issues.apache.org/jira/browse/IGNITE-19902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760553#comment-17760553 ] Pavel Tupitsyn commented on IGNITE-19902: - [~alapin] can you please provide more details? > Client tx partition awareness > - > > Key: IGNITE-19902 > URL: https://issues.apache.org/jira/browse/IGNITE-19902 > Project: Ignite > Issue Type: Epic > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Alexander Lapin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > TBD -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20309) Snapshot creation returns OK even if check failed
[
https://issues.apache.org/jira/browse/IGNITE-20309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760509#comment-17760509
]
Ignite TC Bot commented on IGNITE-20309:
{panel:title=Branch: [pull/10913/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10913/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Disk Page Compressions 1{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7322534]]
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=false,
onlyPrimay=true] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=false,
onlyPrimay=false] - PASSED{color}
{color:#8b}Snapshots{color} [[tests
4|https://ci2.ignite.apache.org/viewLog.html?buildId=7322555]]
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=false,
onlyPrimay=true] - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=false,
onlyPrimay=false] - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=true,
onlyPrimay=true] - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=true,
onlyPrimay=false] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7321997buildTypeId=IgniteTests24Java8_RunAll]
> Snapshot creation returns OK even if check failed
> -
>
> Key: IGNITE-20309
> URL: https://issues.apache.org/jira/browse/IGNITE-20309
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Currently, {{SnapshotPartitionsQuickVerifyHandler#complete}} don't fail
> snapshot even if {{invoke}} throws.
> Reproducer:
>
> {noformat}
> /**
> * Test ensures that snapshot fail if during check some files are absent.
> * @see SnapshotPartitionsQuickVerifyHandler
> */
> @Test
> public void testHandlerExceptionFailSnapshot() throws Exception {
> handlers.add(new SnapshotHandler() {
> @Override public SnapshotHandlerType type() {
> return SnapshotHandlerType.CREATE;
> }
> @Override public Void invoke(SnapshotHandlerContext ctx) {
> // Someone remove snapshot files during creation.
> // In this case snapshot must fail.
> U.delete(ctx.snapshotDirectory());
> return null;
> }
> });
> IgniteEx ignite = startGridsWithCache(1, CACHE_KEYS_RANGE,
> valueBuilder(), dfltCacheCfg);
> assertThrows(
> null,
> () -> snp(ignite).createSnapshot("must_fail", null, false,
> onlyPrimary).get(getTestTimeout()),
> IgniteException.class,
> "Snapshot data doesn't contain required cache group partition"
> );
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20309) Snapshot creation returns OK even if check failed
[
https://issues.apache.org/jira/browse/IGNITE-20309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-20309:
-
Fix Version/s: 2.16
> Snapshot creation returns OK even if check failed
> -
>
> Key: IGNITE-20309
> URL: https://issues.apache.org/jira/browse/IGNITE-20309
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Currently, {{SnapshotPartitionsQuickVerifyHandler#complete}} don't fail
> snapshot even if {{invoke}} throws.
> Reproducer:
>
> {noformat}
> /**
> * Test ensures that snapshot fail if during check some files are absent.
> * @see SnapshotPartitionsQuickVerifyHandler
> */
> @Test
> public void testHandlerExceptionFailSnapshot() throws Exception {
> handlers.add(new SnapshotHandler() {
> @Override public SnapshotHandlerType type() {
> return SnapshotHandlerType.CREATE;
> }
> @Override public Void invoke(SnapshotHandlerContext ctx) {
> // Someone remove snapshot files during creation.
> // In this case snapshot must fail.
> U.delete(ctx.snapshotDirectory());
> return null;
> }
> });
> IgniteEx ignite = startGridsWithCache(1, CACHE_KEYS_RANGE,
> valueBuilder(), dfltCacheCfg);
> assertThrows(
> null,
> () -> snp(ignite).createSnapshot("must_fail", null, false,
> onlyPrimary).get(getTestTimeout()),
> IgniteException.class,
> "Snapshot data doesn't contain required cache group partition"
> );
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20309) Snapshot creation returns OK even if check failed
[
https://issues.apache.org/jira/browse/IGNITE-20309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-20309:
-
Labels: ise (was: )
> Snapshot creation returns OK even if check failed
> -
>
> Key: IGNITE-20309
> URL: https://issues.apache.org/jira/browse/IGNITE-20309
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: ise
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Currently, {{SnapshotPartitionsQuickVerifyHandler#complete}} don't fail
> snapshot even if {{invoke}} throws.
> Reproducer:
>
> {noformat}
> /**
> * Test ensures that snapshot fail if during check some files are absent.
> * @see SnapshotPartitionsQuickVerifyHandler
> */
> @Test
> public void testHandlerExceptionFailSnapshot() throws Exception {
> handlers.add(new SnapshotHandler() {
> @Override public SnapshotHandlerType type() {
> return SnapshotHandlerType.CREATE;
> }
> @Override public Void invoke(SnapshotHandlerContext ctx) {
> // Someone remove snapshot files during creation.
> // In this case snapshot must fail.
> U.delete(ctx.snapshotDirectory());
> return null;
> }
> });
> IgniteEx ignite = startGridsWithCache(1, CACHE_KEYS_RANGE,
> valueBuilder(), dfltCacheCfg);
> assertThrows(
> null,
> () -> snp(ignite).createSnapshot("must_fail", null, false,
> onlyPrimary).get(getTestTimeout()),
> IgniteException.class,
> "Snapshot data doesn't contain required cache group partition"
> );
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20309) Snapshot creation returns OK even if check failed
[
https://issues.apache.org/jira/browse/IGNITE-20309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760510#comment-17760510
]
Ignite TC Bot commented on IGNITE-20309:
{panel:title=Branch: [pull/10913/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10913/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Disk Page Compressions 1{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7322534]]
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=false,
onlyPrimay=true] - PASSED{color}
* {color:#013220}IgnitePdsCompressionTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=false,
onlyPrimay=false] - PASSED{color}
{color:#8b}Snapshots{color} [[tests
4|https://ci2.ignite.apache.org/viewLog.html?buildId=7322555]]
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=false,
onlyPrimay=true] - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=false,
onlyPrimay=false] - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=true,
onlyPrimay=true] - PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotHandlerTest.testHandlerExceptionFailSnapshot[encryption=true,
onlyPrimay=false] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7321997buildTypeId=IgniteTests24Java8_RunAll]
> Snapshot creation returns OK even if check failed
> -
>
> Key: IGNITE-20309
> URL: https://issues.apache.org/jira/browse/IGNITE-20309
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Currently, {{SnapshotPartitionsQuickVerifyHandler#complete}} don't fail
> snapshot even if {{invoke}} throws.
> Reproducer:
>
> {noformat}
> /**
> * Test ensures that snapshot fail if during check some files are absent.
> * @see SnapshotPartitionsQuickVerifyHandler
> */
> @Test
> public void testHandlerExceptionFailSnapshot() throws Exception {
> handlers.add(new SnapshotHandler() {
> @Override public SnapshotHandlerType type() {
> return SnapshotHandlerType.CREATE;
> }
> @Override public Void invoke(SnapshotHandlerContext ctx) {
> // Someone remove snapshot files during creation.
> // In this case snapshot must fail.
> U.delete(ctx.snapshotDirectory());
> return null;
> }
> });
> IgniteEx ignite = startGridsWithCache(1, CACHE_KEYS_RANGE,
> valueBuilder(), dfltCacheCfg);
> assertThrows(
> null,
> () -> snp(ignite).createSnapshot("must_fail", null, false,
> onlyPrimary).get(getTestTimeout()),
> IgniteException.class,
> "Snapshot data doesn't contain required cache group partition"
> );
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20309) Snapshot creation returns OK even if check failed
[
https://issues.apache.org/jira/browse/IGNITE-20309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov resolved IGNITE-20309.
--
Resolution: Fixed
> Snapshot creation returns OK even if check failed
> -
>
> Key: IGNITE-20309
> URL: https://issues.apache.org/jira/browse/IGNITE-20309
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Currently, {{SnapshotPartitionsQuickVerifyHandler#complete}} don't fail
> snapshot even if {{invoke}} throws.
> Reproducer:
>
> {noformat}
> /**
> * Test ensures that snapshot fail if during check some files are absent.
> * @see SnapshotPartitionsQuickVerifyHandler
> */
> @Test
> public void testHandlerExceptionFailSnapshot() throws Exception {
> handlers.add(new SnapshotHandler() {
> @Override public SnapshotHandlerType type() {
> return SnapshotHandlerType.CREATE;
> }
> @Override public Void invoke(SnapshotHandlerContext ctx) {
> // Someone remove snapshot files during creation.
> // In this case snapshot must fail.
> U.delete(ctx.snapshotDirectory());
> return null;
> }
> });
> IgniteEx ignite = startGridsWithCache(1, CACHE_KEYS_RANGE,
> valueBuilder(), dfltCacheCfg);
> assertThrows(
> null,
> () -> snp(ignite).createSnapshot("must_fail", null, false,
> onlyPrimary).get(getTestTimeout()),
> IgniteException.class,
> "Snapshot data doesn't contain required cache group partition"
> );
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19768) Port configured tables workaround from configuration to Catalog
[
https://issues.apache.org/jira/browse/IGNITE-19768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-19768:
-
Assignee: Andrey Mashenkov
> Port configured tables workaround from configuration to Catalog
> ---
>
> Key: IGNITE-19768
> URL: https://issues.apache.org/jira/browse/IGNITE-19768
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, TableManager contains a workaround (for a problem of getting of
> the most recent schemas without a proper Schema Sync mechanism), it works
> like this: on each attempt to resolve a table by ID, we look into the
> configuration to make sure that the table with this ID is created and not
> dropped yet. Also, we look into the configuration on each attempt to get a
> list of all tables.
> A switch from Configuration to the Catalog is under way, so we need to switch
> this workaround from Configuration to the Catalog as well.
> {{ConfiguredTablesCache}} needs to be modified to achieve this.
> An alternative would to be implement both the switch from Configuration to
> Catalog AND introduction of the proper Schema Sync at once, but this will
> greatly complicate the matters, it seems to be better to do these changes one
> after another (first Catalog, then Schema Sync).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20303) "Raft group on the node is already started" exception when pending and planned assignment changed faster then rebalance
[
https://issues.apache.org/jira/browse/IGNITE-20303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel reassigned IGNITE-20303:
--
Assignee: Sergey Uttsel
> "Raft group on the node is already started" exception when pending and
> planned assignment changed faster then rebalance
> ---
>
> Key: IGNITE-20303
> URL: https://issues.apache.org/jira/browse/IGNITE-20303
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
>
> If many changes of assignment are happened quickly then rebalance does not
> have time to be completed for each change. In this case exception is thrown:
> {code:java}
> 2023-08-24T16:58:51,328][ERROR][%irdt_ttqr_2%tableManager-io-10][WatchProcessor]
> Error occurred when processing a watch event
> org.apache.ignite.lang.IgniteInternalException: Raft group on the node is
> already started [nodeId=RaftNodeId [groupId=1_part_0, peer=Peer
> [consistentId=irdt_ttqr_2, idx=0]]]
> at
> org.apache.ignite.internal.raft.Loza.startRaftGroupNodeInternal(Loza.java:342)
> ~[main/:?]
> at
> org.apache.ignite.internal.raft.Loza.startRaftGroupNode(Loza.java:230)
> ~[main/:?]
> at
> org.apache.ignite.internal.raft.Loza.startRaftGroupNode(Loza.java:203)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.TableManager.startPartitionRaftGroupNode(TableManager.java:2361)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$handleChangePendingAssignmentEvent$98(TableManager.java:2261)
> ~[main/:?]
> at
> org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:922)
> ~[main/:?]
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$handleChangePendingAssignmentEvent$99(TableManager.java:2259)
> ~[main/:?]
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> at java.lang.Thread.run(Thread.java:834) ~[?:?]
> {code}
> The reproducer based on ItRebalanceDistributedTest#testThreeQueuedRebalances.
> See exception in the test log:
> {code:java}
> @Test
> void testThreeQueuedRebalances() throws Exception {
> Node node = getNode(0);
> createZone(node, ZONE_NAME, 1, 1);
> createTable(node, ZONE_NAME, TABLE_NAME);
> assertTrue(waitForCondition(() -> getPartitionClusterNodes(node,
> 0).size() == 1, AWAIT_TIMEOUT_MILLIS));
> alterZone(node, ZONE_NAME, 2);
> alterZone(node, ZONE_NAME, 3);
> alterZone(node, ZONE_NAME, 2);
> alterZone(node, ZONE_NAME, 3);
> alterZone(node, ZONE_NAME, 2);
> alterZone(node, ZONE_NAME, 3);
> alterZone(node, ZONE_NAME, 2);
> alterZone(node, ZONE_NAME, 3);
> alterZone(node, ZONE_NAME, 2);
> alterZone(node, ZONE_NAME, 3);
> alterZone(node, ZONE_NAME, 2);
> waitPartitionAssignmentsSyncedToExpected(0, 2);
> checkPartitionNodes(0, 2);
> }
> {code}
> We can fix it by a check if the raft node and the Replica are created before
> startPartitionRaftGroupNode and startReplicaWithNewListener in
> TableManager#handleChangePendingAssignmentEvent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20279) Reordering of altering zone operations
[
https://issues.apache.org/jira/browse/IGNITE-20279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20279:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Reordering of altering zone operations
> --
>
> Key: IGNITE-20279
> URL: https://issues.apache.org/jira/browse/IGNITE-20279
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The issue is shown in the test, where several zone change operations occur.
> In this case, the operation can be reordered and incomplete at the end of the
> test. There are messages "Received update for replicas number" in the test
> log in a wrong order. The reproducer based on
> ItRebalanceDistributedTest#testThreeQueuedRebalances:
> {code:java}
> @Test
> void testThreeQueuedRebalances() throws Exception {
> Node node = getNode(0);
> createZone(node, ZONE_NAME, 1, 1);
> createTable(node, ZONE_NAME, TABLE_NAME);
> assertTrue(waitForCondition(() -> getPartitionClusterNodes(node,
> 0).size() == 1, AWAIT_TIMEOUT_MILLIS));
> alterZone(node, ZONE_NAME, 2);
> alterZone(node, ZONE_NAME, 3);
> alterZone(node, ZONE_NAME, 2);
> alterZone(node, ZONE_NAME, 3);
> alterZone(node, ZONE_NAME, 2);
> alterZone(node, ZONE_NAME, 3);
> alterZone(node, ZONE_NAME, 2);
> alterZone(node, ZONE_NAME, 3);
> alterZone(node, ZONE_NAME, 2);
> alterZone(node, ZONE_NAME, 3);
> alterZone(node, ZONE_NAME, 2);
> waitPartitionAssignmentsSyncedToExpected(0, 2);
> checkPartitionNodes(0, 2);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20266) .NET: Thin 3.0: TestDataStreamerMetrics is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760395#comment-17760395
]
Pavel Tupitsyn commented on IGNITE-20266:
-
Merged to main: 9ba717a670927c785c12a640e899367e2bc8103f
> .NET: Thin 3.0: TestDataStreamerMetrics is flaky
>
>
> Key: IGNITE-20266
> URL: https://issues.apache.org/jira/browse/IGNITE-20266
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/test/5503643215833216881?currentProjectId=ApacheIgnite3xGradle_Test=true=
> {code}
> streamer-batches-active
> Expected: 1
> But was: 2
>at
> Apache.Ignite.Tests.MetricsTests.g__GetTuples|13_0()+MoveNext()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 248
>at System.Linq.AsyncEnumerable.AsyncEnumerableAdapter`1.MoveNextCore() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/Operators/ToAsyncEnumerable.cs:line
> 68
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncIterator.cs:line 70
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncIterator.cs:line 75
>at
> Apache.Ignite.Internal.Table.DataStreamer.StreamDataAsync[T](IAsyncEnumerable`1
> data, Func`4 sender, IRecordSerializerHandler`1 writer, Func`1
> schemaProvider, Func`1 partitionAssignmentProvider, DataStreamerOptions
> options, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/DataStreamer.cs:line
> 92
>at
> Apache.Ignite.Internal.Table.DataStreamer.StreamDataAsync[T](IAsyncEnumerable`1
> data, Func`4 sender, IRecordSerializerHandler`1 writer, Func`1
> schemaProvider, Func`1 partitionAssignmentProvider, DataStreamerOptions
> options, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/DataStreamer.cs:line
> 92
>at
> Apache.Ignite.Internal.Table.RecordView`1.StreamDataAsync(IAsyncEnumerable`1
> data, DataStreamerOptions options, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/RecordView.cs:line
> 300
>at Apache.Ignite.Tests.MetricsTests.TestDataStreamerMetrics() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 224
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.BeforeAndAfterTestCommand.<>c__DisplayClass1_0.b__0()
>at
> NUnit.Framework.Internal.Commands.DelegatingTestCommand.RunTestMethodInThreadAbortSafeZone(TestExecutionContext
> context, Action action)
> 1)at
> Apache.Ignite.Tests.MetricsTests.g__GetTuples|13_0()+MoveNext()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 248
>at System.Linq.AsyncEnumerable.AsyncEnumerableAdapter`1.MoveNextCore() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/Operators/ToAsyncEnumerable.cs:line
> 68
>at
> System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
> stateMachine)
>at System.Linq.AsyncEnumerable.AsyncEnumerableAdapter`1.MoveNextCore()
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncIterator.cs:line 70
>at
> System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
> stateMachine)
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync()
>at
> System.Runtime.CompilerServices.ConfiguredCancelableAsyncEnumerable`1.Enumerator.MoveNextAsync()
>at
> Apache.Ignite.Internal.Table.DataStreamer.StreamDataAsync[T](IAsyncEnumerable`1
> data, Func`4 sender, IRecordSerializerHandler`1 writer, Func`1
> schemaProvider, Func`1 partitionAssignmentProvider, DataStreamerOptions
> options, CancellationToken cancellationToken)
>at
>
[jira] [Assigned] (IGNITE-20181) KV/Binary view public API should only throw public exceptions for the end user.
[ https://issues.apache.org/jira/browse/IGNITE-20181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20181: - Assignee: Maksim Zhuravkov > KV/Binary view public API should only throw public exceptions for the end > user. > --- > > Key: IGNITE-20181 > URL: https://issues.apache.org/jira/browse/IGNITE-20181 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Revise the error handling of the KV/Binary view public API so that only a > public exception is thrown to the end user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20266) .NET: Thin 3.0: TestDataStreamerMetrics is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760354#comment-17760354
]
Igor Sapego commented on IGNITE-20266:
--
Looks good to me.
> .NET: Thin 3.0: TestDataStreamerMetrics is flaky
>
>
> Key: IGNITE-20266
> URL: https://issues.apache.org/jira/browse/IGNITE-20266
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/test/5503643215833216881?currentProjectId=ApacheIgnite3xGradle_Test=true=
> {code}
> streamer-batches-active
> Expected: 1
> But was: 2
>at
> Apache.Ignite.Tests.MetricsTests.g__GetTuples|13_0()+MoveNext()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 248
>at System.Linq.AsyncEnumerable.AsyncEnumerableAdapter`1.MoveNextCore() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/Operators/ToAsyncEnumerable.cs:line
> 68
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncIterator.cs:line 70
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncIterator.cs:line 75
>at
> Apache.Ignite.Internal.Table.DataStreamer.StreamDataAsync[T](IAsyncEnumerable`1
> data, Func`4 sender, IRecordSerializerHandler`1 writer, Func`1
> schemaProvider, Func`1 partitionAssignmentProvider, DataStreamerOptions
> options, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/DataStreamer.cs:line
> 92
>at
> Apache.Ignite.Internal.Table.DataStreamer.StreamDataAsync[T](IAsyncEnumerable`1
> data, Func`4 sender, IRecordSerializerHandler`1 writer, Func`1
> schemaProvider, Func`1 partitionAssignmentProvider, DataStreamerOptions
> options, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/DataStreamer.cs:line
> 92
>at
> Apache.Ignite.Internal.Table.RecordView`1.StreamDataAsync(IAsyncEnumerable`1
> data, DataStreamerOptions options, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/RecordView.cs:line
> 300
>at Apache.Ignite.Tests.MetricsTests.TestDataStreamerMetrics() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 224
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.BeforeAndAfterTestCommand.<>c__DisplayClass1_0.b__0()
>at
> NUnit.Framework.Internal.Commands.DelegatingTestCommand.RunTestMethodInThreadAbortSafeZone(TestExecutionContext
> context, Action action)
> 1)at
> Apache.Ignite.Tests.MetricsTests.g__GetTuples|13_0()+MoveNext()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 248
>at System.Linq.AsyncEnumerable.AsyncEnumerableAdapter`1.MoveNextCore() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/Operators/ToAsyncEnumerable.cs:line
> 68
>at
> System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
> stateMachine)
>at System.Linq.AsyncEnumerable.AsyncEnumerableAdapter`1.MoveNextCore()
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncIterator.cs:line 70
>at
> System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
> stateMachine)
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync()
>at
> System.Runtime.CompilerServices.ConfiguredCancelableAsyncEnumerable`1.Enumerator.MoveNextAsync()
>at
> Apache.Ignite.Internal.Table.DataStreamer.StreamDataAsync[T](IAsyncEnumerable`1
> data, Func`4 sender, IRecordSerializerHandler`1 writer, Func`1
> schemaProvider, Func`1 partitionAssignmentProvider, DataStreamerOptions
> options, CancellationToken cancellationToken)
>at
>
[jira] [Updated] (IGNITE-20313) Flaky ItSqlClientAsynchronousApiTest.errors
[
https://issues.apache.org/jira/browse/IGNITE-20313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20313:
---
Description:
ItSqlClientAsynchronousApiTest.error fails with a low fail rate. On local
environment it reproducible also.
Symptoms looks as one of test node has left cluster.
{code:java}
[2023-08-28T08:24:40,558][WARN
][%iscaat_n_2%tableManager-io-3][RaftGroupServiceImpl] Recoverable error during
the request type=GetLeaderRequestImpl occurred (will be retried on the randomly
selected node):
java.util.concurrent.CompletionException: java.net.ConnectException: Peer
iscaat_n_1 is unavailable
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
~[?:?]
at
java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
~[?:?]
at
java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
~[?:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:522)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:489)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:224)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:180)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.start(TopologyAwareRaftGroupService.java:182)
~[ignite-replicator-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupServiceFactory.startRaftGroupService(TopologyAwareRaftGroupServiceFactory.java:71)
~[ignite-replicator-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupService(Loza.java:321)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$createTablePartitionsLocally$11(TableManager.java:912)
~[ignite-table-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:905)
~[ignite-core-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$createTablePartitionsLocally$12(TableManager.java:909)
~[ignite-table-9.0.127-SNAPSHOT.jar:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
at
java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
Caused by: java.net.ConnectException: Peer iscaat_n_1 is unavailable
{code}
was:
ItSqlClientAsynchronousApiTest.error fails with a low fail rate. On local
environment it reproducable also.
Symptoms looks as one of test node has left cluster.
{code:java}
[2023-08-28T08:24:40,558][WARN
][%iscaat_n_2%tableManager-io-3][RaftGroupServiceImpl] Recoverable error during
the request type=GetLeaderRequestImpl occurred (will be retried on the randomly
selected node):
java.util.concurrent.CompletionException: java.net.ConnectException: Peer
iscaat_n_1 is unavailable
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
~[?:?]
at
java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
~[?:?]
at
java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
~[?:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:522)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:489)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:224)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:180)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.start(TopologyAwareRaftGroupService.java:182)
~[ignite-replicator-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupServiceFactory.startRaftGroupService(TopologyAwareRaftGroupServiceFactory.java:71)
~[ignite-replicator-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupService(Loza.java:321)
[jira] [Created] (IGNITE-20313) Flaky ItSqlClientAsynchronousApiTest.errors
Yury Gerzhedovich created IGNITE-20313:
--
Summary: Flaky ItSqlClientAsynchronousApiTest.errors
Key: IGNITE-20313
URL: https://issues.apache.org/jira/browse/IGNITE-20313
Project: Ignite
Issue Type: Improvement
Reporter: Yury Gerzhedovich
ItSqlClientAsynchronousApiTest.error fails with a low fail rate. On local
environment it reproducable also.
Symptoms looks as one of test node has left cluster.
{code:java}
[2023-08-28T08:24:40,558][WARN
][%iscaat_n_2%tableManager-io-3][RaftGroupServiceImpl] Recoverable error during
the request type=GetLeaderRequestImpl occurred (will be retried on the randomly
selected node):
java.util.concurrent.CompletionException: java.net.ConnectException: Peer
iscaat_n_1 is unavailable
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
~[?:?]
at
java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
~[?:?]
at
java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
~[?:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:522)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:489)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:224)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:180)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.start(TopologyAwareRaftGroupService.java:182)
~[ignite-replicator-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupServiceFactory.startRaftGroupService(TopologyAwareRaftGroupServiceFactory.java:71)
~[ignite-replicator-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.raft.Loza.startRaftGroupService(Loza.java:321)
~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$createTablePartitionsLocally$11(TableManager.java:912)
~[ignite-table-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:905)
~[ignite-core-9.0.127-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$createTablePartitionsLocally$12(TableManager.java:909)
~[ignite-table-9.0.127-SNAPSHOT.jar:?]
at
java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
~[?:?]
at
java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
Caused by: java.net.ConnectException: Peer iscaat_n_1 is unavailable
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20313) Flaky ItSqlClientAsynchronousApiTest.errors
[
https://issues.apache.org/jira/browse/IGNITE-20313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-20313:
---
Labels: ignite-3 (was: )
> Flaky ItSqlClientAsynchronousApiTest.errors
> ---
>
> Key: IGNITE-20313
> URL: https://issues.apache.org/jira/browse/IGNITE-20313
> Project: Ignite
> Issue Type: Improvement
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> ItSqlClientAsynchronousApiTest.error fails with a low fail rate. On local
> environment it reproducable also.
> Symptoms looks as one of test node has left cluster.
> {code:java}
> [2023-08-28T08:24:40,558][WARN
> ][%iscaat_n_2%tableManager-io-3][RaftGroupServiceImpl] Recoverable error
> during the request type=GetLeaderRequestImpl occurred (will be retried on the
> randomly selected node):
> java.util.concurrent.CompletionException: java.net.ConnectException:
> Peer iscaat_n_1 is unavailable
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1099)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> ~[?:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:522)
> ~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:489)
> ~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:224)
> ~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:180)
> ~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService.start(TopologyAwareRaftGroupService.java:182)
> ~[ignite-replicator-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupServiceFactory.startRaftGroupService(TopologyAwareRaftGroupServiceFactory.java:71)
> ~[ignite-replicator-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.raft.Loza.startRaftGroupService(Loza.java:321)
> ~[ignite-raft-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTablePartitionsLocally$11(TableManager.java:912)
> ~[ignite-table-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:905)
> ~[ignite-core-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTablePartitionsLocally$12(TableManager.java:909)
> ~[ignite-table-9.0.127-SNAPSHOT.jar:?]
> at
> java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> at java.lang.Thread.run(Thread.java:834) ~[?:?]
> Caused by: java.net.ConnectException: Peer iscaat_n_1 is unavailable
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20266) .NET: Thin 3.0: TestDataStreamerMetrics is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-20266:
Ignite Flags: (was: Docs Required,Release Notes Required)
> .NET: Thin 3.0: TestDataStreamerMetrics is flaky
>
>
> Key: IGNITE-20266
> URL: https://issues.apache.org/jira/browse/IGNITE-20266
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://ci.ignite.apache.org/test/5503643215833216881?currentProjectId=ApacheIgnite3xGradle_Test=true=
> {code}
> streamer-batches-active
> Expected: 1
> But was: 2
>at
> Apache.Ignite.Tests.MetricsTests.g__GetTuples|13_0()+MoveNext()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 248
>at System.Linq.AsyncEnumerable.AsyncEnumerableAdapter`1.MoveNextCore() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/Operators/ToAsyncEnumerable.cs:line
> 68
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncIterator.cs:line 70
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncIterator.cs:line 75
>at
> Apache.Ignite.Internal.Table.DataStreamer.StreamDataAsync[T](IAsyncEnumerable`1
> data, Func`4 sender, IRecordSerializerHandler`1 writer, Func`1
> schemaProvider, Func`1 partitionAssignmentProvider, DataStreamerOptions
> options, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/DataStreamer.cs:line
> 92
>at
> Apache.Ignite.Internal.Table.DataStreamer.StreamDataAsync[T](IAsyncEnumerable`1
> data, Func`4 sender, IRecordSerializerHandler`1 writer, Func`1
> schemaProvider, Func`1 partitionAssignmentProvider, DataStreamerOptions
> options, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/DataStreamer.cs:line
> 92
>at
> Apache.Ignite.Internal.Table.RecordView`1.StreamDataAsync(IAsyncEnumerable`1
> data, DataStreamerOptions options, CancellationToken cancellationToken) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/RecordView.cs:line
> 300
>at Apache.Ignite.Tests.MetricsTests.TestDataStreamerMetrics() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 224
>at
> NUnit.Framework.Internal.TaskAwaitAdapter.GenericAdapter`1.BlockUntilCompleted()
>at
> NUnit.Framework.Internal.MessagePumpStrategy.NoMessagePumpStrategy.WaitForCompletion(AwaitAdapter
> awaiter)
>at NUnit.Framework.Internal.AsyncToSyncAdapter.Await(Func`1 invoke)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(TestExecutionContext
> context)
>at
> NUnit.Framework.Internal.Commands.BeforeAndAfterTestCommand.<>c__DisplayClass1_0.b__0()
>at
> NUnit.Framework.Internal.Commands.DelegatingTestCommand.RunTestMethodInThreadAbortSafeZone(TestExecutionContext
> context, Action action)
> 1)at
> Apache.Ignite.Tests.MetricsTests.g__GetTuples|13_0()+MoveNext()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/MetricsTests.cs:line
> 248
>at System.Linq.AsyncEnumerable.AsyncEnumerableAdapter`1.MoveNextCore() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/Operators/ToAsyncEnumerable.cs:line
> 68
>at
> System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
> stateMachine)
>at System.Linq.AsyncEnumerable.AsyncEnumerableAdapter`1.MoveNextCore()
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync() in
> /_/Ix.NET/Source/System.Linq.Async/System/Linq/AsyncIterator.cs:line 70
>at
> System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
> stateMachine)
>at System.Linq.AsyncIteratorBase`1.MoveNextAsync()
>at
> System.Runtime.CompilerServices.ConfiguredCancelableAsyncEnumerable`1.Enumerator.MoveNextAsync()
>at
> Apache.Ignite.Internal.Table.DataStreamer.StreamDataAsync[T](IAsyncEnumerable`1
> data, Func`4 sender, IRecordSerializerHandler`1 writer, Func`1
> schemaProvider, Func`1 partitionAssignmentProvider, DataStreamerOptions
> options, CancellationToken cancellationToken)
>at
>
[jira] [Updated] (IGNITE-20312) Change default logger settings
[
https://issues.apache.org/jira/browse/IGNITE-20312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-20312:
---
Ignite Flags: Docs Required (was: Docs Required,Release Notes Required)
> Change default logger settings
> --
>
> Key: IGNITE-20312
> URL: https://issues.apache.org/jira/browse/IGNITE-20312
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> What we have now is:
>
> {noformat}
> java.util.logging.FileHandler.limit = 10485760
> java.util.logging.FileHandler.count = 10
> {noformat}
>
> That's not enough for good testing, especially considering that each restart
> will start with next file, instead of appending to the previous file. I
> suggest greatly increasing the number of files in rotation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20312) Change default logger settings
[
https://issues.apache.org/jira/browse/IGNITE-20312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-20312:
---
Ignite Flags: Release Notes Required (was: Docs Required)
> Change default logger settings
> --
>
> Key: IGNITE-20312
> URL: https://issues.apache.org/jira/browse/IGNITE-20312
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> What we have now is:
>
> {noformat}
> java.util.logging.FileHandler.limit = 10485760
> java.util.logging.FileHandler.count = 10
> {noformat}
>
> That's not enough for good testing, especially considering that each restart
> will start with next file, instead of appending to the previous file. I
> suggest greatly increasing the number of files in rotation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20312) Change default logger settings
Ivan Bessonov created IGNITE-20312:
--
Summary: Change default logger settings
Key: IGNITE-20312
URL: https://issues.apache.org/jira/browse/IGNITE-20312
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov
What we have now is:
{noformat}
java.util.logging.FileHandler.limit = 10485760
java.util.logging.FileHandler.count = 10
{noformat}
That's not enough for good testing, especially considering that each restart
will start with next file, instead of appending to the previous file. I suggest
greatly increasing the number of files in rotation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20299) Creating a cache with an unknown data region name causes total unrecoverable failure of the grid
[ https://issues.apache.org/jira/browse/IGNITE-20299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760318#comment-17760318 ] Pavel Tupitsyn commented on IGNITE-20299: - [~rpwilson] sorry, did not refresh the page. I will check the reproducer, thank you. > Creating a cache with an unknown data region name causes total unrecoverable > failure of the grid > > > Key: IGNITE-20299 > URL: https://issues.apache.org/jira/browse/IGNITE-20299 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.15 > Environment: Observed in: > C# client and grid running on Linux in a container > C# client and grid running on Windows > >Reporter: Raymond Wilson >Priority: Major > > Using the Ignite C# client. > > Given a running grid, having a client (and perhaps server) node in the grid > attempt to create a cache using a DataRegionName that does not exist in the > grid causes immediate failure in the client node with the following log > output. > > 2023-08-27 17:08:48,520 [44] INF [ImmutableClientServer] Completed > partition exchange [localNode=15122bd7-bf81-44e6-a548-e70dbd9334c0, > exchange=GridDhtPartitionsExchangeFuture [topVer=AffinityTopologyVersion > [topVer=15, minorTopVer=0], evt=NODE_FAILED, evtNode=TcpDiscoveryNode > [id=9d5ed68d-38bb-447d-aed5-189f52660716, > consistentId=9d5ed68d-38bb-447d-aed5-189f52660716, addrs=ArrayList > [127.0.0.1], sockAddrs=null, discPort=0, order=8, intOrder=8, > lastExchangeTime=1693112858024, loc=false, ver=2.15.0#20230425-sha1:f98f7f35, > isClient=true], rebalanced=false, done=true, newCrdFut=null], > topVer=AffinityTopologyVersion [topVer=15, minorTopVer=0]] > 2023-08-27 17:08:48,520 [44] INF [ImmutableClientServer] Exchange timings > [startVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], > resVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], stage="Waiting in > exchange queue" (14850 ms), stage="Exchange parameters initialization" (2 > ms), stage="Determine exchange type" (3 ms), stage="Exchange done" (4 ms), > stage="Total time" (14859 ms)] > 2023-08-27 17:08:48,522 [44] INF [ImmutableClientServer] Exchange longest > local stages [startVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], > resVer=AffinityTopologyVersion [topVer=15, minorTopVer=0]] > 2023-08-27 17:08:48,524 [44] INF [ImmutableClientServer] Finished exchange > init [topVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], crd=false] > 2023-08-27 17:08:48,525 [44] INF [ImmutableClientServer] > AffinityTopologyVersion [topVer=15, minorTopVer=0], evt=NODE_FAILED, > evtNode=9d5ed68d-38bb-447d-aed5-189f52660716, client=true] > Unhandled exception: Apache.Ignite.Core.Cache.CacheException: class > org.apache.ignite.IgniteCheckedException: Failed to complete exchange process. > ---> Apache.Ignite.Core.Common.IgniteException: Failed to complete exchange > process. > ---> Apache.Ignite.Core.Common.JavaException: javax.cache.CacheException: > class org.apache.ignite.IgniteCheckedException: Failed to complete exchange > process. > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1272) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache0(IgniteKernal.java:2278) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2242) > at > org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutObject(PlatformProcessorImpl.java:643) > at > org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to complete > exchange process. > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createExchangeException(GridDhtPartitionsExchangeFuture.java:3709) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendExchangeFailureMessage(GridDhtPartitionsExchangeFuture.java:3737) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3832) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3813) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1796) > at >
[jira] [Updated] (IGNITE-20311) Sql. Fix behaviour of ROUND function.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Summary: Sql. Fix behaviour of ROUND function. (was: Sql. Handle return
type of ROUND. )
> Sql. Fix behaviour of ROUND function.
> -
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2, RowSchema
> has NativeType (precision=2, scale=1).
> # Because of that this query returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
was:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2, RowSchema
> has NativeType (precision=2, scale=1).
> # Because of that this query returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
was:
The return type for `ROUND(N)`/`ROUND(N, s)` is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryRow` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
was:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
was:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Fix Version/s: 3.0.0-beta2
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(x)/ROUND(x, n) is equal to the type of x, which
> causes issues when reading data from a `BinaryRow` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Labels: ignite-3 (was: )
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> The return type for ROUND(x)/ROUND(x, n) is equal to the type of x, which
> causes issues when reading data from a `BinaryRow` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for `ROUND(N)`/`ROUND(N, s)` is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
was:
The return type for `ROUND(x)`/`ROUND(x, n)` is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for `ROUND(N)`/`ROUND(N, s)` is equal to the type of x, which
> causes issues when reading data from a `BinaryRow` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for `ROUND(x)`/`ROUND(x, n)` is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
was:
The return type for ROUND(x)/ROUND(x, n) is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for `ROUND(x)`/`ROUND(x, n)` is equal to the type of x, which
> causes issues when reading data from a `BinaryRow` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20311) Sql. Handle return type of ROUND.
Maksim Zhuravkov created IGNITE-20311:
-
Summary: Sql. Handle return type of ROUND.
Key: IGNITE-20311
URL: https://issues.apache.org/jira/browse/IGNITE-20311
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
The return type for ROUND(x)/ROUND(x, n) is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20310) Meta storage invokes are not completed when DZM start is completed
Sergey Uttsel created IGNITE-20310: -- Summary: Meta storage invokes are not completed when DZM start is completed Key: IGNITE-20310 URL: https://issues.apache.org/jira/browse/IGNITE-20310 Project: Ignite Issue Type: Bug Reporter: Sergey Uttsel There are meta storage invokes in DistributionZoneManager start. Currently it does the meta storage invoke in case when a filter update was handled before DZM stop, but it didn't update data nodes. The future of this invoke is ignored. So after the start method is completed actually not all start actions are completed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20299) Creating a cache with an unknown data region name causes total unrecoverable failure of the grid
[ https://issues.apache.org/jira/browse/IGNITE-20299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760296#comment-17760296 ] Pavel Tupitsyn commented on IGNITE-20299: - > none of the information in the exception indicates that the "Requested > DataRegion is not configured" This information is in the inner JavaException. You can also do *ex.ToString()*. This is not great, of course - would be better if the root cause was in the top level exception message. > Creating a cache with an unknown data region name causes total unrecoverable > failure of the grid > > > Key: IGNITE-20299 > URL: https://issues.apache.org/jira/browse/IGNITE-20299 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.15 > Environment: Observed in: > C# client and grid running on Linux in a container > C# client and grid running on Windows > >Reporter: Raymond Wilson >Priority: Major > > Using the Ignite C# client. > > Given a running grid, having a client (and perhaps server) node in the grid > attempt to create a cache using a DataRegionName that does not exist in the > grid causes immediate failure in the client node with the following log > output. > > 2023-08-27 17:08:48,520 [44] INF [ImmutableClientServer] Completed > partition exchange [localNode=15122bd7-bf81-44e6-a548-e70dbd9334c0, > exchange=GridDhtPartitionsExchangeFuture [topVer=AffinityTopologyVersion > [topVer=15, minorTopVer=0], evt=NODE_FAILED, evtNode=TcpDiscoveryNode > [id=9d5ed68d-38bb-447d-aed5-189f52660716, > consistentId=9d5ed68d-38bb-447d-aed5-189f52660716, addrs=ArrayList > [127.0.0.1], sockAddrs=null, discPort=0, order=8, intOrder=8, > lastExchangeTime=1693112858024, loc=false, ver=2.15.0#20230425-sha1:f98f7f35, > isClient=true], rebalanced=false, done=true, newCrdFut=null], > topVer=AffinityTopologyVersion [topVer=15, minorTopVer=0]] > 2023-08-27 17:08:48,520 [44] INF [ImmutableClientServer] Exchange timings > [startVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], > resVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], stage="Waiting in > exchange queue" (14850 ms), stage="Exchange parameters initialization" (2 > ms), stage="Determine exchange type" (3 ms), stage="Exchange done" (4 ms), > stage="Total time" (14859 ms)] > 2023-08-27 17:08:48,522 [44] INF [ImmutableClientServer] Exchange longest > local stages [startVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], > resVer=AffinityTopologyVersion [topVer=15, minorTopVer=0]] > 2023-08-27 17:08:48,524 [44] INF [ImmutableClientServer] Finished exchange > init [topVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], crd=false] > 2023-08-27 17:08:48,525 [44] INF [ImmutableClientServer] > AffinityTopologyVersion [topVer=15, minorTopVer=0], evt=NODE_FAILED, > evtNode=9d5ed68d-38bb-447d-aed5-189f52660716, client=true] > Unhandled exception: Apache.Ignite.Core.Cache.CacheException: class > org.apache.ignite.IgniteCheckedException: Failed to complete exchange process. > ---> Apache.Ignite.Core.Common.IgniteException: Failed to complete exchange > process. > ---> Apache.Ignite.Core.Common.JavaException: javax.cache.CacheException: > class org.apache.ignite.IgniteCheckedException: Failed to complete exchange > process. > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1272) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache0(IgniteKernal.java:2278) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2242) > at > org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutObject(PlatformProcessorImpl.java:643) > at > org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to complete > exchange process. > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createExchangeException(GridDhtPartitionsExchangeFuture.java:3709) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendExchangeFailureMessage(GridDhtPartitionsExchangeFuture.java:3737) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3832) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3813) > at >
[jira] [Commented] (IGNITE-20299) Creating a cache with an unknown data region name causes total unrecoverable failure of the grid
[ https://issues.apache.org/jira/browse/IGNITE-20299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760294#comment-17760294 ] Pavel Tupitsyn commented on IGNITE-20299: - With PersistenceEnabled=true it still does not reproduce for me. > Creating a cache with an unknown data region name causes total unrecoverable > failure of the grid > > > Key: IGNITE-20299 > URL: https://issues.apache.org/jira/browse/IGNITE-20299 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.15 > Environment: Observed in: > C# client and grid running on Linux in a container > C# client and grid running on Windows > >Reporter: Raymond Wilson >Priority: Major > > Using the Ignite C# client. > > Given a running grid, having a client (and perhaps server) node in the grid > attempt to create a cache using a DataRegionName that does not exist in the > grid causes immediate failure in the client node with the following log > output. > > 2023-08-27 17:08:48,520 [44] INF [ImmutableClientServer] Completed > partition exchange [localNode=15122bd7-bf81-44e6-a548-e70dbd9334c0, > exchange=GridDhtPartitionsExchangeFuture [topVer=AffinityTopologyVersion > [topVer=15, minorTopVer=0], evt=NODE_FAILED, evtNode=TcpDiscoveryNode > [id=9d5ed68d-38bb-447d-aed5-189f52660716, > consistentId=9d5ed68d-38bb-447d-aed5-189f52660716, addrs=ArrayList > [127.0.0.1], sockAddrs=null, discPort=0, order=8, intOrder=8, > lastExchangeTime=1693112858024, loc=false, ver=2.15.0#20230425-sha1:f98f7f35, > isClient=true], rebalanced=false, done=true, newCrdFut=null], > topVer=AffinityTopologyVersion [topVer=15, minorTopVer=0]] > 2023-08-27 17:08:48,520 [44] INF [ImmutableClientServer] Exchange timings > [startVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], > resVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], stage="Waiting in > exchange queue" (14850 ms), stage="Exchange parameters initialization" (2 > ms), stage="Determine exchange type" (3 ms), stage="Exchange done" (4 ms), > stage="Total time" (14859 ms)] > 2023-08-27 17:08:48,522 [44] INF [ImmutableClientServer] Exchange longest > local stages [startVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], > resVer=AffinityTopologyVersion [topVer=15, minorTopVer=0]] > 2023-08-27 17:08:48,524 [44] INF [ImmutableClientServer] Finished exchange > init [topVer=AffinityTopologyVersion [topVer=15, minorTopVer=0], crd=false] > 2023-08-27 17:08:48,525 [44] INF [ImmutableClientServer] > AffinityTopologyVersion [topVer=15, minorTopVer=0], evt=NODE_FAILED, > evtNode=9d5ed68d-38bb-447d-aed5-189f52660716, client=true] > Unhandled exception: Apache.Ignite.Core.Cache.CacheException: class > org.apache.ignite.IgniteCheckedException: Failed to complete exchange process. > ---> Apache.Ignite.Core.Common.IgniteException: Failed to complete exchange > process. > ---> Apache.Ignite.Core.Common.JavaException: javax.cache.CacheException: > class org.apache.ignite.IgniteCheckedException: Failed to complete exchange > process. > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1272) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache0(IgniteKernal.java:2278) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2242) > at > org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutObject(PlatformProcessorImpl.java:643) > at > org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to complete > exchange process. > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createExchangeException(GridDhtPartitionsExchangeFuture.java:3709) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendExchangeFailureMessage(GridDhtPartitionsExchangeFuture.java:3737) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3832) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3813) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1796) > at >
[jira] [Commented] (IGNITE-20033) Implement local txnStateMap
[
https://issues.apache.org/jira/browse/IGNITE-20033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760276#comment-17760276
]
Vladislav Pyatkov commented on IGNITE-20033:
LGTM
Merged 07a02ae89e627ed218267f041c0ab3de6f0cee30
> Implement local txnStateMap
> ---
>
> Key: IGNITE-20033
> URL: https://issues.apache.org/jira/browse/IGNITE-20033
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3, transaction3_recovery, transactions
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> h3. Motivation
> For some purposes, in addition to persistent txnState in commit partition,
> it's required to have a txn meta on every transactional actor: txn
> coordinator, commit partition (both primary and all backups) and all enlisted
> partitions (both primary and backups).
> [IEP-91|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Txnstatemap]
> names such meta holder as txn state map and specifies following structure
> {code:java}
> txId -> (txState, txCoordAddr, commitTs){code}
> Such map is originally designed to provide required information for
> writeIntentResolution: txState for local write intent resolution and
> txCoordAddr for coordinator-path one, but that's not all it's good for, so it
> definitely worth to implement it as soon as possible in order to unblock
> further activities.
> -Why we have this ticket in "commit partition recovery" pack?
> -Because in order to implement proper handling of a commit partition primary
> replica change (which is definitely a part of the "commit partition pack")
> it's required to:
> # Support local txnStateMap, in order to
> # Implement writeIntentResolution coordinator path, in order to
> # Calculate commitTimestamp on txn coordtinator istead of commit partition,
> where we do it now.
> h3. Definition of Done
> Every transactional actor
> * Txn Coordinator.
> * CommitPartition, both primary and all backups.
> * All enlisted partitions, both primary and all backups.
> should have volatile txnStateMap with following suggested structure 'txId ->
> (txState, txCoordAddr, commitTs)'.
>
> Given map should be adjusted before any further transactional actions within
> node in a following way:
> * Transaction coordinator.
> ** On transaction start with state PENDING.
> ** On transaction commit, right after commitTimestamp calucalttion with
> state FINISHING.
> ** On txFinishReplicaResponse with either COMMITED or ABORTED.
> * Commit partition.
> ** On replica touch with state PENDING.
> ** After succefull finishTxCommand application on majoirty with either
> COMMITED or ABORTED.
> ** Seems that we don't need FINISHING state here, so let's skip it for now.
> * Enlisted replica.
> ** Primary
> *** On replica touch with state PENDING.
> *** On TxCleanupCommand COMMITED or ABORTED.
> ** Backup
> *** On touch replication PENDING.
> *** On TxCleanupCommand COMMITED or ABORTED, same as for primary.
> h3. Implementation Notes
> There are some open questions:
> * Where to put this txnStateMap? TxManager?
> * Properly handle same map multiple updates, based on the fact that Commit
> Partition is also an enlisted partition. To be honest I believe it's not that
> important. We may extent possible state change application rules to assume
> that null > PENDING, PENDING > FINISHING, PENDING > COMMITED, PENDING >
> ABORTED, PENDING > PENDING, COMMITED > COMMITED and ABORTED > ABORTED are all
> possible.
> * Eliminate excessive map updates in case of "one-phase commit".
> https://issues.apache.org/jira/browse/IGNITE-15927
> * Substitute org.apache.ignite.internal.tx.impl.TxManagerImpl#states with
> txnStateMap.
> * Definte "touch".
> * It's reasonbale to use non-consistent node id as txCoordAddr because
> currently there's no sense in sending TxStateReq to the node that lost it's
> local txnStateMap because of node restart.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-10418) Implement lightweight profiling of messages processing
[
https://issues.apache.org/jira/browse/IGNITE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-10418:
-
Assignee: (was: Denis Chudov)
> Implement lightweight profiling of messages processing
> --
>
> Key: IGNITE-10418
> URL: https://issues.apache.org/jira/browse/IGNITE-10418
> Project: Ignite
> Issue Type: New Feature
>Reporter: Alexey Scherbakov
>Priority: Major
> Labels: IEP-35
>
> There is a lack of capabilities to identify bottlenecks without extensive
> profiling on server and client side (JFR recording, sampling profilers,
> regular thread dumps, etc), which is not always possible. Even having
> profiling data not always helpful for determining several types of
> bottlenecks, for example, if there is a contention on single key/partition.
> Lightweight message profiling will allow to track each message execution, to
> collect a statistics of execution in executors for each grid node and for all
> nodes, collect histograms distributed by waiting/execution time for each type
> of message.
> We need to implement:
> # histogram metrics for message execution time, queue waiting time, queue
> size at the moments of queue add and execution start, with distribution by
> message type;
> # Dumping of messages if it’s execution/waiting time exceeds some threshold
> timeout, i.e.
> {code:java}
> Slow message: *enqueueTs*=2018-11-27 15:10:22.241, *waitTime*=0.048,
> *procTime*=305.186, *messageId*=3a3064a9, *queueSzBefore*=0,
> *headMessageId*=null, *queueSzAfter*=0, *message*=GridNearTxFinishRequest
> [miniId=1, mvccSnapshot=null, super=GridDistributedTxFinishRequest
> [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
> futId=199a3155761-f379f312-ad4b-4181-acc5-0aacb3391f07, threadId=296,
> commitVer=null, invalidate=false, commit=true, baseVer=null, txSize=0,
> sys=false, plc=2, subjId=dda703a0-69ee-47cf-9b9a-bf3dc9309feb,
> taskNameHash=0, flags=32, syncMode=FULL_SYNC, txState=IgniteTxStateImpl
> [activeCacheIds=[644280847], recovery=false, mvccEnabled=false, txMap=HashSet
> [IgniteTxEntry [key=KeyCacheObjectImpl [part=8, val=8, hasValBytes=true],
> cacheId=644280847, txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=8, val=8,
> hasValBytes=true], cacheId=644280847], val=[op=READ, val=null],
> prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null],
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null,
> explicitVer=null, dhtVer=null, filters=CacheEntryPredicate[] [],
> filtersPassed=false, filtersSet=false, entry=GridCacheMapEntry
> [key=KeyCacheObjectImpl [part=8, val=8, hasValBytes=true], val=null,
> ver=GridCacheVersion [topVer=0, order=0, nodeOrder=0], hash=8,
> extras=GridCacheObsoleteEntryExtras [obsoleteVer=GridCacheVersion
> [topVer=2147483647, order=0, nodeOrder=0]], flags=2]GridDistributedCacheEntry
> [super=]GridDhtCacheEntry [rdrs=ReaderId[] [], part=8, super=], prepared=0,
> locked=false, nodeId=null, locMapped=false, expiryPlc=null,
> transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null,
> xidVer=GridCacheVersion{code}
> # JMX tools and command line interface to get this metrics and print
> statistics view.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20260) RaftGroupServiceImpl#readIndex() is broken
[
https://issues.apache.org/jira/browse/IGNITE-20260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760271#comment-17760271
]
Mirza Aliev commented on IGNITE-20260:
--
LGTM, thanks for the contribution!
> RaftGroupServiceImpl#readIndex() is broken
> --
>
> Key: IGNITE-20260
> URL: https://issues.apache.org/jira/browse/IGNITE-20260
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Denis Chudov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> According to {{NodeImpl#readLeader()}}, peerId must be specified together
> with serverId on a {{ReadIndexRequest}}, but
> {{RaftGroupServiceImpl#readIndex()}} omits serverId, so on the server side
> request processing always fails.
> Probably, local node name should be sent as serverId.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
