[jira] [Resolved] (IGNITE-21697) ConnectionManager ignores exceptional return value of ExecutorService.submit
[
https://issues.apache.org/jira/browse/IGNITE-21697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko resolved IGNITE-21697.
--
Resolution: Duplicate
https://issues.apache.org/jira/browse/IGNITE-21696
> ConnectionManager ignores exceptional return value of ExecutorService.submit
>
>
> Key: IGNITE-21697
> URL: https://issues.apache.org/jira/browse/IGNITE-21697
> Project: Ignite
> Issue Type: Task
>Reporter: Viacheslav Blinov
>Priority: Minor
> Labels: ignite-3, spotbugs
>
> Issue detected by SpotBugs. Specifically the warning reported is:
> {noformat}
> M B RV_RETURN_VALUE_IGNORED_BAD_PRACTICE RV: Exceptional return value of
> java.util.concurrent.ExecutorService.submit(Callable) ignored in
> org.apache.ignite.internal.network.netty.ConnectionManager.handleNodeLeft(String)
> At ConnectionManager.java:[line 603]
> {noformat}
> If you don't check the result, you won't notice if the method invocation
> signals unexpected behavior by returning an atypical return value.
> Investigate whenever this is a false-positive and we should suppress it, or
> we should make a proper fix.
> At the result of investigation corresponding TODO should be removed in
> spotbugs-excludes.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21770) Improve logging for the ‘Probably disk is too busy, please check your device’ event (when reading from disk)
Oleg Valuyskiy created IGNITE-21770:
---
Summary: Improve logging for the ‘Probably disk is too busy,
please check your device’ event (when reading from disk)
Key: IGNITE-21770
URL: https://issues.apache.org/jira/browse/IGNITE-21770
Project: Ignite
Issue Type: Improvement
Reporter: Oleg Valuyskiy
Assignee: Oleg Valuyskiy
Make logging messages more specific and include more information that could be
necessary for analysis.
Stack trace example:
{code:java}
2024-03-15 04:23:25.395 [ERROR][ForkJoinPool.commonPool-worker-41][] Critical
system error detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.StorageException: Failed to read page
[file=/opt/ignite/ssd/data/cell_6_node_4/cacheGroup-part/part-15909.bin,
pageId=349803611487542]]]
org.apache.ignite.internal.processors.cache.persistence.StorageException:
Failed to read page
[file=/opt/ignite/ssd/data/cell_6_node_4/cacheGroup-part/part-15909.bin,
pageId=349803611487542]
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:547)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:487)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageReadWriteManagerImpl.read(PageReadWriteManagerImpl.java:69)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:522)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:930)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:741)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:730)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.doInitFromLink(CacheDataRowAdapter.java:304)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:165)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:136)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.tree.DataRow.(DataRow.java:55)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.tree.CacheDataRowStore.dataRow(CacheDataRowStore.java:129)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.getRow(CacheDataTree.java:424)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.getRow(CacheDataTree.java:63)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.fillFromBuffer0(BPlusTree.java:6168)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.fillFromBuffer(BPlusTree.java:5917)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5971)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:6221)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.onHasNext(IgniteCacheOffheapManagerImpl.java:913)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:56)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.verify.IdleVerifyUtility.calculatePartitionHash(IdleVerifyUtility.java:269)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.lambda$calculatePartitionHashAsync$3(VerifyBackupPartitionsTaskV2.java:478)
~[ignite-core-14.1.2.jar:14.1.2]
at
java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1448)
~[?:?]
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.j
[jira] [Assigned] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
[
https://issues.apache.org/jira/browse/IGNITE-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-12625:
---
Assignee: (was: Mikhail Petrov)
> Thin client: Marshaling/unmarshaling of objects performed twice
> ---
>
> Key: IGNITE-12625
> URL: https://issues.apache.org/jira/browse/IGNITE-12625
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Reporter: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For each thin client cache operation marshaling/unmarshaling of objects
> performed twice. For example, cache "put" operation marshal object on the
> client-side, then unmarshal object (with keep binaries) on the server-side
> and marshal it again before putting it to the cache. It causes some
> undesirable effects. For example, references to the same binary object in a
> collection ( {{new ArrayList(Arrays.asList(person, person))}} ) deserialized
> as different objects.
> Reproducer:
> {code:java}
> try (IgniteClient client = startClient()) {
> ClientCache cache =
> client.getOrCreateCache(DEFAULT_CACHE_NAME);
> Person person = new Person(0, "name");
> cache.put(0, new Object[] {person, person} );
> Object[] res = cache.get(0);
> assertTrue(res[0] == res[1]);
> }{code}
> Also, we need to unwrap binaries recursively since all objects inside
> collections, arrays and maps become binary objects after
> marshaling/unmarshalling (see IGNITE-12468)
> Also, we don't know do we really need to deserialize binary objects. If
> object was originally binary there is no evidence of this after
> marshaling/unmarshaling on server-side. This leads to problems when a binary
> object was created for unknown class.
> Reproducer:
> {code:java}
> cache.put(0, client.binary().builder("TestType").setField("test",
> "val").build());
> cache.get(0);{code}
> Will throw exception:
> {noformat}
> class org.apache.ignite.binary.BinaryInvalidTypeException: TestType
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319)
> at
> org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:547){noformat}
> To avoid double marshaling we could pass byte array from request content to
> cache directly (for example using {{CacheObject}}), but we don't have object
> size in thin client protocol, so in any case, we need to traverse the
> objects. Also, we don't have the ability to get {{CacheObject}} from the
> cache now, so such an approach will only work in one way, for "put"
> operations, but not for "get" operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
[
https://issues.apache.org/jira/browse/IGNITE-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-12625:
---
Assignee: Mikhail Petrov
> Thin client: Marshaling/unmarshaling of objects performed twice
> ---
>
> Key: IGNITE-12625
> URL: https://issues.apache.org/jira/browse/IGNITE-12625
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Reporter: Aleksey Plekhanov
>Assignee: Mikhail Petrov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For each thin client cache operation marshaling/unmarshaling of objects
> performed twice. For example, cache "put" operation marshal object on the
> client-side, then unmarshal object (with keep binaries) on the server-side
> and marshal it again before putting it to the cache. It causes some
> undesirable effects. For example, references to the same binary object in a
> collection ( {{new ArrayList(Arrays.asList(person, person))}} ) deserialized
> as different objects.
> Reproducer:
> {code:java}
> try (IgniteClient client = startClient()) {
> ClientCache cache =
> client.getOrCreateCache(DEFAULT_CACHE_NAME);
> Person person = new Person(0, "name");
> cache.put(0, new Object[] {person, person} );
> Object[] res = cache.get(0);
> assertTrue(res[0] == res[1]);
> }{code}
> Also, we need to unwrap binaries recursively since all objects inside
> collections, arrays and maps become binary objects after
> marshaling/unmarshalling (see IGNITE-12468)
> Also, we don't know do we really need to deserialize binary objects. If
> object was originally binary there is no evidence of this after
> marshaling/unmarshaling on server-side. This leads to problems when a binary
> object was created for unknown class.
> Reproducer:
> {code:java}
> cache.put(0, client.binary().builder("TestType").setField("test",
> "val").build());
> cache.get(0);{code}
> Will throw exception:
> {noformat}
> class org.apache.ignite.binary.BinaryInvalidTypeException: TestType
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319)
> at
> org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:547){noformat}
> To avoid double marshaling we could pass byte array from request content to
> cache directly (for example using {{CacheObject}}), but we don't have object
> size in thin client protocol, so in any case, we need to traverse the
> objects. Also, we don't have the ability to get {{CacheObject}} from the
> cache now, so such an approach will only work in one way, for "put"
> operations, but not for "get" operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
[
https://issues.apache.org/jira/browse/IGNITE-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-12625:
---
Assignee: (was: Mikhail Petrov)
> Thin client: Marshaling/unmarshaling of objects performed twice
> ---
>
> Key: IGNITE-12625
> URL: https://issues.apache.org/jira/browse/IGNITE-12625
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Reporter: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For each thin client cache operation marshaling/unmarshaling of objects
> performed twice. For example, cache "put" operation marshal object on the
> client-side, then unmarshal object (with keep binaries) on the server-side
> and marshal it again before putting it to the cache. It causes some
> undesirable effects. For example, references to the same binary object in a
> collection ( {{new ArrayList(Arrays.asList(person, person))}} ) deserialized
> as different objects.
> Reproducer:
> {code:java}
> try (IgniteClient client = startClient()) {
> ClientCache cache =
> client.getOrCreateCache(DEFAULT_CACHE_NAME);
> Person person = new Person(0, "name");
> cache.put(0, new Object[] {person, person} );
> Object[] res = cache.get(0);
> assertTrue(res[0] == res[1]);
> }{code}
> Also, we need to unwrap binaries recursively since all objects inside
> collections, arrays and maps become binary objects after
> marshaling/unmarshalling (see IGNITE-12468)
> Also, we don't know do we really need to deserialize binary objects. If
> object was originally binary there is no evidence of this after
> marshaling/unmarshaling on server-side. This leads to problems when a binary
> object was created for unknown class.
> Reproducer:
> {code:java}
> cache.put(0, client.binary().builder("TestType").setField("test",
> "val").build());
> cache.get(0);{code}
> Will throw exception:
> {noformat}
> class org.apache.ignite.binary.BinaryInvalidTypeException: TestType
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319)
> at
> org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:547){noformat}
> To avoid double marshaling we could pass byte array from request content to
> cache directly (for example using {{CacheObject}}), but we don't have object
> size in thin client protocol, so in any case, we need to traverse the
> objects. Also, we don't have the ability to get {{CacheObject}} from the
> cache now, so such an approach will only work in one way, for "put"
> operations, but not for "get" operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21636) Code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21636: -- Fix Version/s: 2.17 > Code cleanup > > > Key: IGNITE-21636 > URL: https://issues.apache.org/jira/browse/IGNITE-21636 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Trivial > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > Removing of unused 'mvccEnabled', codestyle fixex, +abbreviations, finals and > etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21636) Code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21636: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Code cleanup > > > Key: IGNITE-21636 > URL: https://issues.apache.org/jira/browse/IGNITE-21636 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Trivial > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > Removing of unused 'mvccEnabled', codestyle fixex, +abbreviations, finals and > etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21636) Code cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-21636: - Assignee: Vladimir Steshin > Code cleanup > > > Key: IGNITE-21636 > URL: https://issues.apache.org/jira/browse/IGNITE-21636 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > > Removing of unused 'mvccEnabled', codestyle fixex, +abbreviations, finals and > etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
