Attaching ignite config. A failed code is a simple execution of hibernate
query. Here is bigger stacktrace:
Caused by: java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast
to [Ljava.io.Serializable;
at
org.hibernate.cache.internal.StandardQueryCache.get(StandardQueryCache.java:189)
at
Using Ignite 2.4 for Hibernate query cache and getting an exception:
Caused by: java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast
to [Ljava.io.Serializable;
at
org.hibernate.cache.internal.StandardQueryCache.get(StandardQueryCache.java:189)
at org.hibernate.loader.Loa
I see there is ticket registered for Hibernate 5.2 support:
https://issues.apache.org/jira/browse/IGNITE-5848
It is planned for 2.5 release. And release page says
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.5 the 2.5
version should come out on Apr 30, so it is only 2 weeks aw
I did try your suggestion. My code:
some = ignite.compute().affinityCall(CACHE_NAME,1, () ->
cacheBinary.get(1).field("some"));
And i get ClassNotFoundException for the object class which is put into
cache. peerClassLoadingEnabled is set to true.
--
View this message in context:
http://apache-
I did some testing on #invoke vs #get performance. It works as expected on
ATOMIC cache, however on TRANSACTIONAL cache #invoke has even lower
performance than pure #get. Is this to be expected?
simplified code:
some = cacheBinary.invoke(1,(mutableEntry, objects) ->
mutableEntry.getValue().field("
Yes, this seems to appear when we start working with large objects. Is there
a way to solve this? Does it affect cache put/get operations performance
directly ?
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Possible-starvation-in-striped-pool-message-tp15993p16
Hi,
sometimes we get this message in logs. What does it mean ?
Jul 26, 2017 11:43:25 AM org.apache.ignite.logger.java.JavaLogger warning
WARNING: >>> Possible starvation in striped pool.
Thread name: sys-stripe-3-#4%null%
Queue: []
Deadlock: false
Completed: 17
Thread [name="sys-s
Ok, so i digged deeper in the problem and will try to describe it
We want to cache persistent objects and need cache to function exactly like
it is a DB in respect of javax.persistence.Transient annotated fields. Some
business logic is doing deep object cloning and it needs those
javax.persistence.
We do not want to have dependency on Ignite in our domain subsystem so
implementing Binarylizable is not an option (at the moment). Reading
documentation i found Ignite honors readResolve and writeReplace methods
which should work for my case. However in Ignite documentation says
readResolve is def
Is there a simple way to ensure fields marked as @javax.persistence.Transient
are not being stored in cache?
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Do-not-store-javax-persistence-Transient-fields-tp15604.html
Sent from the Apache Ignite Users mailing lis
10 matches
Mail list logo