[JBoss JIRA] (ISPN-10957) Index/Query by key
by Tristan Tarrant (Jira)
Tristan Tarrant created ISPN-10957:
--------------------------------------
Summary: Index/Query by key
Key: ISPN-10957
URL: https://issues.jboss.org/browse/ISPN-10957
Project: Infinispan
Issue Type: Enhancement
Components: Embedded Querying
Reporter: Tristan Tarrant
Assignee: Nistor Adrian
We should offer the ability to query by key both in non-indexed mode as well as adding the key to the index using some special field name
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (ISPN-10924) JPA cache store (with async enabled) will log Exceptions in DEBUG for deleteBatch and is not able to remove entries from the store
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-10924?page=com.atlassian.jira.plugin... ]
Pedro Ruivo updated ISPN-10924:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> JPA cache store (with async enabled) will log Exceptions in DEBUG for deleteBatch and is not able to remove entries from the store
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-10924
> URL: https://issues.jboss.org/browse/ISPN-10924
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.4.16.Final, 10.0.1.Final, 10.1.0.Beta1
> Environment: Embedded mode with configured ASYNC JPA CacheStore
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 9.4.17.Final, 10.1.0.Beta1, 10.0.2.Final
>
>
> If the cache is configured with a persistence of JPAStore in async mode each modification will log a DEBUG message like followed
> Oct 22, 2019 1:51:08 PM org.infinispan.persistence.async.AsyncCacheWriter$AsyncStoreProcessor retryWork
> DEBUG: Failed to process async modifications
> org.infinispan.persistence.jpa.JpaStoreException: Exception caught in deleteBatch()
> at org.infinispan.persistence.jpa.JpaStore.deleteBatch(JpaStore.java:357)
> at org.infinispan.persistence.async.AsyncCacheWriter.applyModificationsSync(AsyncCacheWriter.java:234)
> at org.infinispan.persistence.async.AsyncCacheWriter$AsyncStoreProcessor.retryWork(AsyncCacheWriter.java:463)
> at org.infinispan.persistence.async.AsyncCacheWriter$AsyncStoreProcessor.run(AsyncCacheWriter.java:423)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: Parameter value [org.infinispan.persistence.async.AsyncCacheWriter$$Lambda$136/1340865907@4c7c351c] did not match expected type [java.lang.String (n/a)]
> at org.hibernate.query.spi.QueryParameterBindingValidator.validate(QueryParameterBindingValidator.java:54)
> at org.hibernate.query.spi.QueryParameterBindingValidator.validate(QueryParameterBindingValidator.java:27)
> at org.hibernate.query.internal.QueryParameterBindingImpl.validate(QueryParameterBindingImpl.java:90)
> at org.hibernate.query.internal.QueryParameterBindingImpl.setBindValue(QueryParameterBindingImpl.java:55)
> at org.hibernate.query.internal.AbstractProducedQuery.setParameter(AbstractProducedQuery.java:493)
> at org.hibernate.query.internal.AbstractProducedQuery.setParameter(AbstractProducedQuery.java:106)
> at org.hibernate.query.criteria.internal.compile.CriteriaCompiler$1$1.bind(CriteriaCompiler.java:119)
> at org.hibernate.query.criteria.internal.AbstractManipulationCriteriaQuery$1.buildCompiledQuery(AbstractManipulationCriteriaQuery.java:135)
> at org.hibernate.query.criteria.internal.compile.CriteriaCompiler.compile(CriteriaCompiler.java:149)
> at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:3724)
> at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:207)
> at org.infinispan.persistence.jpa.JpaStore.deleteBatch(JpaStore.java:341)
> ... 6 more
> If entries should be removed this is only done in memory but the store will fail ASYNC.
> Because of the async contract there is only a warning wihtout any exact hint:
> WARN: ISPN000053: Unable to process some async modifications after 10 retries!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (ISPN-10955) Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response)
by Diego Lovison (Jira)
[ https://issues.jboss.org/browse/ISPN-10955?page=com.atlassian.jira.plugin... ]
Diego Lovison reassigned ISPN-10955:
------------------------------------
Assignee: Diego Lovison
> Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response)
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-10955
> URL: https://issues.jboss.org/browse/ISPN-10955
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 10.0.1.Final
> Reporter: Diego Lovison
> Assignee: Diego Lovison
> Priority: Major
>
> 1 % of the total allocation (214 MiB) is caused by conversion from primitive types to object types.
> The most common object type that primitives are converted into is 'java.lang.Long', which causes 214 MiB to be allocated. The most common call site is 'org.infinispan.remoting.transport.impl.RequestRepository.addResponse(long, Address, Response):46'.
> Conversion from primitives to the corresponding object types can either be done explicitly, or be caused by autoboxing. If a considerable amount of the total allocation is caused by such conversions, consider changing the application source code to avoid this behavior. Look at the allocation stack traces to see which parts of the code to change. This rule finds the calls to the valueOf method for any of the eight object types that have primitive counterparts.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (ISPN-10955) Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response)
by Diego Lovison (Jira)
Diego Lovison created ISPN-10955:
------------------------------------
Summary: Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response)
Key: ISPN-10955
URL: https://issues.jboss.org/browse/ISPN-10955
Project: Infinispan
Issue Type: Enhancement
Affects Versions: 10.0.1.Final
Reporter: Diego Lovison
1 % of the total allocation (214 MiB) is caused by conversion from primitive types to object types.
The most common object type that primitives are converted into is 'java.lang.Long', which causes 214 MiB to be allocated. The most common call site is 'org.infinispan.remoting.transport.impl.RequestRepository.addResponse(long, Address, Response):46'.
Conversion from primitives to the corresponding object types can either be done explicitly, or be caused by autoboxing. If a considerable amount of the total allocation is caused by such conversions, consider changing the application source code to avoid this behavior. Look at the allocation stack traces to see which parts of the code to change. This rule finds the calls to the valueOf method for any of the eight object types that have primitive counterparts.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (ISPN-10955) Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response)
by Diego Lovison (Jira)
[ https://issues.jboss.org/browse/ISPN-10955?page=com.atlassian.jira.plugin... ]
Work on ISPN-10955 started by Diego Lovison.
--------------------------------------------
> Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response)
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-10955
> URL: https://issues.jboss.org/browse/ISPN-10955
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 10.0.1.Final
> Reporter: Diego Lovison
> Assignee: Diego Lovison
> Priority: Major
>
> 1 % of the total allocation (214 MiB) is caused by conversion from primitive types to object types.
> The most common object type that primitives are converted into is 'java.lang.Long', which causes 214 MiB to be allocated. The most common call site is 'org.infinispan.remoting.transport.impl.RequestRepository.addResponse(long, Address, Response):46'.
> Conversion from primitives to the corresponding object types can either be done explicitly, or be caused by autoboxing. If a considerable amount of the total allocation is caused by such conversions, consider changing the application source code to avoid this behavior. Look at the allocation stack traces to see which parts of the code to change. This rule finds the calls to the valueOf method for any of the eight object types that have primitive counterparts.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (ISPN-10955) Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response)
by Diego Lovison (Jira)
[ https://issues.jboss.org/browse/ISPN-10955?page=com.atlassian.jira.plugin... ]
Diego Lovison updated ISPN-10955:
---------------------------------
Status: Open (was: New)
> Reduce Primitive To Object Conversion - RequestRepository.addResponse(long, Address, Response)
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-10955
> URL: https://issues.jboss.org/browse/ISPN-10955
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 10.0.1.Final
> Reporter: Diego Lovison
> Priority: Major
>
> 1 % of the total allocation (214 MiB) is caused by conversion from primitive types to object types.
> The most common object type that primitives are converted into is 'java.lang.Long', which causes 214 MiB to be allocated. The most common call site is 'org.infinispan.remoting.transport.impl.RequestRepository.addResponse(long, Address, Response):46'.
> Conversion from primitives to the corresponding object types can either be done explicitly, or be caused by autoboxing. If a considerable amount of the total allocation is caused by such conversions, consider changing the application source code to avoid this behavior. Look at the allocation stack traces to see which parts of the code to change. This rule finds the calls to the valueOf method for any of the eight object types that have primitive counterparts.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month