[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] [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] [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)
