[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-21586) Removed orphaned rawRetval flag.
[ https://issues.apache.org/jira/browse/IGNITE-21586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21586: Fix Version/s: 2.17 > Removed orphaned rawRetval flag. > > > Key: IGNITE-21586 > URL: https://issues.apache.org/jira/browse/IGNITE-21586 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21586) Removed orphaned rawRetval flag.
[ https://issues.apache.org/jira/browse/IGNITE-21586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-21586. - Resolution: Fixed > Removed orphaned rawRetval flag. > > > Key: IGNITE-21586 > URL: https://issues.apache.org/jira/browse/IGNITE-21586 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21586) Removed orphaned rawRetval flag.
[ https://issues.apache.org/jira/browse/IGNITE-21586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820348#comment-17820348 ] Mikhail Petrov commented on IGNITE-21586: - [~NSAmelchev] Thank you for the review. > Removed orphaned rawRetval flag. > > > Key: IGNITE-21586 > URL: https://issues.apache.org/jira/browse/IGNITE-21586 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819545#comment-17819545
]
Mikhail Petrov commented on IGNITE-21266:
-
[~alex_pl] Thank you for the review.
> [Java Thin Client] Partition Awareness does not work after cluster restart
> --
>
> Key: IGNITE-21266
> URL: https://issues.apache.org/jira/browse/IGNITE-21266
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> ClientCacheAffinityContext is susceptible to the similar problem that
> described in
> [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. As a
> result cache affinity data required for PA work is not updated after cluster
> restart.
> Reproducer:
> {code:java}
> /** */
> public class PartitionAwarenessClusterRestartTest extends
> ThinClientAbstractPartitionAwarenessTest {
> /** */
> @Test
> public void testGroupNodesAfterClusterRestart() throws Exception {
> prepareCluster();
> initClient(getClientConfiguration(0), 0, 1);
> checkPartitionAwareness();
> stopAllGrids();
> prepareCluster();
> checkPartitionAwareness();
> }
> /** */
> private void checkPartitionAwareness() throws Exception {
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> cache.put(0, 0);
> opsQueue.clear();
> for (int i = 1; i < 1000; i++) {
> cache.put(i, i);
>
> assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
> ClientOperation.CACHE_PUT);
> }
> }
> /** */
> private void prepareCluster() throws Exception {
> startGrids(3);
> grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21266:
Fix Version/s: 2.17
> [Java Thin Client] Partition Awareness does not work after cluster restart
> --
>
> Key: IGNITE-21266
> URL: https://issues.apache.org/jira/browse/IGNITE-21266
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> ClientCacheAffinityContext is susceptible to the similar problem that
> described in
> [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. As a
> result cache affinity data required for PA work is not updated after cluster
> restart.
> Reproducer:
> {code:java}
> /** */
> public class PartitionAwarenessClusterRestartTest extends
> ThinClientAbstractPartitionAwarenessTest {
> /** */
> @Test
> public void testGroupNodesAfterClusterRestart() throws Exception {
> prepareCluster();
> initClient(getClientConfiguration(0), 0, 1);
> checkPartitionAwareness();
> stopAllGrids();
> prepareCluster();
> checkPartitionAwareness();
> }
> /** */
> private void checkPartitionAwareness() throws Exception {
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> cache.put(0, 0);
> opsQueue.clear();
> for (int i = 1; i < 1000; i++) {
> cache.put(i, i);
>
> assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
> ClientOperation.CACHE_PUT);
> }
> }
> /** */
> private void prepareCluster() throws Exception {
> startGrids(3);
> grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21586) Removed orphaned rawRetval flag.
[ https://issues.apache.org/jira/browse/IGNITE-21586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21586: --- Assignee: Mikhail Petrov > Removed orphaned rawRetval flag. > > > Key: IGNITE-21586 > URL: https://issues.apache.org/jira/browse/IGNITE-21586 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21586) Removed orphaned rawRetval flag.
[ https://issues.apache.org/jira/browse/IGNITE-21586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21586: Ignite Flags: (was: Docs Required,Release Notes Required) > Removed orphaned rawRetval flag. > > > Key: IGNITE-21586 > URL: https://issues.apache.org/jira/browse/IGNITE-21586 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21586) Removed orphaned rawRetval flag.
Mikhail Petrov created IGNITE-21586: --- Summary: Removed orphaned rawRetval flag. Key: IGNITE-21586 URL: https://issues.apache.org/jira/browse/IGNITE-21586 Project: Ignite Issue Type: Task Reporter: Mikhail Petrov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
[
https://issues.apache.org/jira/browse/IGNITE-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812785#comment-17812785
]
Mikhail Petrov commented on IGNITE-21399:
-
[~NSAmelchev] Thank you for the review.
> IgniteCache#getAll invoked on transactional cache can lead to a node failure
> with OutOfMemoryError
> --
>
> Key: IGNITE-21399
> URL: https://issues.apache.org/jira/browse/IGNITE-21399
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Exception:
> {code:java}
> 2024-01-18 09:28:07.374 [ERROR][sys-#4371][] 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=java.lang.OutOfMemoryError]]
> java.lang.OutOfMemoryError: null
> at
> java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329)
> ~[?:?]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at
> org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
>
[jira] [Updated] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
[
https://issues.apache.org/jira/browse/IGNITE-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21399:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> IgniteCache#getAll invoked on transactional cache can lead to a node failure
> with OutOfMemoryError
> --
>
> Key: IGNITE-21399
> URL: https://issues.apache.org/jira/browse/IGNITE-21399
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Exception:
> {code:java}
> 2024-01-18 09:28:07.374 [ERROR][sys-#4371][] 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=java.lang.OutOfMemoryError]]
> java.lang.OutOfMemoryError: null
> at
> java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329)
> ~[?:?]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at
> org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
>
[jira] [Updated] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
[
https://issues.apache.org/jira/browse/IGNITE-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21399:
Labels: ise (was: )
> IgniteCache#getAll invoked on transactional cache can lead to a node failure
> with OutOfMemoryError
> --
>
> Key: IGNITE-21399
> URL: https://issues.apache.org/jira/browse/IGNITE-21399
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Exception:
> {code:java}
> 2024-01-18 09:28:07.374 [ERROR][sys-#4371][] 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=java.lang.OutOfMemoryError]]
> java.lang.OutOfMemoryError: null
> at
> java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329)
> ~[?:?]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at
> org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
>
[jira] [Updated] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
[
https://issues.apache.org/jira/browse/IGNITE-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21399:
Fix Version/s: 2.17
> IgniteCache#getAll invoked on transactional cache can lead to a node failure
> with OutOfMemoryError
> --
>
> Key: IGNITE-21399
> URL: https://issues.apache.org/jira/browse/IGNITE-21399
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Exception:
> {code:java}
> 2024-01-18 09:28:07.374 [ERROR][sys-#4371][] 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=java.lang.OutOfMemoryError]]
> java.lang.OutOfMemoryError: null
> at
> java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329)
> ~[?:?]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at
> org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
>
[jira] [Assigned] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
[
https://issues.apache.org/jira/browse/IGNITE-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-21399:
---
Assignee: Mikhail Petrov
> IgniteCache#getAll invoked on transactional cache can lead to a node failure
> with OutOfMemoryError
> --
>
> Key: IGNITE-21399
> URL: https://issues.apache.org/jira/browse/IGNITE-21399
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Exception:
> {code:java}
> 2024-01-18 09:28:07.374 [ERROR][sys-#4371][] 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=java.lang.OutOfMemoryError]]
> java.lang.OutOfMemoryError: null
> at
> java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173)
> ~[?:?]
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329)
> ~[?:?]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at
> org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at java.lang.String.valueOf(String.java:2951) ~[?:?]
> at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> ~[ignite-core-14.1.2.jar:14.1.2]
> at
>
[jira] [Created] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
Mikhail Petrov created IGNITE-21399:
---
Summary: IgniteCache#getAll invoked on transactional cache can
lead to a node failure with OutOfMemoryError
Key: IGNITE-21399
URL: https://issues.apache.org/jira/browse/IGNITE-21399
Project: Ignite
Issue Type: Bug
Reporter: Mikhail Petrov
Exception:
{code:java}
2024-01-18 09:28:07.374 [ERROR][sys-#4371][] 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=java.lang.OutOfMemoryError]]
java.lang.OutOfMemoryError: null
at
java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214)
~[?:?]
at
java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206)
~[?:?]
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173)
~[?:?]
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?]
at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?]
at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
at
java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329)
~[?:?]
at java.lang.String.valueOf(String.java:2951) ~[?:?]
at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646)
~[ignite-core-14.1.2.jar:14.1.2]
at java.lang.String.valueOf(String.java:2951) ~[?:?]
at
org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664)
~[ignite-core-14.1.2.jar:14.1.2]
at java.lang.String.valueOf(String.java:2951) ~[?:?]
at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?]
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
~[ignite-core-14.1.2.jar:14.1.2]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
~[ignite-core-14.1.2.jar:14.1.2]
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:829) ~[?:?]
2024-01-18 09:28:07.411 [WARN
][sys-#4371][org.apache.ignite.internal.processors.cache.CacheDiagnosticManager]
Page locks dump:
{code}
Java version: OpenJDK
[jira] [Updated] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21308: Description: After GridLocalAtomicCache removal in [IGNITE-15759|https://issues.apache.org/jira/browse/IGNITE-15759] some code in GridCacheAdapter #getAllAsync methods is orphaned and should be removed as well. > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > After GridLocalAtomicCache removal in > [IGNITE-15759|https://issues.apache.org/jira/browse/IGNITE-15759] some code > in GridCacheAdapter #getAllAsync methods is orphaned and should be removed as > well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810224#comment-17810224 ] Mikhail Petrov commented on IGNITE-21308: - [~av] Thank you for the review. > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21266:
Description:
ClientCacheAffinityContext is susceptible to the similar problem that described
in [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. As a
result cache affinity data required for PA work is not updated after cluster
restart.
Reproducer:
{code:java}
/** */
public class PartitionAwarenessClusterRestartTest extends
ThinClientAbstractPartitionAwarenessTest {
/** */
@Test
public void testGroupNodesAfterClusterRestart() throws Exception {
prepareCluster();
initClient(getClientConfiguration(0), 0, 1);
checkPartitionAwareness();
stopAllGrids();
prepareCluster();
checkPartitionAwareness();
}
/** */
private void checkPartitionAwareness() throws Exception {
ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
cache.put(0, 0);
opsQueue.clear();
for (int i = 1; i < 1000; i++) {
cache.put(i, i);
assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
ClientOperation.CACHE_PUT);
}
}
/** */
private void prepareCluster() throws Exception {
startGrids(3);
grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
}
}
{code}
was:
ClientCacheAffinityContext is susceptible to the similar problem ерфе described
in [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001].
Reproducer:
{code:java}
/** */
public class PartitionAwarenessClusterRestartTest extends
ThinClientAbstractPartitionAwarenessTest {
/** */
@Test
public void testGroupNodesAfterClusterRestart() throws Exception {
prepareCluster();
initClient(getClientConfiguration(0), 0, 1);
checkPartitionAwareness();
stopAllGrids();
prepareCluster();
checkPartitionAwareness();
}
/** */
private void checkPartitionAwareness() throws Exception {
ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
cache.put(0, 0);
opsQueue.clear();
for (int i = 1; i < 1000; i++) {
cache.put(i, i);
assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
ClientOperation.CACHE_PUT);
}
}
/** */
private void prepareCluster() throws Exception {
startGrids(3);
grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
}
}
{code}
> [Java Thin Client] Partition Awareness does not work after cluster restart
> --
>
> Key: IGNITE-21266
> URL: https://issues.apache.org/jira/browse/IGNITE-21266
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ClientCacheAffinityContext is susceptible to the similar problem that
> described in
> [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. As a
> result cache affinity data required for PA work is not updated after cluster
> restart.
> Reproducer:
> {code:java}
> /** */
> public class PartitionAwarenessClusterRestartTest extends
> ThinClientAbstractPartitionAwarenessTest {
> /** */
> @Test
> public void testGroupNodesAfterClusterRestart() throws Exception {
> prepareCluster();
> initClient(getClientConfiguration(0), 0, 1);
> checkPartitionAwareness();
> stopAllGrids();
> prepareCluster();
> checkPartitionAwareness();
> }
> /** */
> private void checkPartitionAwareness() throws Exception {
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> cache.put(0, 0);
> opsQueue.clear();
> for (int i = 1; i < 1000; i++) {
> cache.put(i, i);
>
> assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
> ClientOperation.CACHE_PUT);
> }
> }
> /** */
> private void prepareCluster() throws Exception {
> startGrids(3);
> grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-21266:
---
Assignee: Mikhail Petrov
> [Java Thin Client] Partition Awareness does not work after cluster restart
> --
>
> Key: IGNITE-21266
> URL: https://issues.apache.org/jira/browse/IGNITE-21266
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ClientCacheAffinityContext is susceptible to the similar problem ерфе
> described in
> [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001].
> Reproducer:
> {code:java}
> /** */
> public class PartitionAwarenessClusterRestartTest extends
> ThinClientAbstractPartitionAwarenessTest {
> /** */
> @Test
> public void testGroupNodesAfterClusterRestart() throws Exception {
> prepareCluster();
> initClient(getClientConfiguration(0), 0, 1);
> checkPartitionAwareness();
> stopAllGrids();
> prepareCluster();
> checkPartitionAwareness();
> }
> /** */
> private void checkPartitionAwareness() throws Exception {
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> cache.put(0, 0);
> opsQueue.clear();
> for (int i = 1; i < 1000; i++) {
> cache.put(i, i);
>
> assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
> ClientOperation.CACHE_PUT);
> }
> }
> /** */
> private void prepareCluster() throws Exception {
> startGrids(3);
> grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21266:
Description:
ClientCacheAffinityContext is susceptible to the similar problem ерфе described
in [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001].
Reproducer:
{code:java}
/** */
public class PartitionAwarenessClusterRestartTest extends
ThinClientAbstractPartitionAwarenessTest {
/** */
@Test
public void testGroupNodesAfterClusterRestart() throws Exception {
prepareCluster();
initClient(getClientConfiguration(0), 0, 1);
checkPartitionAwareness();
stopAllGrids();
prepareCluster();
checkPartitionAwareness();
}
/** */
private void checkPartitionAwareness() throws Exception {
ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
cache.put(0, 0);
opsQueue.clear();
for (int i = 1; i < 1000; i++) {
cache.put(i, i);
assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
ClientOperation.CACHE_PUT);
}
}
/** */
private void prepareCluster() throws Exception {
startGrids(3);
grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
}
}
{code}
was:
Reproducer:
{code:java}
/** */
public class PartitionAwarenessClusterRestartTest extends
ThinClientAbstractPartitionAwarenessTest {
/** */
@Test
public void testGroupNodesAfterClusterRestart() throws Exception {
prepareCluster();
initClient(getClientConfiguration(0), 0, 1);
checkPartitionAwareness();
stopAllGrids();
prepareCluster();
checkPartitionAwareness();
}
/** */
private void checkPartitionAwareness() throws Exception {
ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
cache.put(0, 0);
opsQueue.clear();
for (int i = 1; i < 1000; i++) {
cache.put(i, i);
assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
ClientOperation.CACHE_PUT);
}
}
/** */
private void prepareCluster() throws Exception {
startGrids(3);
grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
}
}
{code}
> [Java Thin Client] Partition Awareness does not work after cluster restart
> --
>
> Key: IGNITE-21266
> URL: https://issues.apache.org/jira/browse/IGNITE-21266
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ClientCacheAffinityContext is susceptible to the similar problem ерфе
> described in
> [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001].
> Reproducer:
> {code:java}
> /** */
> public class PartitionAwarenessClusterRestartTest extends
> ThinClientAbstractPartitionAwarenessTest {
> /** */
> @Test
> public void testGroupNodesAfterClusterRestart() throws Exception {
> prepareCluster();
> initClient(getClientConfiguration(0), 0, 1);
> checkPartitionAwareness();
> stopAllGrids();
> prepareCluster();
> checkPartitionAwareness();
> }
> /** */
> private void checkPartitionAwareness() throws Exception {
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> cache.put(0, 0);
> opsQueue.clear();
> for (int i = 1; i < 1000; i++) {
> cache.put(i, i);
>
> assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
> ClientOperation.CACHE_PUT);
> }
> }
> /** */
> private void prepareCluster() throws Exception {
> startGrids(3);
> grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21308: Ignite Flags: (was: Docs Required,Release Notes Required) > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21308: Labels: ise (was: ) > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21308: Fix Version/s: 2.17 > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21308: --- Assignee: Mikhail Petrov > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-15478) Add access to the IgniteMBeanManager via KernalContext
[ https://issues.apache.org/jira/browse/IGNITE-15478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-15478: --- Assignee: (was: Mikhail Petrov) > Add access to the IgniteMBeanManager via KernalContext > -- > > Key: IGNITE-15478 > URL: https://issues.apache.org/jira/browse/IGNITE-15478 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > It is needed to add an access to the IgniteMBeanManager via KernalContext. It > helps to access the IgniteMBeanManager in the same way as for other Ignite > components, and allows Ignite components to register needed MBeans from their > own implementations. > It's also proposed to refactor MBeans registration to be performed explicitly > via IgniteMBeanManager. As an example we can eliminate > GridQueryIndexing#registerMxBeans method and registers beans directly. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21266:
Labels: ise (was: )
> [Java Thin Client] Partition Awareness does not work after cluster restart
> --
>
> Key: IGNITE-21266
> URL: https://issues.apache.org/jira/browse/IGNITE-21266
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
> Labels: ise
>
> Reproducer:
> {code:java}
> /** */
> public class PartitionAwarenessClusterRestartTest extends
> ThinClientAbstractPartitionAwarenessTest {
> /** */
> @Test
> public void testGroupNodesAfterClusterRestart() throws Exception {
> prepareCluster();
> initClient(getClientConfiguration(0), 0, 1);
> checkPartitionAwareness();
> stopAllGrids();
> prepareCluster();
> checkPartitionAwareness();
> }
> /** */
> private void checkPartitionAwareness() throws Exception {
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> cache.put(0, 0);
> opsQueue.clear();
> for (int i = 1; i < 1000; i++) {
> cache.put(i, i);
>
> assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
> ClientOperation.CACHE_PUT);
> }
> }
> /** */
> private void prepareCluster() throws Exception {
> startGrids(3);
> grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808644#comment-17808644 ] Mikhail Petrov commented on IGNITE-21240: - [~av] Thank you for the review. > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in > https://issues.apache.org/jira/browse/IGNITE-19807 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21308) Remove orphaned GridCacheAdapter code
Mikhail Petrov created IGNITE-21308: --- Summary: Remove orphaned GridCacheAdapter code Key: IGNITE-21308 URL: https://issues.apache.org/jira/browse/IGNITE-21308 Project: Ignite Issue Type: Task Reporter: Mikhail Petrov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808166#comment-17808166
]
Mikhail Petrov commented on IGNITE-21001:
-
[~alex_pl] Thank you for the review.
> Thin client: cluster group returns cached nodes after cluster restart
> -
>
> Key: IGNITE-21001
> URL: https://issues.apache.org/jira/browse/IGNITE-21001
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When a client requests information about cluster nodes, it sends the version
> of the topology for which it received a list of cluster nodes the previous
> time.
> And if the client's version of the topology matches the one currently on the
> server, then the server does not send the list of cluster nodes back to the
> client. Like the client knows everything itself.
> But after full cluster restart, the topology version may not change. But the
> nodes will be different.
> The reproducer:
> {noformat}
> @Test
> public void testClusterGroup() throws Exception {
> IgniteEx srv = startGrid(0);
> try (IgniteClient client = startClient(0)) {
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> stopAllGrids();
> srv = startGrid(0);
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21266:
Summary: [Java Thin Client] Partition Awareness does not work after cluster
restart (was: [Java Thin Client] PA do not work after cluster restart)
> [Java Thin Client] Partition Awareness does not work after cluster restart
> --
>
> Key: IGNITE-21266
> URL: https://issues.apache.org/jira/browse/IGNITE-21266
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
>
> Reproducer:
> {code:java}
> /** */
> public class PartitionAwarenessClusterRestartTest extends
> ThinClientAbstractPartitionAwarenessTest {
> /** */
> @Test
> public void testGroupNodesAfterClusterRestart() throws Exception {
> prepareCluster();
> initClient(getClientConfiguration(0), 0, 1);
> checkPartitionAwareness();
> stopAllGrids();
> prepareCluster();
> checkPartitionAwareness();
> }
> /** */
> private void checkPartitionAwareness() throws Exception {
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> cache.put(0, 0);
> opsQueue.clear();
> for (int i = 1; i < 1000; i++) {
> cache.put(i, i);
>
> assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
> ClientOperation.CACHE_PUT);
> }
> }
> /** */
> private void prepareCluster() throws Exception {
> startGrids(3);
> grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21266:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> [Java Thin Client] Partition Awareness does not work after cluster restart
> --
>
> Key: IGNITE-21266
> URL: https://issues.apache.org/jira/browse/IGNITE-21266
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
>
> Reproducer:
> {code:java}
> /** */
> public class PartitionAwarenessClusterRestartTest extends
> ThinClientAbstractPartitionAwarenessTest {
> /** */
> @Test
> public void testGroupNodesAfterClusterRestart() throws Exception {
> prepareCluster();
> initClient(getClientConfiguration(0), 0, 1);
> checkPartitionAwareness();
> stopAllGrids();
> prepareCluster();
> checkPartitionAwareness();
> }
> /** */
> private void checkPartitionAwareness() throws Exception {
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> cache.put(0, 0);
> opsQueue.clear();
> for (int i = 1; i < 1000; i++) {
> cache.put(i, i);
>
> assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
> ClientOperation.CACHE_PUT);
> }
> }
> /** */
> private void prepareCluster() throws Exception {
> startGrids(3);
> grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21266) [Java Thin Client] PA do not work after cluster restart
Mikhail Petrov created IGNITE-21266:
---
Summary: [Java Thin Client] PA do not work after cluster restart
Key: IGNITE-21266
URL: https://issues.apache.org/jira/browse/IGNITE-21266
Project: Ignite
Issue Type: Bug
Reporter: Mikhail Petrov
Reproducer:
{code:java}
/** */
public class PartitionAwarenessClusterRestartTest extends
ThinClientAbstractPartitionAwarenessTest {
/** */
@Test
public void testGroupNodesAfterClusterRestart() throws Exception {
prepareCluster();
initClient(getClientConfiguration(0), 0, 1);
checkPartitionAwareness();
stopAllGrids();
prepareCluster();
checkPartitionAwareness();
}
/** */
private void checkPartitionAwareness() throws Exception {
ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
cache.put(0, 0);
opsQueue.clear();
for (int i = 1; i < 1000; i++) {
cache.put(i, i);
assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()),
ClientOperation.CACHE_PUT);
}
}
/** */
private void prepareCluster() throws Exception {
startGrids(3);
grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME));
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21240: Fix Version/s: 2.17 > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in > https://issues.apache.org/jira/browse/IGNITE-19807 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21240: Issue Type: Task (was: Bug) > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in > https://issues.apache.org/jira/browse/IGNITE-19807 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19807) Deprecate legacy authorization approach through Security Context.
[ https://issues.apache.org/jira/browse/IGNITE-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-19807: Description: We currently have several ways to check if a user has permission to perform an operation. 1. IgniteSecurity#authorize methods that delegate permission check to security plugin. 2. SecurityContext#*OperationAllowed methods. They currently are used just for one check. This approach assumes that granted permissions set is returned during user authentication and remains immutable. Let's deprecate the second authorization approach and support both authorization approaches for the JOIN_AS_SERVER permission (the only permission that is checked through SecurityContext authorization API). was: We currently have several ways to check if a user has permission to perform an operation. 1. IgniteSecurity#authorize methods that delegate permission check to security plugin. 2. SecurityContext#*OperationAllowed methods. They currently are used just for one check. This approach assumes that granted permissions set is returned during user authentication and remains immutable. Let's deprecate the second authorization approach and migrate completely to the first. > Deprecate legacy authorization approach through Security Context. > - > > Key: IGNITE-19807 > URL: https://issues.apache.org/jira/browse/IGNITE-19807 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > We currently have several ways to check if a user has permission to perform > an operation. > 1. IgniteSecurity#authorize methods that delegate permission check to > security plugin. > 2. SecurityContext#*OperationAllowed methods. They currently are used just > for one check. This approach assumes that granted permissions set is > returned during user authentication and remains immutable. > Let's deprecate the second authorization approach and support both > authorization approaches for the JOIN_AS_SERVER permission (the only > permission that is checked through SecurityContext authorization API). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21240: Priority: Minor (was: Major) > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in > https://issues.apache.org/jira/browse/IGNITE-19807 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21240: Description: We need to finally remove what was described ad deprecated in https://issues.apache.org/jira/browse/IGNITE-19807 (was: We need to finally remove what was described ad deprecated in ) > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in > https://issues.apache.org/jira/browse/IGNITE-19807 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21240: Description: We need to finally remove what was described ad deprecated in > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21240: --- Assignee: Mikhail Petrov > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21240) Remove deprecated authorization method from Security Context
Mikhail Petrov created IGNITE-21240: --- Summary: Remove deprecated authorization method from Security Context Key: IGNITE-21240 URL: https://issues.apache.org/jira/browse/IGNITE-21240 Project: Ignite Issue Type: Bug Reporter: Mikhail Petrov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21001:
Description:
When a client requests information about cluster nodes, it sends the version of
the topology for which it received a list of cluster nodes the previous time.
And if the client's version of the topology matches the one currently on the
server, then the server does not send the list of cluster nodes back to the
client. Like the client knows everything itself.
But after full cluster restart, the topology version may not change. But the
nodes will be different.
The reproducer:
{noformat}
@Test
public void testClusterGroup() throws Exception {
IgniteEx srv = startGrid(0);
try (IgniteClient client = startClient(0)) {
assertTrue(client.cluster().nodes().contains(srv.localNode()));
stopAllGrids();
srv = startGrid(0);
assertTrue(client.cluster().nodes().contains(srv.localNode()));
}
}
{noformat}
was:
When a client requests information about cluster nodes, it sends the version of
the topology for which it received a list of cluster nodes the previous time.
And if the client's version of the topology matches the one currently on the
server, then the server does not send the list of cluster nodes back to the
client. Like the client knows everything itself.
But after cluster restart, the topology version may not change. But the nodes
will be different.
The reproducer:
{noformat}
@Test
public void testClusterGroup() throws Exception {
IgniteEx srv = startGrid(0);
try (IgniteClient client = startClient(0)) {
assertTrue(client.cluster().nodes().contains(srv.localNode()));
stopAllGrids();
srv = startGrid(0);
assertTrue(client.cluster().nodes().contains(srv.localNode()));
}
}
{noformat}
> Thin client: cluster group returns cached nodes after cluster restart
> -
>
> Key: IGNITE-21001
> URL: https://issues.apache.org/jira/browse/IGNITE-21001
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a client requests information about cluster nodes, it sends the version
> of the topology for which it received a list of cluster nodes the previous
> time.
> And if the client's version of the topology matches the one currently on the
> server, then the server does not send the list of cluster nodes back to the
> client. Like the client knows everything itself.
> But after full cluster restart, the topology version may not change. But the
> nodes will be different.
> The reproducer:
> {noformat}
> @Test
> public void testClusterGroup() throws Exception {
> IgniteEx srv = startGrid(0);
> try (IgniteClient client = startClient(0)) {
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> stopAllGrids();
> srv = startGrid(0);
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21001:
Description:
When a client requests information about cluster nodes, it sends the version of
the topology for which it received a list of cluster nodes the previous time.
And if the client's version of the topology matches the one currently on the
server, then the server does not send the list of cluster nodes back to the
client. Like the client knows everything itself.
But after cluster restart, the topology version may not change. But the nodes
will be different.
The reproducer:
{noformat}
@Test
public void testClusterGroup() throws Exception {
IgniteEx srv = startGrid(0);
try (IgniteClient client = startClient(0)) {
assertTrue(client.cluster().nodes().contains(srv.localNode()));
stopAllGrids();
srv = startGrid(0);
assertTrue(client.cluster().nodes().contains(srv.localNode()));
}
}
{noformat}
was:
When a client requests information about cluster nodes, it sends the version of
the topology for which it received a list of cluster nodes the previous time.
And if the client's version of the topology matches the one currently on the
server, then the server does not send the list of cluster nodes back to the
client. Like the client knows everything itself.
But after restarting the cluster, the topology version may not change. But the
nodes will be different.
The reproducer:
{noformat}
@Test
public void testClusterGroup() throws Exception {
IgniteEx srv = startGrid(0);
try (IgniteClient client = startClient(0)) {
assertTrue(client.cluster().nodes().contains(srv.localNode()));
stopAllGrids();
srv = startGrid(0);
assertTrue(client.cluster().nodes().contains(srv.localNode()));
}
}
{noformat}
> Thin client: cluster group returns cached nodes after cluster restart
> -
>
> Key: IGNITE-21001
> URL: https://issues.apache.org/jira/browse/IGNITE-21001
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a client requests information about cluster nodes, it sends the version
> of the topology for which it received a list of cluster nodes the previous
> time.
> And if the client's version of the topology matches the one currently on the
> server, then the server does not send the list of cluster nodes back to the
> client. Like the client knows everything itself.
> But after cluster restart, the topology version may not change. But the nodes
> will be different.
> The reproducer:
> {noformat}
> @Test
> public void testClusterGroup() throws Exception {
> IgniteEx srv = startGrid(0);
> try (IgniteClient client = startClient(0)) {
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> stopAllGrids();
> srv = startGrid(0);
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21001:
Description:
When a client requests information about cluster nodes, it sends the version of
the topology for which it received a list of cluster nodes the previous time.
And if the client's version of the topology matches the one currently on the
server, then the server does not send the list of cluster nodes back to the
client. Like the client knows everything itself.
But after restarting the cluster, the topology version may not change. But the
nodes will be different.
The reproducer:
{noformat}
@Test
public void testClusterGroup() throws Exception {
IgniteEx srv = startGrid(0);
try (IgniteClient client = startClient(0)) {
assertTrue(client.cluster().nodes().contains(srv.localNode()));
stopAllGrids();
srv = startGrid(0);
assertTrue(client.cluster().nodes().contains(srv.localNode()));
}
}
{noformat}
was:
When a client requests information about cluster nodes, it sends the version of
the topology for which it received a list of cluster nodes the previous time.
And if the client's version of the topology matches the one currently on the
server, then the server does not send the list of cluster nodes back to the
client. Like the client knows everything himself.
But after restarting the cluster, the topology version may not change. But the
nodes will be different.
The reproducer:
{noformat}
@Test
public void testClusterGroup() throws Exception {
IgniteEx srv = startGrid(0);
try (IgniteClient client = startClient(0)) {
assertTrue(client.cluster().nodes().contains(srv.localNode()));
stopAllGrids();
srv = startGrid(0);
assertTrue(client.cluster().nodes().contains(srv.localNode()));
}
}
{noformat}
> Thin client: cluster group returns cached nodes after cluster restart
> -
>
> Key: IGNITE-21001
> URL: https://issues.apache.org/jira/browse/IGNITE-21001
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a client requests information about cluster nodes, it sends the version
> of the topology for which it received a list of cluster nodes the previous
> time.
> And if the client's version of the topology matches the one currently on the
> server, then the server does not send the list of cluster nodes back to the
> client. Like the client knows everything itself.
> But after restarting the cluster, the topology version may not change. But
> the nodes will be different.
> The reproducer:
> {noformat}
> @Test
> public void testClusterGroup() throws Exception {
> IgniteEx srv = startGrid(0);
> try (IgniteClient client = startClient(0)) {
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> stopAllGrids();
> srv = startGrid(0);
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21001:
Description:
When a client requests information about cluster nodes, it sends the version of
the topology for which it received a list of cluster nodes the previous time.
And if the client's version of the topology matches the one currently on the
server, then the server does not send the list of cluster nodes back to the
client. Like the client knows everything himself.
But after restarting the cluster, the topology version may not change. But the
nodes will be different.
The reproducer:
{noformat}
@Test
public void testClusterGroup() throws Exception {
IgniteEx srv = startGrid(0);
try (IgniteClient client = startClient(0)) {
assertTrue(client.cluster().nodes().contains(srv.localNode()));
stopAllGrids();
srv = startGrid(0);
assertTrue(client.cluster().nodes().contains(srv.localNode()));
}
}
{noformat}
was:
The reproducer:
{noformat}
@Test
public void testClusterGroup() throws Exception {
IgniteEx srv = startGrid(0);
try (IgniteClient client = startClient(0)) {
assertTrue(client.cluster().nodes().contains(srv.localNode()));
stopAllGrids();
srv = startGrid(0);
assertTrue(client.cluster().nodes().contains(srv.localNode()));
}
}
{noformat}
> Thin client: cluster group returns cached nodes after cluster restart
> -
>
> Key: IGNITE-21001
> URL: https://issues.apache.org/jira/browse/IGNITE-21001
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a client requests information about cluster nodes, it sends the version
> of the topology for which it received a list of cluster nodes the previous
> time.
> And if the client's version of the topology matches the one currently on the
> server, then the server does not send the list of cluster nodes back to the
> client. Like the client knows everything himself.
> But after restarting the cluster, the topology version may not change. But
> the nodes will be different.
> The reproducer:
> {noformat}
> @Test
> public void testClusterGroup() throws Exception {
> IgniteEx srv = startGrid(0);
> try (IgniteClient client = startClient(0)) {
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> stopAllGrids();
> srv = startGrid(0);
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-21001:
---
Assignee: Mikhail Petrov (was: Nikita Amelchev)
> Thin client: cluster group returns cached nodes after cluster restart
> -
>
> Key: IGNITE-21001
> URL: https://issues.apache.org/jira/browse/IGNITE-21001
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
>
> The reproducer:
> {noformat}
> @Test
> public void testClusterGroup() throws Exception {
> IgniteEx srv = startGrid(0);
> try (IgniteClient client = startClient(0)) {
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> stopAllGrids();
> srv = startGrid(0);
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21001:
Fix Version/s: 2.17
> Thin client: cluster group returns cached nodes after cluster restart
> -
>
> Key: IGNITE-21001
> URL: https://issues.apache.org/jira/browse/IGNITE-21001
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
> Fix For: 2.17
>
>
> The reproducer:
> {noformat}
> @Test
> public void testClusterGroup() throws Exception {
> IgniteEx srv = startGrid(0);
> try (IgniteClient client = startClient(0)) {
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> stopAllGrids();
> srv = startGrid(0);
> assertTrue(client.cluster().nodes().contains(srv.localNode()));
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Description: Check https://github.com/apache/ignite/issues/10907 for more detailed description of the problem. It is proposed to not consider classes that are not in org.apache.ignite package as system. was:Check https://github.com/apache/ignite/issues/10907 for more detailed description of the problem. > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.15, 2.16 >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. > It is proposed to not consider classes that are not in org.apache.ignite > package as system. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Fix Version/s: 2.17 > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Affects Version/s: 2.16 2.15 > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.15, 2.16 >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Component/s: security > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Ignite Flags: (was: Docs Required,Release Notes Required) > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-21216. - Resolution: Fixed > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805070#comment-17805070 ] Mikhail Petrov commented on IGNITE-21216: - [~NSAmelchev] Thank you for the review. > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21216: --- Assignee: Mikhail Petrov > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
Mikhail Petrov created IGNITE-21216: --- Summary: Do not consider tasks that are not in org.apache.ignite package as system Key: IGNITE-21216 URL: https://issues.apache.org/jira/browse/IGNITE-21216 Project: Ignite Issue Type: Bug Reporter: Mikhail Petrov Check https://github.com/apache/ignite/issues/10907 for more detailed description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20922) Java Thin: direct service invocation with ClientClusterGroup and Service Awareness
[
https://issues.apache.org/jira/browse/IGNITE-20922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798531#comment-17798531
]
Mikhail Petrov commented on IGNITE-20922:
-
[~vladsz83] Thank you for the contribution.
> Java Thin: direct service invocation with ClientClusterGroup and Service
> Awareness
> --
>
> Key: IGNITE-20922
> URL: https://issues.apache.org/jira/browse/IGNITE-20922
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.16
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Once we implemented Service Awareness for Java Thin Client, we might improve
> the service invocation with `IgniteClient.services(ClientClusterGroup grp)`
> Consider:
> 1) There is a cluster with some nodes A, B, C, D, F
> 1) A service is deployed on nodes A,B,C
> 2) Service Awareness is enabled.
> 3) User limits the service instance nodes set with
> `IgniteClient.services('node A', 'node B')` skipping node C.
> 4) The thin client requests the service randomly on node C because it has the
> service instance too.
> 5) Node C redirects the invocation to node A or to node B as user required.
> We should prevent the redirection call at #5 and call service only on A or B.
> And this would help user to choose nodes for loading purposes.
> It looks simple to intersect passed `ClientClusterGroup` and known set of
> service instance nodes before the service calling. I.e. the client can
> exclude node C from the options where to send the invocation request.
> If user chosses `services('node A', 'node B', 'node F')`, where F has no
> service instance, we do not invoke F.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21100) [Python Thin Client] Key class binary metadata registration is skipped
[ https://issues.apache.org/jira/browse/IGNITE-21100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21100: Description: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see a) pyignite.datatypes.complex.BinaryObject.hashcode b) pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) was: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see a) pyignite.datatypes.complex.BinaryObject.hashcode b) pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the serialization result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) > [Python Thin Client] Key class binary metadata registration is skipped > -- > > Key: IGNITE-21100 > URL: https://issues.apache.org/jira/browse/IGNITE-21100 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > > Python thin client does not register binary metadata for user classes that > are used as a key for cache operations. > It seems that it happens because > 1. When we calculate hash code of a key object, we serialize it. The result > is cached in `_buffer` attribute of the object. (see > a) pyignite.datatypes.complex.BinaryObject.hashcode > b) pyignite/binary.py#write_footer:203 ). > The hash code of a key object is used to determine which node this key > belongs to (PA). > 2. But when we are about to send key object to the server side - we skip > cache object serialization as the result is already saved in the buffer > mentioned above AND skip its binary type registration. > (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21100) [Python Thin Client] Key class binary metadata registration is skipped
[ https://issues.apache.org/jira/browse/IGNITE-21100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21100: Description: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see a) pyignite.datatypes.complex.BinaryObject.hashcode b) pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the serialization result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) was: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see a) pyignite.datatypes.complex.BinaryObject.hashcode b) pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the serialization result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) > [Python Thin Client] Key class binary metadata registration is skipped > -- > > Key: IGNITE-21100 > URL: https://issues.apache.org/jira/browse/IGNITE-21100 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > > Python thin client does not register binary metadata for user classes that > are used as a key for cache operations. > It seems that it happens because > 1. When we calculate hash code of a key object, we serialize it. The result > is cached in `_buffer` attribute of the object. (see > a) pyignite.datatypes.complex.BinaryObject.hashcode > b) pyignite/binary.py#write_footer:203 ). > The hash code of a key object is used to determine which node this key > belongs to (PA). > 2. But when we are about to send key object to the server side - we skip > cache object serialization as the serialization result is already saved in > the buffer mentioned above AND skip its binary type registration. > (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21100) [Python Thin Client] Key class binary metadata registration is skipped
[ https://issues.apache.org/jira/browse/IGNITE-21100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21100: Description: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see a) pyignite.datatypes.complex.BinaryObject.hashcode b) pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the serialization result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) was: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see pyignite.datatypes.complex.BinaryObject.hashcode, pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) > [Python Thin Client] Key class binary metadata registration is skipped > -- > > Key: IGNITE-21100 > URL: https://issues.apache.org/jira/browse/IGNITE-21100 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > > Python thin client does not register binary metadata for user classes that > are used as a key for cache operations. > It seems that it happens because > 1. When we calculate hash code of a key object, we serialize it. The result > is cached in `_buffer` attribute of the object. (see > a) pyignite.datatypes.complex.BinaryObject.hashcode > b) pyignite/binary.py#write_footer:203 > ). > The hash code of a key object is used to determine which node this key > belongs to (PA). > 2. But when we are about to send key object to the server side - we skip > cache object serialization as the serialization result is already saved in > the buffer mentioned above AND skip its binary type registration. > (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21100) [Python Thin Client] Key class binary metadata registration is skipped
[ https://issues.apache.org/jira/browse/IGNITE-21100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21100: Summary: [Python Thin Client] Key class binary metadata registration is skipped (was: [Python Thin Client] Key class binary metadata is not registered) > [Python Thin Client] Key class binary metadata registration is skipped > -- > > Key: IGNITE-21100 > URL: https://issues.apache.org/jira/browse/IGNITE-21100 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > > Python thin client does not register binary metadata for user classes that > are used as a key for cache operations. > It seems that it happens because > 1. When we calculate hash code of a key object, we serialize it. The result > is cached in `_buffer` attribute of the object. (see > pyignite.datatypes.complex.BinaryObject.hashcode, > pyignite/binary.py#write_footer:203 ). The hash code of a key object is used > to determine which node this key belongs to (PA). > 2. But when we are about to send key object to the server side - we skip > cache object serialization as the result is already saved in the buffer > mentioned above AND skip its binary type registration. > (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21100) [Python Thin Client] Key class binary metadata is not registered
Mikhail Petrov created IGNITE-21100: --- Summary: [Python Thin Client] Key class binary metadata is not registered Key: IGNITE-21100 URL: https://issues.apache.org/jira/browse/IGNITE-21100 Project: Ignite Issue Type: Task Reporter: Mikhail Petrov Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see pyignite.datatypes.complex.BinaryObject.hashcode, pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21026) [Extensions] Fixed NPE in the performance statistics extension if there are no jobs for a task
[
https://issues.apache.org/jira/browse/IGNITE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-21026:
Labels: ise (was: )
> [Extensions] Fixed NPE in the performance statistics extension if there are
> no jobs for a task
> --
>
> Key: IGNITE-21026
> URL: https://issues.apache.org/jira/browse/IGNITE-21026
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Minor
> Labels: ise
>
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.ignite.internal.performancestatistics.handlers.ComputeHandler.lambda$results$5(ComputeHandler.java:137)
> at java.base/java.lang.Iterable.forEach(Iterable.java:75)
> at
> org.apache.ignite.internal.performancestatistics.handlers.ComputeHandler.results(ComputeHandler.java:130)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.createReport(PerformanceStatisticsReportBuilder.java:129)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.main(PerformanceStatisticsReportBuilder.java:69)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21029) Update Ignite dependency log4j2
[ https://issues.apache.org/jira/browse/IGNITE-21029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21029: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Update Ignite dependency log4j2 > --- > > Key: IGNITE-21029 > URL: https://issues.apache.org/jira/browse/IGNITE-21029 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Update Ignite dependency log4j2 2.20.0 to 2.22.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21029) Update Ignite dependency log4j2
[ https://issues.apache.org/jira/browse/IGNITE-21029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21029: Docs Text: Updated log4j2 dependency to 2.22.0 version (was: Update Ignite dependency log4j2) > Update Ignite dependency log4j2 > --- > > Key: IGNITE-21029 > URL: https://issues.apache.org/jira/browse/IGNITE-21029 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Update Ignite dependency log4j2 2.20.0 to 2.22.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793623#comment-17793623 ] Mikhail Petrov commented on IGNITE-21021: - --cache destroy (CACHE_DESTROY) --cache clear (CACHE_REMOVE) --cache create (CACHE_CREATE) --cache scan (CACHE_READ) All the commands mentioned above have been corrected so that when executed, only the permissions specified in parentheses are checked. > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793623#comment-17793623 ] Mikhail Petrov edited comment on IGNITE-21021 at 12/6/23 10:36 AM: --- --cache destroy (CACHE_DESTROY) --cache clear (CACHE_REMOVE) --cache create (CACHE_CREATE) --cache scan (CACHE_READ) All the CONTROL UTILITY commands mentioned above have been corrected so that when executed, only the permissions specified in parentheses are checked. was (Author: petrovmikhail): --cache destroy (CACHE_DESTROY) --cache clear (CACHE_REMOVE) --cache create (CACHE_CREATE) --cache scan (CACHE_READ) All the commands mentioned above have been corrected so that when executed, only the permissions specified in parentheses are checked. > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-21021. - Resolution: Fixed > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21021: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793619#comment-17793619 ] Mikhail Petrov commented on IGNITE-21021: - [~NSAmelchev] Thank you for the review. > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21021: --- Assignee: Mikhail Petrov > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21023) [Control Utility] Authorization errors are propagated to user as a task execution exception
Mikhail Petrov created IGNITE-21023:
---
Summary: [Control Utility] Authorization errors are propagated to
user as a task execution exception
Key: IGNITE-21023
URL: https://issues.apache.org/jira/browse/IGNITE-21023
Project: Ignite
Issue Type: Task
Reporter: Mikhail Petrov
If the control utility command authorization fails, the user output will
contain only an illegible stack trace of the exception associated with the
execution of the internal task. In some cases it is impossible to determine the
root caused command to fail.
As an example you can execute `--cache clear --caches DEFAULT_CACHE_NAME` on
behalf of the user with no "CACHE_REMOVE" permission granted. As a result you
will get something like that
{code:java}
Command [CACHE] finished with code: 4
Error stack trace:
class org.apache.ignite.internal.client.GridClientException: Failed to reduce
job results due to undeclared user exception
[task=org.apache.ignite.internal.processors.cache.ClearCachesTask@63acb0d2,
err=class org.apache.ignite.compute.ComputeUserUndeclaredException: Failed to
execute job due to unexpected runtime exception
[jobId=5e5ecaa3c81-3ea239af-6e36-4bde-bc0b-121aca80, ses=GridJobSessionImpl
[ses=GridTaskSessionImpl
[taskName=org.apache.ignite.internal.processors.cache.ClearCachesTask,
dep=GridDeployment [ts=1701791460030, depMode=SHARED,
clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
clsLdrId=4e5ecaa3c81-3ea239af-6e36-4bde-bc0b-121aca80, userVer=0, loc=true,
sampleClsName=org.apache.ignite.internal.processors.cache.ClearCachesTask,
pendingUndeploy=false, undeployed=false, usage=2],
taskClsName=org.apache.ignite.internal.processors.cache.ClearCachesTask,
sesId=3e5ecaa3c81-3ea239af-6e36-4bde-bc0b-121aca80,
startTime=1701791460020, endTime=9223372036854775807,
taskNodeId=3ea239af-6e36-4bde-bc0b-121aca80,
clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2, closed=false, cpSpi=null,
failSpi=null, loadSpi=null, usage=1, fullSup=false, internal=true,
topPred=null, mapFut=IgniteFuture [orig=GridFutureAdapter
[ignoreInterrupts=false, state=INIT, res=null, hash=972210139]], execName=null,
secCtx=TestSecurityContext{subject=TestSecuritySubject{id=26ddd492-a139-4dff-8d6d-27c412101dcc,
type=REMOTE_CLIENT, login=no-permissions-login}}],
jobId=5e5ecaa3c81-3ea239af-6e36-4bde-bc0b-121aca80], err=class
org.apache.ignite.IgniteCheckedException: Remote job threw exception.]]
at
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleClientResponse(GridClientNioTcpConnection.java:634)
at
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleResponse(GridClientNioTcpConnection.java:565)
at
org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter$NioListener.onMessage(GridClientConnectionManagerAdapter.java:691)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:116)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3753)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
at
org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1211)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2527)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2282)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1911)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at java.lang.Thread.run(Thread.java:750)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21008) Update Ignite dependency: Netty
[ https://issues.apache.org/jira/browse/IGNITE-21008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21008: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Update Ignite dependency: Netty > --- > > Key: IGNITE-21008 > URL: https://issues.apache.org/jira/browse/IGNITE-21008 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Update Ignite dependency: Netty 4.1.89.Final to 4.1.101.Final -- 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
>
> 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] [Commented] (IGNITE-15419) [Security] Unify the authentication and authorization process for joining node across all discovery implementations
[ https://issues.apache.org/jira/browse/IGNITE-15419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787072#comment-17787072 ] Mikhail Petrov commented on IGNITE-15419: - Fixed as part of https://issues.apache.org/jira/browse/IGNITE-19807 > [Security] Unify the authentication and authorization process for joining > node across all discovery implementations > --- > > Key: IGNITE-15419 > URL: https://issues.apache.org/jira/browse/IGNITE-15419 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > It is needed to unify the authentication and authorization process for > joining node across all discovery implementations. Currently the logic of new > node authentication and authorization is duplicated with some differences. > For example in TCP discovery implementation node is authorized for > NODE_JOINED permission in zookeeper discovery implementation this check is > missed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-15419) [Security] Unify the authentication and authorization process for joining node across all discovery implementations
[ https://issues.apache.org/jira/browse/IGNITE-15419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reopened IGNITE-15419: - > [Security] Unify the authentication and authorization process for joining > node across all discovery implementations > --- > > Key: IGNITE-15419 > URL: https://issues.apache.org/jira/browse/IGNITE-15419 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > It is needed to unify the authentication and authorization process for > joining node across all discovery implementations. Currently the logic of new > node authentication and authorization is duplicated with some differences. > For example in TCP discovery implementation node is authorized for > NODE_JOINED permission in zookeeper discovery implementation this check is > missed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-15419) [Security] Unify the authentication and authorization process for joining node across all discovery implementations
[ https://issues.apache.org/jira/browse/IGNITE-15419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-15419. - Resolution: Duplicate > [Security] Unify the authentication and authorization process for joining > node across all discovery implementations > --- > > Key: IGNITE-15419 > URL: https://issues.apache.org/jira/browse/IGNITE-15419 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > It is needed to unify the authentication and authorization process for > joining node across all discovery implementations. Currently the logic of new > node authentication and authorization is duplicated with some differences. > For example in TCP discovery implementation node is authorized for > NODE_JOINED permission in zookeeper discovery implementation this check is > missed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15419) [Security] Unify the authentication and authorization process for joining node across all discovery implementations
[ https://issues.apache.org/jira/browse/IGNITE-15419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-15419: Ignite Flags: (was: Docs Required,Release Notes Required) > [Security] Unify the authentication and authorization process for joining > node across all discovery implementations > --- > > Key: IGNITE-15419 > URL: https://issues.apache.org/jira/browse/IGNITE-15419 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > It is needed to unify the authentication and authorization process for > joining node across all discovery implementations. Currently the logic of new > node authentication and authorization is duplicated with some differences. > For example in TCP discovery implementation node is authorized for > NODE_JOINED permission in zookeeper discovery implementation this check is > missed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-15419) [Security] Unify the authentication and authorization process for joining node across all discovery implementations
[ https://issues.apache.org/jira/browse/IGNITE-15419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-15419. - Resolution: Fixed > [Security] Unify the authentication and authorization process for joining > node across all discovery implementations > --- > > Key: IGNITE-15419 > URL: https://issues.apache.org/jira/browse/IGNITE-15419 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > It is needed to unify the authentication and authorization process for > joining node across all discovery implementations. Currently the logic of new > node authentication and authorization is duplicated with some differences. > For example in TCP discovery implementation node is authorized for > NODE_JOINED permission in zookeeper discovery implementation this check is > missed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19807) Deprecate legacy authorization approach through Security Context.
[ https://issues.apache.org/jira/browse/IGNITE-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-19807: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Deprecate legacy authorization approach through Security Context. > - > > Key: IGNITE-19807 > URL: https://issues.apache.org/jira/browse/IGNITE-19807 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.16 > > Time Spent: 1h > Remaining Estimate: 0h > > We currently have several ways to check if a user has permission to perform > an operation. > 1. IgniteSecurity#authorize methods that delegate permission check to > security plugin. > 2. SecurityContext#*OperationAllowed methods. They currently are used just > for one check. This approach assumes that granted permissions set is > returned during user authentication and remains immutable. > Let's deprecate the second authorization approach and migrate completely to > the first. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19807) Deprecate legacy authorization approach through Security Context.
[ https://issues.apache.org/jira/browse/IGNITE-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785036#comment-17785036 ] Mikhail Petrov commented on IGNITE-19807: - [~NSAmelchev] Thank you for the review. > Deprecate legacy authorization approach through Security Context. > - > > Key: IGNITE-19807 > URL: https://issues.apache.org/jira/browse/IGNITE-19807 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.16 > > Time Spent: 1h > Remaining Estimate: 0h > > We currently have several ways to check if a user has permission to perform > an operation. > 1. IgniteSecurity#authorize methods that delegate permission check to > security plugin. > 2. SecurityContext#*OperationAllowed methods. They currently are used just > for one check. This approach assumes that granted permissions set is > returned during user authentication and remains immutable. > Let's deprecate the second authorization approach and migrate completely to > the first. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20656) Service awareness for java thin client
[ https://issues.apache.org/jira/browse/IGNITE-20656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784577#comment-17784577 ] Mikhail Petrov commented on IGNITE-20656: - Merged to the master branch. [~vladsz83] Thank you for the contribution! [~ptupitsyn] Thank you for the review! > Service awareness for java thin client > -- > > Key: IGNITE-20656 > URL: https://issues.apache.org/jira/browse/IGNITE-20656 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Java thin client (like the other clients) can call service on a node where > service is not deployed. We might implement service awareness like partition > awareness starting with java thin client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20656) Service awareness for java thin client
[ https://issues.apache.org/jira/browse/IGNITE-20656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20656: Fix Version/s: 2.16 > Service awareness for java thin client > -- > > Key: IGNITE-20656 > URL: https://issues.apache.org/jira/browse/IGNITE-20656 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 4h > Remaining Estimate: 0h > > Java thin client (like the other clients) can call service on a node where > service is not deployed. We might implement service awareness like partition > awareness starting with java thin client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20627) Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command.
[ https://issues.apache.org/jira/browse/IGNITE-20627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779912#comment-17779912 ] Mikhail Petrov commented on IGNITE-20627: - [~NSAmelchev] Thank you for the review. > Add the number of partitions processed by the indexing worker to the output > of the index_rebuild_status command. > > > Key: IGNITE-20627 > URL: https://issues.apache.org/jira/browse/IGNITE-20627 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20627) Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command.
[ https://issues.apache.org/jira/browse/IGNITE-20627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20627: Labels: ise (was: ) > Add the number of partitions processed by the indexing worker to the output > of the index_rebuild_status command. > > > Key: IGNITE-20627 > URL: https://issues.apache.org/jira/browse/IGNITE-20627 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20627) Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command.
[ https://issues.apache.org/jira/browse/IGNITE-20627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20627: Ignite Flags: Docs Required (was: Docs Required,Release Notes Required) > Add the number of partitions processed by the indexing worker to the output > of the index_rebuild_status command. > > > Key: IGNITE-20627 > URL: https://issues.apache.org/jira/browse/IGNITE-20627 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20627) Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command.
[ https://issues.apache.org/jira/browse/IGNITE-20627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20627: Fix Version/s: 2.16 > Add the number of partitions processed by the indexing worker to the output > of the index_rebuild_status command. > > > Key: IGNITE-20627 > URL: https://issues.apache.org/jira/browse/IGNITE-20627 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20627) Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command.
[ https://issues.apache.org/jira/browse/IGNITE-20627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20627: Priority: Minor (was: Major) > Add the number of partitions processed by the indexing worker to the output > of the index_rebuild_status command. > > > Key: IGNITE-20627 > URL: https://issues.apache.org/jira/browse/IGNITE-20627 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20424) Slow thin client connection can lead to consuming of huge amount of heap
[ https://issues.apache.org/jira/browse/IGNITE-20424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20424: Description: All messages designated for the thin client are accumulated in the selector queue GridSelectorNioSessionImpl#queue before they are sent. Note that GridSelectorNioSessionImpl#queue for the Ignite Thin Client currently is unbound. If the thin client connection is slow and a huge number of heavy messages are about to send to the thin client, GridSelectorNioSessionImpl#queue growing size can lead to OOM. See 1. https://issues.apache.org/jira/browse/IGNITE-20327 2. https://github.com/apache/ignite/issues/10559 We need to investigate mechanisms to limit the thin client message queue size. Currently, two mechanisms related to the described problem have already been implemented: 1. GridNioServer.Builder#messageQueueSizeListener is used to limit the message queue size for Ignite Thick clients - if the message queue size limit is exceeded, the client node will be forced to leave the cluster. 2. GridNioServer.Builder#sendQueueLimit is used to block a thread that sends a message if the message queue size limit is exceeded. Currently is used with Thick Clients and Ignite REST clients. The first approach was chosen to reuse it for thin clients. was: All messages designated for the thin client are accumulated in the selector queue GridSelectorNioSessionImpl#queue before they are sent. Note that GridSelectorNioSessionImpl#queue for the Ignite Thin Client currently is unbound. If the thin client connection is slow and a huge number of heavy messages are about to send to the thin client, GridSelectorNioSessionImpl#queue growing size can lead to OOM. See 1. https://issues.apache.org/jira/browse/IGNITE-20327 2. https://github.com/apache/ignite/issues/10559 We need to investigate mechanisms to limit the thin client message queue size. Currently, two mechanisms related to the described problem have already been implemented: 1. GridNioServer.Builder#messageQueueSizeListener is used to limit the message queue size for Ignite Thick clients - if the message queue size limit is exceeded, the client node will be forced to leave the cluster. 2. GridNioServer.Builder#sendQueueLimit is used to block a thread that sends a message if the message queue size limit is exceeded. Currently is used with Thick Clients and Ignite REST clients. > Slow thin client connection can lead to consuming of huge amount of heap > - > > Key: IGNITE-20424 > URL: https://issues.apache.org/jira/browse/IGNITE-20424 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 2.5h > Remaining Estimate: 0h > > All messages designated for the thin client are accumulated in the selector > queue GridSelectorNioSessionImpl#queue before they are sent. Note that > GridSelectorNioSessionImpl#queue for the Ignite Thin Client currently is > unbound. If the thin client connection is slow and a huge number of heavy > messages are about to send to the thin client, > GridSelectorNioSessionImpl#queue growing size can lead to OOM. > See > 1. https://issues.apache.org/jira/browse/IGNITE-20327 > 2. https://github.com/apache/ignite/issues/10559 > We need to investigate mechanisms to limit the thin client message queue size. > Currently, two mechanisms related to the described problem have already been > implemented: > 1. GridNioServer.Builder#messageQueueSizeListener is used to limit the > message queue size for Ignite Thick clients - if the message queue size limit > is exceeded, the client node will be forced to leave the cluster. > 2. GridNioServer.Builder#sendQueueLimit is used to block a thread that sends > a message if the message queue size limit is exceeded. Currently is used with > Thick Clients and Ignite REST clients. > The first approach was chosen to reuse it for thin clients. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[
https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-20688:
Priority: Critical (was: Major)
> Java Thin Client - Error while deserializing Collection
> ---
>
> Key: IGNITE-20688
> URL: https://issues.apache.org/jira/browse/IGNITE-20688
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Affects Versions: 2.9, 2.10, 2.12, 2.13, 2.14, 2.15
>Reporter: Rahul Mohan
>Assignee: Mikhail Petrov
>Priority: Critical
> Labels: ise
> Fix For: 2.16
>
> Attachments: image001.png
>
>
> I have encountered an issue in deserializing cache values which are of
> Collection type.
> The issue occurs if a field in different objects within the collection
> points to the same reference.
> *Versions:*
> org.apache.ignite:ignite-core:2.9.0 to org.apache.ignite:ignite-core:2.15.0
>
> {code:java}
> Person.java
> public class Person implements Serializable {
> private String id;
> private String firstName;
> private String lastName;
> private double salary;
> private String country;
> private String deleted;
> private Set accounts;
> }
> Client
> ClientCacheConfiguration cacheCfg = new
> ClientCacheConfiguration().setName(cacheName).
> setCacheMode(CacheMode.REPLICATED).
>
> setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
>
> cache = client.getOrCreateCache(cacheCfg);
>
> Set set = new HashSet<>();
> set.add("1");
>
> List persons = new ArrayList<>();
> persons.add(new Person("105286a4","Jack","Smith",1f,
> "USA","false", set));
> persons.add(new Person("98545b0fd3af","John", "Doe", 50f,
> "Australia","false", null));
> persons.add(new Person("98545b0fd3afd","Hari","M",40f,
> "India", null, null));
> persons.add(new
> Person("985488b0fd3ae","Bugs","Bunny",30f,"Wabbit Land ", null, set));
> cache.put("group1", value) // Write collection to cache
>
> List persons = (List) cache.get("group1"); // Get
> from cache, Exception here {code}
>
> *Exception:*
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Failed to deserialize
> object [typeName=com.ignite.example.model.Person]
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:927)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:316)
> at
> org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:557)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapCollection(ClientUtils.java:578)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:562)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:546)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:556)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:561)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache$$Lambda$395/1950117092.apply(Unknown
> Source)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:284)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:219)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:198)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:261)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:508)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.get(TcpClientCache.java:111)
> at
> com.ignite.example.service.ApacheIgniteService.printAllKeys(ApacheIgniteService.java:117)
> at
> com.ignite.example.service.ApacheIgniteService.init(ApacheIgniteService.java:103)
> at
>
[jira] [Updated] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[
https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-20688:
Fix Version/s: 2.16
> Java Thin Client - Error while deserializing Collection
> ---
>
> Key: IGNITE-20688
> URL: https://issues.apache.org/jira/browse/IGNITE-20688
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Affects Versions: 2.9, 2.10, 2.12, 2.13, 2.14, 2.15
>Reporter: Rahul Mohan
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.16
>
> Attachments: image001.png
>
>
> I have encountered an issue in deserializing cache values which are of
> Collection type.
> The issue occurs if a field in different objects within the collection
> points to the same reference.
> *Versions:*
> org.apache.ignite:ignite-core:2.9.0 to org.apache.ignite:ignite-core:2.15.0
>
> {code:java}
> Person.java
> public class Person implements Serializable {
> private String id;
> private String firstName;
> private String lastName;
> private double salary;
> private String country;
> private String deleted;
> private Set accounts;
> }
> Client
> ClientCacheConfiguration cacheCfg = new
> ClientCacheConfiguration().setName(cacheName).
> setCacheMode(CacheMode.REPLICATED).
>
> setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
>
> cache = client.getOrCreateCache(cacheCfg);
>
> Set set = new HashSet<>();
> set.add("1");
>
> List persons = new ArrayList<>();
> persons.add(new Person("105286a4","Jack","Smith",1f,
> "USA","false", set));
> persons.add(new Person("98545b0fd3af","John", "Doe", 50f,
> "Australia","false", null));
> persons.add(new Person("98545b0fd3afd","Hari","M",40f,
> "India", null, null));
> persons.add(new
> Person("985488b0fd3ae","Bugs","Bunny",30f,"Wabbit Land ", null, set));
> cache.put("group1", value) // Write collection to cache
>
> List persons = (List) cache.get("group1"); // Get
> from cache, Exception here {code}
>
> *Exception:*
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Failed to deserialize
> object [typeName=com.ignite.example.model.Person]
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:927)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:316)
> at
> org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:557)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapCollection(ClientUtils.java:578)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:562)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:546)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:556)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:561)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache$$Lambda$395/1950117092.apply(Unknown
> Source)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:284)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:219)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:198)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:261)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:508)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.get(TcpClientCache.java:111)
> at
> com.ignite.example.service.ApacheIgniteService.printAllKeys(ApacheIgniteService.java:117)
> at
> com.ignite.example.service.ApacheIgniteService.init(ApacheIgniteService.java:103)
> at
>
[jira] [Updated] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[
https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-20688:
Labels: ise (was: )
> Java Thin Client - Error while deserializing Collection
> ---
>
> Key: IGNITE-20688
> URL: https://issues.apache.org/jira/browse/IGNITE-20688
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Affects Versions: 2.9, 2.10, 2.12, 2.13, 2.14, 2.15
>Reporter: Rahul Mohan
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Fix For: 2.16
>
> Attachments: image001.png
>
>
> I have encountered an issue in deserializing cache values which are of
> Collection type.
> The issue occurs if a field in different objects within the collection
> points to the same reference.
> *Versions:*
> org.apache.ignite:ignite-core:2.9.0 to org.apache.ignite:ignite-core:2.15.0
>
> {code:java}
> Person.java
> public class Person implements Serializable {
> private String id;
> private String firstName;
> private String lastName;
> private double salary;
> private String country;
> private String deleted;
> private Set accounts;
> }
> Client
> ClientCacheConfiguration cacheCfg = new
> ClientCacheConfiguration().setName(cacheName).
> setCacheMode(CacheMode.REPLICATED).
>
> setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
>
> cache = client.getOrCreateCache(cacheCfg);
>
> Set set = new HashSet<>();
> set.add("1");
>
> List persons = new ArrayList<>();
> persons.add(new Person("105286a4","Jack","Smith",1f,
> "USA","false", set));
> persons.add(new Person("98545b0fd3af","John", "Doe", 50f,
> "Australia","false", null));
> persons.add(new Person("98545b0fd3afd","Hari","M",40f,
> "India", null, null));
> persons.add(new
> Person("985488b0fd3ae","Bugs","Bunny",30f,"Wabbit Land ", null, set));
> cache.put("group1", value) // Write collection to cache
>
> List persons = (List) cache.get("group1"); // Get
> from cache, Exception here {code}
>
> *Exception:*
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Failed to deserialize
> object [typeName=com.ignite.example.model.Person]
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:927)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:316)
> at
> org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:557)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapCollection(ClientUtils.java:578)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:562)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:546)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:556)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:561)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache$$Lambda$395/1950117092.apply(Unknown
> Source)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:284)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:219)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:198)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:261)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:508)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.get(TcpClientCache.java:111)
> at
> com.ignite.example.service.ApacheIgniteService.printAllKeys(ApacheIgniteService.java:117)
> at
> com.ignite.example.service.ApacheIgniteService.init(ApacheIgniteService.java:103)
> at
>
[jira] [Commented] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[
https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778438#comment-17778438
]
Mikhail Petrov commented on IGNITE-20688:
-
[~rahmo] Thank you for reporting the issue!
The information you provided is enough to reproduce and confirm the problem. We
are doing our best to fix it as soon as possible.
As a WA you can wrap List that you put in the cache with some other
class e.g.
{code:java}
public static class Organization implements Serializable {
private List employees;
}
{code}
> Java Thin Client - Error while deserializing Collection
> ---
>
> Key: IGNITE-20688
> URL: https://issues.apache.org/jira/browse/IGNITE-20688
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Affects Versions: 2.9, 2.10, 2.12, 2.13, 2.14, 2.15
>Reporter: Rahul Mohan
>Assignee: Mikhail Petrov
>Priority: Major
> Attachments: image001.png
>
>
> I have encountered an issue in deserializing cache values which are of
> Collection type.
> The issue occurs if a field in different objects within the collection
> points to the same reference.
> *Versions:*
> org.apache.ignite:ignite-core:2.9.0 to org.apache.ignite:ignite-core:2.15.0
>
> {code:java}
> Person.java
> public class Person implements Serializable {
> private String id;
> private String firstName;
> private String lastName;
> private double salary;
> private String country;
> private String deleted;
> private Set accounts;
> }
> Client
> ClientCacheConfiguration cacheCfg = new
> ClientCacheConfiguration().setName(cacheName).
> setCacheMode(CacheMode.REPLICATED).
>
> setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
>
> cache = client.getOrCreateCache(cacheCfg);
>
> Set set = new HashSet<>();
> set.add("1");
>
> List persons = new ArrayList<>();
> persons.add(new Person("105286a4","Jack","Smith",1f,
> "USA","false", set));
> persons.add(new Person("98545b0fd3af","John", "Doe", 50f,
> "Australia","false", null));
> persons.add(new Person("98545b0fd3afd","Hari","M",40f,
> "India", null, null));
> persons.add(new
> Person("985488b0fd3ae","Bugs","Bunny",30f,"Wabbit Land ", null, set));
> cache.put("group1", value) // Write collection to cache
>
> List persons = (List) cache.get("group1"); // Get
> from cache, Exception here {code}
>
> *Exception:*
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Failed to deserialize
> object [typeName=com.ignite.example.model.Person]
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:927)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:316)
> at
> org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:557)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapCollection(ClientUtils.java:578)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:562)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:546)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:556)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:561)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache$$Lambda$395/1950117092.apply(Unknown
> Source)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:284)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:219)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:198)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:261)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:508)
> at
>
[jira] [Assigned] (IGNITE-19988) Add index creation (population) status to index view
[ https://issues.apache.org/jira/browse/IGNITE-19988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-19988: --- Assignee: (was: Mikhail Petrov) > Add index creation (population) status to index view > > > Key: IGNITE-19988 > URL: https://issues.apache.org/jira/browse/IGNITE-19988 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.15 >Reporter: Ivan Daschinsky >Priority: Major > Labels: ise > Fix For: 2.16 > > > Sometimes index creation can be quite long. A user might start queries > without waiting for finish of the index creation process and see slow > queries. It is necessary to provide index status information to users by > exposing it in the index system view. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[
https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-20688:
---
Assignee: Mikhail Petrov
> Java Thin Client - Error while deserializing Collection
> ---
>
> Key: IGNITE-20688
> URL: https://issues.apache.org/jira/browse/IGNITE-20688
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Affects Versions: 2.9, 2.10, 2.12, 2.13, 2.14, 2.15
>Reporter: Rahul Mohan
>Assignee: Mikhail Petrov
>Priority: Major
>
> I have encountered an issue in deserializing cache values which are of
> Collection type.
> The issue occurs if a field in different objects within the collection
> points to the same reference.
> *Versions:*
> org.apache.ignite:ignite-core:2.9.0 to org.apache.ignite:ignite-core:2.15.0
>
> {code:java}
> Person.java
> public class Person implements Serializable {
> private String id;
> private String firstName;
> private String lastName;
> private double salary;
> private String country;
> private String deleted;
> private Set accounts;
> }
> Client
> ClientCacheConfiguration cacheCfg = new
> ClientCacheConfiguration().setName(cacheName).
> setCacheMode(CacheMode.REPLICATED).
>
> setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
>
> cache = client.getOrCreateCache(cacheCfg);
>
> Set set = new HashSet<>();
> set.add("1");
>
> List persons = new ArrayList<>();
> persons.add(new Person("105286a4","Jack","Smith",1f,
> "USA","false", set));
> persons.add(new Person("98545b0fd3af","John", "Doe", 50f,
> "Australia","false", null));
> persons.add(new Person("98545b0fd3afd","Hari","M",40f,
> "India", null, null));
> persons.add(new
> Person("985488b0fd3ae","Bugs","Bunny",30f,"Wabbit Land ", null, set));
> cache.put("group1", value) // Write collection to cache
>
> List persons = (List) cache.get("group1"); // Get
> from cache, Exception here {code}
>
> *Exception:*
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Failed to deserialize
> object [typeName=com.ignite.example.model.Person]
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:927)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:316)
> at
> org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:557)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapCollection(ClientUtils.java:578)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:562)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:546)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:556)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:561)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache$$Lambda$395/1950117092.apply(Unknown
> Source)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:284)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:219)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:198)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:261)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:508)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.get(TcpClientCache.java:111)
> at
> com.ignite.example.service.ApacheIgniteService.printAllKeys(ApacheIgniteService.java:117)
> at
> com.ignite.example.service.ApacheIgniteService.init(ApacheIgniteService.java:103)
> at
> com.ignite.example.IgniteCacheExampleApplication.run(IgniteCacheExampleApplication.java:22)
> at
>
[jira] [Resolved] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-11970. - Resolution: Fixed > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Fix For: 2.16 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-11970: Fix Version/s: 2.16 > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Fix For: 2.16 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776661#comment-17776661 ] Mikhail Petrov commented on IGNITE-11970: - [~alex_pl] Thank you for the review. > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Time Spent: 3h 20m > Remaining Estimate: 0h > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20424) Slow thin client connection can lead to consuming of huge amount of heap
[ https://issues.apache.org/jira/browse/IGNITE-20424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774874#comment-17774874 ] Mikhail Petrov commented on IGNITE-20424: - [~alex_pl], [~ivandasch] Thank you a lot for the review. > Slow thin client connection can lead to consuming of huge amount of heap > - > > Key: IGNITE-20424 > URL: https://issues.apache.org/jira/browse/IGNITE-20424 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Time Spent: 2.5h > Remaining Estimate: 0h > > All messages designated for the thin client are accumulated in the selector > queue GridSelectorNioSessionImpl#queue before they are sent. Note that > GridSelectorNioSessionImpl#queue for the Ignite Thin Client currently is > unbound. If the thin client connection is slow and a huge number of heavy > messages are about to send to the thin client, > GridSelectorNioSessionImpl#queue growing size can lead to OOM. > See > 1. https://issues.apache.org/jira/browse/IGNITE-20327 > 2. https://github.com/apache/ignite/issues/10559 > We need to investigate mechanisms to limit the thin client message queue size. > Currently, two mechanisms related to the described problem have already been > implemented: > 1. GridNioServer.Builder#messageQueueSizeListener is used to limit the > message queue size for Ignite Thick clients - if the message queue size limit > is exceeded, the client node will be forced to leave the cluster. > 2. GridNioServer.Builder#sendQueueLimit is used to block a thread that sends > a message if the message queue size limit is exceeded. Currently is used with > Thick Clients and Ignite REST clients. -- This message was sent by Atlassian Jira (v8.20.10#820010)
