Re: ClassCastException in Hibernate QueryCache
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 org.hibernate.loader.Loader.getResultFromQueryCache(Loader.java:2587)
at org.hibernate.loader.Loader.listUsingQueryCache(Loader.java:2495)
at org.hibernate.loader.Loader.list(Loader.java:2467)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:502)
at
org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:384)
at
org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216)
at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1490)
at
org.hibernate.query.internal.AbstractProducedQuery.doList(AbstractProducedQuery.java:1445)
at
org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1414)
at org.hibernate.query.Query.getResultList(Query.java:146)
at
com.aaa.bbb.base.dataload.dao.GenericJpaQueryDAO.executeGenericQuery(GenericJpaQueryDAO.java:55)
For now I created 'dirty' workaround to continue with my testing:
org.apache.ignite.cache.hibernate.HibernateQueryResultsRegion#get
@Override
public Object get(SharedSessionContractImplementor
sharedSessionContractImplementor, Object key) throws CacheException {
Object result = super.get(sharedSessionContractImplementor, key);
if (result instanceof List) {
List list = (List) result;
if (list.size() > 1) {
for (int i = 1; i < list.size(); i++) {//first element in
list is id, skip it
Object row = list.get(i);
if (row != null && row.getClass().isArray())
{//convert Object[] to Serializable[]
Object[] rowArr = (Object[]) row;
list.set(i, Arrays.copyOf(rowArr, rowArr.length,
Serializable[].class));
}
}
}
}
return result;
}
On Mon, Jun 25, 2018 at 9:41 PM aealexsandrov
wrote:
> Hi,
>
> Could you please provide some more details: cache configuration, an example
> of code that was failed and logs?
>
> BR,
> Andrei
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
127.0.0.1
ClassCastException in Hibernate QueryCache
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.Loader.getResultFromQueryCache(Loader.java:2587) The problematic line in Hibernate reads: TypeHelper.beforeAssemble( (Serializable[]) cacheable.get( i ), returnTypes, session ); it receives Object[] from the cache and tries to cast to Serializable[] which obviously fails. It seems to be a generic place and should not work for anyone, but somehow it is working? I did check put operation and it actually puts Serializable[] into the cache. Any pointers on how to resolve the issue? Cache config used is very simple taken from examples. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hibernate 5.2 support
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 away, however, there is no activity on Hibernate integration ticket. So should we expect Hibernate 5.2 support in upcoming Apr 30 release? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Possible starvation in striped pool. message
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-ignite-users.70518.x6.nabble.com/Possible-starvation-in-striped-pool-message-tp15993p16482.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Possible starvation in striped pool. message
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-tp15993p16025.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Possible starvation in striped pool. message
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-stripe-3-#4%null%", id=36, state=RUNNABLE, blockCnt=0, waitCnt=18] at o.a.i.i.MarshallerContextImpl.getClassName(MarshallerContextImpl.java:348) at o.a.i.i.MarshallerContextImpl.getClass(MarshallerContextImpl.java:335) at o.a.i.i.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:692) at o.a.i.i.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1745) at o.a.i.i.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1704) at o.a.i.i.binary.BinaryUtils.doReadObject(BinaryUtils.java:1728) at o.a.i.i.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2085) at o.a.i.i.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2016) at o.a.i.i.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1904) at o.a.i.i.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1704) at o.a.i.i.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1964) at o.a.i.i.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:674) at o.a.i.i.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164) at o.a.i.i.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843) at o.a.i.i.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1752) at o.a.i.i.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1704) at o.a.i.i.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1964) at o.a.i.i.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:674) at o.a.i.i.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164) at o.a.i.i.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843) at o.a.i.i.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1752) at o.a.i.i.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1704) at o.a.i.i.binary.BinaryUtils.doReadObject(BinaryUtils.java:1728) at o.a.i.i.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2085) at o.a.i.i.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2016) at o.a.i.i.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1904) at o.a.i.i.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1704) at o.a.i.i.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1964) at o.a.i.i.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:674) at o.a.i.i.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164) at o.a.i.i.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843) at o.a.i.i.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1752) at o.a.i.i.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1704) at o.a.i.i.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1964) at o.a.i.i.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:674) at o.a.i.i.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164) at o.a.i.i.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843) at o.a.i.i.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1752) at o.a.i.i.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1704) at o.a.i.i.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1964) at o.a.i.i.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:674) at o.a.i.i.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164) at o.a.i.i.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843) at o.a.i.i.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1752) at o.a.i.i.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1704) at o.a.i.i.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1964) at o.a.i.i.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:674) at o.a.i.i.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164) at o.a.i.i.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843) at o.a.i.i.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1752) at o.a.i.i.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1704) at o.a.i.i.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794) at o.a.i.i.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142) at
Re: Do not store @javax.persistence.Transient fields
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 defined as follows: ANY-ACCESS-MODIFIER Object readResolve(). and java 8 doc says ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException; the difference is in throws declaration. Does it makes difference to Ignite is there a throw clause or not? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Do-not-store-javax-persistence-Transient-fields-tp15604p15681.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Do not store @javax.persistence.Transient fields
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 list archive at Nabble.com.
