[jira] [Updated] (IGNITE-10733) CassandraStore in write behind mode loses data when back-pressure is active
[ https://issues.apache.org/jira/browse/IGNITE-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov updated IGNITE-10733: - Ignite Flags: (was: Docs Required) > CassandraStore in write behind mode loses data when back-pressure is active > --- > > Key: IGNITE-10733 > URL: https://issues.apache.org/jira/browse/IGNITE-10733 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.6, 2.7 >Reporter: Dmitry Konstantinov >Priority: Critical > > When WriteBehindStore writes data synchronously to an underline store using > back-pressure logic (storeSingleValue) - the operation is happened in a > transaction. CassandraStore uses presence of transaction to clarify is it a > atomicity needed: if there is a transaction - CassandraStore accumulates data > in a session-local attribute. When transaction is committed WriteBehindStore > is notified about the related session end but CassandraStore is not notified > (and not subscribed using a session listener), as a result CassandraStore > does not flush the accumulated values in this cases and they are lost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10733) CassandraStore in write behind mode loses data when back-pressure is active
[ https://issues.apache.org/jira/browse/IGNITE-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov updated IGNITE-10733: - Description: When WriteBehindStore writes data synchronously to an underline store using back-pressure logic (storeSingleValue) - the operation is happened in a transaction. CassandraStore uses presence of transaction to clarify is a atomicity needed: if there is a transaction - CassandraStore accumulates data in a session-local attribute to flush at the end of the transaction using Cassandra batches. When transaction is committed WriteBehindStore is notified about the related session end but underline CassandraStore is not notified (and not subscribed using a session listener), as a result CassandraStore does not flush the accumulated values written via storeSingleValue and they are lost. (was: When WriteBehindStore writes data synchronously to an underline store using back-pressure logic (storeSingleValue) - the operation is happened in a transaction. CassandraStore uses presence of transaction to clarify is it a atomicity needed: if there is a transaction - CassandraStore accumulates data in a session-local attribute. When transaction is committed WriteBehindStore is notified about the related session end but CassandraStore is not notified (and not subscribed using a session listener), as a result CassandraStore does not flush the accumulated values in this cases and they are lost.) > CassandraStore in write behind mode loses data when back-pressure is active > --- > > Key: IGNITE-10733 > URL: https://issues.apache.org/jira/browse/IGNITE-10733 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.6, 2.7 >Reporter: Dmitry Konstantinov >Priority: Critical > > When WriteBehindStore writes data synchronously to an underline store using > back-pressure logic (storeSingleValue) - the operation is happened in a > transaction. CassandraStore uses presence of transaction to clarify is a > atomicity needed: if there is a transaction - CassandraStore accumulates data > in a session-local attribute to flush at the end of the transaction using > Cassandra batches. When transaction is committed WriteBehindStore is notified > about the related session end but underline CassandraStore is not notified > (and not subscribed using a session listener), as a result CassandraStore > does not flush the accumulated values written via storeSingleValue and they > are lost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10733) CassandraStore in write behind mode loses data when back-pressure is active
[ https://issues.apache.org/jira/browse/IGNITE-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov updated IGNITE-10733: - Description: When GridCacheWriteBehindStore writes data synchronously to an underline store using back-pressure logic (flushSingleValue) - the operation is happened in a transaction. CassandraCacheStore uses presence of transaction to clarify is a atomicity needed: if there is a transaction - CassandraCacheStore accumulates data in a session-local attribute to flush at the end of the transaction using Cassandra batches. When transaction is committed GridCacheWriteBehindStore is notified about the related session end but underline CassandraCacheStore is not notified (and not subscribed using a session listener), as a result CassandraStore does not flush the accumulated values written via flushSingleValue and they are lost. (was: When WriteBehindStore writes data synchronously to an underline store using back-pressure logic (storeSingleValue) - the operation is happened in a transaction. CassandraStore uses presence of transaction to clarify is a atomicity needed: if there is a transaction - CassandraStore accumulates data in a session-local attribute to flush at the end of the transaction using Cassandra batches. When transaction is committed WriteBehindStore is notified about the related session end but underline CassandraStore is not notified (and not subscribed using a session listener), as a result CassandraStore does not flush the accumulated values written via storeSingleValue and they are lost.) > CassandraStore in write behind mode loses data when back-pressure is active > --- > > Key: IGNITE-10733 > URL: https://issues.apache.org/jira/browse/IGNITE-10733 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.6, 2.7 >Reporter: Dmitry Konstantinov >Priority: Critical > > When GridCacheWriteBehindStore writes data synchronously to an underline > store using back-pressure logic (flushSingleValue) - the operation is > happened in a transaction. CassandraCacheStore uses presence of transaction > to clarify is a atomicity needed: if there is a transaction - > CassandraCacheStore accumulates data in a session-local attribute to flush at > the end of the transaction using Cassandra batches. When transaction is > committed GridCacheWriteBehindStore is notified about the related session end > but underline CassandraCacheStore is not notified (and not subscribed using a > session listener), as a result CassandraStore does not flush the accumulated > values written via flushSingleValue and they are lost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10733) CassandraStore in write behind mode loses data when back-pressure is active
[ https://issues.apache.org/jira/browse/IGNITE-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov updated IGNITE-10733: - Description: When WriteBehindStore writes data synchronously to an underline store using back-pressure logic (storeSingleValue) - the operation is happened in a transaction. CassandraStore uses presence of transaction to clarify is it a atomicity needed: if there is a transaction - CassandraStore accumulates data in a session-local attribute. When transaction is committed WriteBehindStore is notified about the related session end but CassandraStore is not notified (and not subscribed using a session listener), as a result CassandraStore does not flush the accumulated values in this cases and they are lost. (was: Whe) > CassandraStore in write behind mode loses data when back-pressure is active > --- > > Key: IGNITE-10733 > URL: https://issues.apache.org/jira/browse/IGNITE-10733 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.6, 2.7 >Reporter: Dmitry Konstantinov >Priority: Critical > > When WriteBehindStore writes data synchronously to an underline store using > back-pressure logic (storeSingleValue) - the operation is happened in a > transaction. CassandraStore uses presence of transaction to clarify is it a > atomicity needed: if there is a transaction - CassandraStore accumulates data > in a session-local attribute. When transaction is committed WriteBehindStore > is notified about the related session end but CassandraStore is not notified > (and not subscribed using a session listener), as a result CassandraStore > does not flush the accumulated values in this cases and they are lost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10733) CassandraStore in write behind mode loses data when back-pressure is active
Dmitry Konstantinov created IGNITE-10733: Summary: CassandraStore in write behind mode loses data when back-pressure is active Key: IGNITE-10733 URL: https://issues.apache.org/jira/browse/IGNITE-10733 Project: Ignite Issue Type: Bug Components: cache, cassandra Affects Versions: 2.7, 2.6, 2.5 Reporter: Dmitry Konstantinov Whe -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10665) CassandraSessionImpl creates IgniteException even if it is not needed
Dmitry Konstantinov created IGNITE-10665:
Summary: CassandraSessionImpl creates IgniteException even if it
is not needed
Key: IGNITE-10665
URL: https://issues.apache.org/jira/browse/IGNITE-10665
Project: Ignite
Issue Type: Bug
Components: cassandra
Affects Versions: 2.7, 2.6, 2.5, 2.4
Reporter: Dmitry Konstantinov
*
[https://github.com/apache/ignite/blob/master/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L208]
*
[https://git.netcracker.com/thirdparty.modified/ignite/blob/2.4.0_nc_modified/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L399]
Example from a thread dump:
{code:java}
"flusher-5-#97" #126 prio=5 os_prio=0 tid=0x7fc070228000 nid=0x2a68
runnable [0x7fbff02a3000]
java.lang.Thread.State: RUNNABLE
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:783)
- locked <0x00076b2201d0> (a org.apache.ignite.IgniteException)
at java.lang.Throwable.(Throwable.java:265)
at java.lang.Exception.(Exception.java:66)
at java.lang.RuntimeException.(RuntimeException.java:62)
at org.apache.ignite.IgniteException.(IgniteException.java:44)
at
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:209)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore.writeAll(CassandraCacheStore.java:354)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.updateStore(GridCacheWriteBehindStore.java:814)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.applyBatch(GridCacheWriteBehindStore.java:726)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.access$2400(GridCacheWriteBehindStore.java:76)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore$Flusher.flushCacheCoalescing(GridCacheWriteBehindStore.java:1143)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore$Flusher.body(GridCacheWriteBehindStore.java:1016)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9993) Some values cached in WB store are locked during a batch flush
[
https://issues.apache.org/jira/browse/IGNITE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated IGNITE-9993:
Summary: Some values cached in WB store are locked during a batch flush
(was: Values cached in WB store are locked during a batch flush)
> Some values cached in WB store are locked during a batch flush
> --
>
> Key: IGNITE-9993
> URL: https://issues.apache.org/jira/browse/IGNITE-9993
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Dmitry Konstantinov
>Priority: Major
>
> The following logic is executed under write lock within flushing logic:
> {code:java}
> applyBatch(pending, true, null);
> {code}
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L1120]
> In combination with IGNITE-5003 it may cause locking of a put/remove
> operation for the first value in next batch while the whole current batch is
> applying.
> applyBatch(pending, true, null); should be moved out of the lock guarded
> section.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9993) Values cached in WB store are locked during a batch flush
[
https://issues.apache.org/jira/browse/IGNITE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated IGNITE-9993:
Affects Version/s: 2.6
> Values cached in WB store are locked during a batch flush
> -
>
> Key: IGNITE-9993
> URL: https://issues.apache.org/jira/browse/IGNITE-9993
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Dmitry Konstantinov
>Priority: Major
>
> The following logic is executed under write lock:
> {code: java}
> applyBatch(pending, true, null);
> {code}
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L1120
> In combination with IGNITE-5003 it may cause locking of a put/remove
> operation for the first value in next batch while the whole current batch is
> applying.
> applyBatch(pending, true, null); should be moved out of the lock guarded
> section.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9993) Values cached in WB store are locked during a batch flush
[
https://issues.apache.org/jira/browse/IGNITE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated IGNITE-9993:
Description:
The following logic is executed under write lock:
{code: java}
applyBatch(pending, true, null);
{code}
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L1120
In combination with IGNITE-5003 it may cause locking of a put/remove operation
for the first value in next batch while the whole current batch is applying.
applyBatch(pending, true, null); should be moved out of the lock guarded
section.
was:
The following logic is executed under write lock:
{code: java}
applyBatch(pending, true, null);
{code}
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L1120
In combination with IGNITE-5003 it may cause locking of a put/remove operation
while the whole batch is applying.
applyBatch(pending, true, null); should be moved out of the lock guarded
section.
> Values cached in WB store are locked during a batch flush
> -
>
> Key: IGNITE-9993
> URL: https://issues.apache.org/jira/browse/IGNITE-9993
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Dmitry Konstantinov
>Priority: Major
>
> The following logic is executed under write lock:
> {code: java}
> applyBatch(pending, true, null);
> {code}
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L1120
> In combination with IGNITE-5003 it may cause locking of a put/remove
> operation for the first value in next batch while the whole current batch is
> applying.
> applyBatch(pending, true, null); should be moved out of the lock guarded
> section.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9993) Values cached in WB store are locked during a batch flush
[
https://issues.apache.org/jira/browse/IGNITE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated IGNITE-9993:
Description:
The following logic is executed under write lock within flushing logic:
{code:java}
applyBatch(pending, true, null);
{code}
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L1120]
In combination with IGNITE-5003 it may cause locking of a put/remove operation
for the first value in next batch while the whole current batch is applying.
applyBatch(pending, true, null); should be moved out of the lock guarded
section.
was:
The following logic is executed under write lock:
{code: java}
applyBatch(pending, true, null);
{code}
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L1120
In combination with IGNITE-5003 it may cause locking of a put/remove operation
for the first value in next batch while the whole current batch is applying.
applyBatch(pending, true, null); should be moved out of the lock guarded
section.
> Values cached in WB store are locked during a batch flush
> -
>
> Key: IGNITE-9993
> URL: https://issues.apache.org/jira/browse/IGNITE-9993
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Dmitry Konstantinov
>Priority: Major
>
> The following logic is executed under write lock within flushing logic:
> {code:java}
> applyBatch(pending, true, null);
> {code}
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L1120]
> In combination with IGNITE-5003 it may cause locking of a put/remove
> operation for the first value in next batch while the whole current batch is
> applying.
> applyBatch(pending, true, null); should be moved out of the lock guarded
> section.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9993) Values cached in WB store are locked during a batch flush
[
https://issues.apache.org/jira/browse/IGNITE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated IGNITE-9993:
Ignite Flags: (was: Docs Required)
> Values cached in WB store are locked during a batch flush
> -
>
> Key: IGNITE-9993
> URL: https://issues.apache.org/jira/browse/IGNITE-9993
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Dmitry Konstantinov
>Priority: Major
>
> The following logic is executed under write lock:
> {code: java}
> applyBatch(pending, true, null);
> {code}
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L1120
> In combination with IGNITE-5003 it may cause locking of a put/remove
> operation while the whole batch is applying.
> applyBatch(pending, true, null); should be moved out of the lock guarded
> section.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9993) Values cached in WB store are locked during a batch flush
Dmitry Konstantinov created IGNITE-9993:
---
Summary: Values cached in WB store are locked during a batch flush
Key: IGNITE-9993
URL: https://issues.apache.org/jira/browse/IGNITE-9993
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Dmitry Konstantinov
The following logic is executed under write lock:
{code: java}
applyBatch(pending, true, null);
{code}
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L1120
In combination with IGNITE-5003 it may cause locking of a put/remove operation
while the whole batch is applying.
applyBatch(pending, true, null); should be moved out of the lock guarded
section.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8978) Affinity throws "IgniteException: Failed to find cache" after an Ignite client re-connect
Dmitry Konstantinov created IGNITE-8978:
---
Summary: Affinity throws "IgniteException: Failed to find cache"
after an Ignite client re-connect
Key: IGNITE-8978
URL: https://issues.apache.org/jira/browse/IGNITE-8978
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Environment: ver. 2.5.0#20180523-sha1:86e110c7
OS: Windows 7 6.1 amd64
Java(TM) SE Runtime Environment 1.8.0_101-b13 Oracle Corporation Java
HotSpot(TM) 64-Bit Server VM 25.101-b13
Reporter: Dmitry Konstantinov
Use case:
# A single Ignite server node is deployed and running.
# An ignite Java client connects to the server node and starts to do cache
operations (put/get) + invoke Affinity.mapKeyToNode() method.
# The Ignite server process is killed
# Waiting for some time
# Starting the Ignite server back.
{code:java}
public static void main(String ... args) throws InterruptedException {
Ignition.setClientMode(true);
String config = "ignite-config.xml";
try (Ignite ignite = Ignition.start(config)) {
String cacheName = "testCache";
IgniteCache cache = ignite.cache(cacheName);
Affinity affinity = ignite.affinity(cacheName);
while (true) {
try {
String key = "testKey";
cache.put(key, "testValue");
String value = cache.get(key);
ClusterNode primary = affinity.mapKeyToNode(key);
System.out.println("read value: " + value + ", primary node: "
+ primary);
} catch (Exception e) {
System.out.println("Error: " + e.toString());
e.printStackTrace();
} finally {
Thread.sleep(1000);
}
}
}
}
{code}
Expected result:
affinity.mapKeyToNode(key) starts to work after a re-connection to the
restarted server
Actual result:
affinity.mapKeyToNode(key) continues to throw the following exception:
{code:java}
class org.apache.ignite.IgniteException: Failed to find cache (cache was not
started yet or cache was already stopped): testCache
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.affinityTopologyVersion(GridCacheAffinityManager.java:402)
at
org.apache.ignite.internal.processors.cache.affinity.GridCacheAffinityImpl.topologyVersion(GridCacheAffinityImpl.java:241)
at
org.apache.ignite.internal.processors.cache.affinity.GridCacheAffinityImpl.mapKeysToNodes(GridCacheAffinityImpl.java:189)
at
org.apache.ignite.internal.processors.cache.affinity.GridCacheAffinityImpl.mapKeyToNode(GridCacheAffinityImpl.java:182)
at test.ignite.Main.main(Main.java:25)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7219) Reduce memory allocation in cassandra.persistence.PojoFieldAccessor
[ https://issues.apache.org/jira/browse/IGNITE-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov updated IGNITE-7219: Attachment: ignitePojoFieldAccessorMemAlloc.png > Reduce memory allocation in cassandra.persistence.PojoFieldAccessor > --- > > Key: IGNITE-7219 > URL: https://issues.apache.org/jira/browse/IGNITE-7219 > Project: Ignite > Issue Type: Improvement > Components: cassandra >Affects Versions: 2.1, 2.2, 2.3 >Reporter: Dmitry Konstantinov > Attachments: ignitePojoFieldAccessorMemAlloc.png > > > As a part of store logic of CassandraCacheStore if strategy="POJO" is used to > store a value entity - > org.apache.ignite.cache.store.cassandra.persistence.PojoFieldAccessor is used > to work with POJO properties. Within the methods getValue/setValue > getReadMethod()/getWriteMethod() are invoked each time. As a part of the > methods invocation sun.reflect.misc.ReflectUtil#isNonPublicProxyClass is > triggered which works with class names as strings and allocates a memory. It > is a small allocation by itself but it is triggered very frequently - for > each field for each entity per each DB operation - so in summary it create a > significant pressure. See attach: > Suggestion: we can cache and reuse getReadMethod()/getWriteMethod() results > as a part of constructor logic of PojoFieldAccessor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7219) Reduce memory allocation in cassandra.persistence.PojoFieldAccessor
[ https://issues.apache.org/jira/browse/IGNITE-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov updated IGNITE-7219: Description: As a part of store logic of CassandraCacheStore if strategy="POJO" is used to store a value entity - org.apache.ignite.cache.store.cassandra.persistence.PojoFieldAccessor is used to work with POJO properties. Within the methods getValue/setValue getReadMethod()/getWriteMethod() are invoked each time. As a part of the methods invocation sun.reflect.misc.ReflectUtil#isNonPublicProxyClass is triggered which works with class names as strings and allocates a memory. It is a small allocation by itself but it is triggered very frequently - for each field for each entity per each DB operation - so in summary it create a significant pressure. See attach: [^ignitePojoFieldAccessorMemAlloc.png] Suggestion: we can cache and reuse getReadMethod()/getWriteMethod() results as a part of constructor logic of PojoFieldAccessor was: As a part of store logic of CassandraCacheStore if strategy="POJO" is used to store a value entity - org.apache.ignite.cache.store.cassandra.persistence.PojoFieldAccessor is used to work with POJO properties. Within the methods getValue/setValue getReadMethod()/getWriteMethod() are invoked each time. As a part of the methods invocation sun.reflect.misc.ReflectUtil#isNonPublicProxyClass is triggered which works with class names as strings and allocates a memory. It is a small allocation by itself but it is triggered very frequently - for each field for each entity per each DB operation - so in summary it create a significant pressure. See attach: Suggestion: we can cache and reuse getReadMethod()/getWriteMethod() results as a part of constructor logic of PojoFieldAccessor > Reduce memory allocation in cassandra.persistence.PojoFieldAccessor > --- > > Key: IGNITE-7219 > URL: https://issues.apache.org/jira/browse/IGNITE-7219 > Project: Ignite > Issue Type: Improvement > Components: cassandra >Affects Versions: 2.1, 2.2, 2.3 >Reporter: Dmitry Konstantinov > Attachments: ignitePojoFieldAccessorMemAlloc.png > > > As a part of store logic of CassandraCacheStore if strategy="POJO" is used to > store a value entity - > org.apache.ignite.cache.store.cassandra.persistence.PojoFieldAccessor is used > to work with POJO properties. Within the methods getValue/setValue > getReadMethod()/getWriteMethod() are invoked each time. As a part of the > methods invocation sun.reflect.misc.ReflectUtil#isNonPublicProxyClass is > triggered which works with class names as strings and allocates a memory. It > is a small allocation by itself but it is triggered very frequently - for > each field for each entity per each DB operation - so in summary it create a > significant pressure. See attach: [^ignitePojoFieldAccessorMemAlloc.png] > Suggestion: we can cache and reuse getReadMethod()/getWriteMethod() results > as a part of constructor logic of PojoFieldAccessor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7219) Reduce memory allocation in cassandra.persistence.PojoFieldAccessor
Dmitry Konstantinov created IGNITE-7219: --- Summary: Reduce memory allocation in cassandra.persistence.PojoFieldAccessor Key: IGNITE-7219 URL: https://issues.apache.org/jira/browse/IGNITE-7219 Project: Ignite Issue Type: Improvement Components: cassandra Affects Versions: 2.3, 2.2, 2.1 Reporter: Dmitry Konstantinov As a part of store logic of CassandraCacheStore if strategy="POJO" is used to store a value entity - org.apache.ignite.cache.store.cassandra.persistence.PojoFieldAccessor is used to work with POJO properties. Within the methods getValue/setValue getReadMethod()/getWriteMethod() are invoked each time. As a part of the methods invocation sun.reflect.misc.ReflectUtil#isNonPublicProxyClass is triggered which works with class names as strings and allocates a memory. It is a small allocation by itself but it is triggered very frequently - for each field for each entity per each DB operation - so in summary it create a significant pressure. See attach: Suggestion: we can cache and reuse getReadMethod()/getWriteMethod() results as a part of constructor logic of PojoFieldAccessor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
