[JBoss JIRA] (ISPN-10630) Cluster wide cache stats do not work with exception based eviction
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10630?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10630:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Cluster wide cache stats do not work with exception based eviction
> ------------------------------------------------------------------
>
> Key: ISPN-10630
> URL: https://issues.jboss.org/browse/ISPN-10630
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.4.16.Final
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.CR3, 9.4.17.Final
>
>
> Upon configuring exception eviction type then the MBean that provide cluster wide cache stats operation does not work.
> ~~~
> <distributed-cache name="abc" mode="SYNC" owners="2">
> <memory>
> <off-heap size="1160773632" eviction="MEMORY" strategy="EXCEPTION" address-count="1048576"/>
> </memory>
> <partition-handling when-split="DENY_READ_WRITES"/>
> <transaction mode="NON_DURABLE_XA"/>
> <state-transfer enabled="true"/>
> </distributed-cache>
> ~~~
> Below the error in the server.log.
> ~~~
> ERROR [org.infinispan.stats.impl.ClusterCacheStatsImpl] (Thread-72) Could not execute cluster wide cache stats operation : java.util.concurrent.CompletionException: org.infinispan.commons.CacheException: java.lang.UnsupportedOperationException
> at java.base/java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:412)
> at java.base/java.util.concurrent.CompletableFuture.join(CompletableFuture.java:2044)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.stats.impl.ClusterCacheStatsImpl.updateStats(ClusterCacheStatsImpl.java:116)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.stats.impl.AbstractClusterStats.fetchClusterWideStatsIfNeeded(AbstractClusterStats.java:114)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.stats.impl.AbstractClusterStats.getStat(AbstractClusterStats.java:207)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.stats.impl.AbstractClusterStats.getStatAsLong(AbstractClusterStats.java:198)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.stats.impl.ClusterCacheStatsImpl.getPassivations(ClusterCacheStatsImpl.java:397)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.jmx.ResourceDMBean$InvokableSetterBasedMBeanAttributeInfo.invoke(ResourceDMBean.java:400)
> ...
> ...
> Caused by: org.infinispan.commons.CacheException: java.lang.UnsupportedOperationException
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.stats.impl.ClusterCacheStatsImpl.lambda$updateStats$0(ClusterCacheStatsImpl.java:105)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.manager.impl.AllClusterExecutor.lambda$submitConsumer$6(AllClusterExecutor.java:193)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.manager.impl.AbstractClusterExecutor.consumeResponse(AbstractClusterExecutor.java:64)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.manager.impl.AllClusterExecutor.lambda$submitConsumer$7(AllClusterExecutor.java:192)
> at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
> at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:67)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.remoting.transport.impl.SingleTargetRequest.receiveResponse(SingleTargetRequest.java:57)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001//org.infinispan.remoting.transport.impl.SingleTargetRequest.onResponse(SingleTargetRequest.java:35)
> at org.infinispan.core:jdg-7.3@9.4.15.Final-redhat-00001/
> ~~~
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10699) Add Transcoder name to log statements to aid debugging
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-10699?page=com.atlassian.jira.plugin... ]
Will Burns updated ISPN-10699:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Add Transcoder name to log statements to aid debugging
> ------------------------------------------------------
>
> Key: ISPN-10699
> URL: https://issues.jboss.org/browse/ISPN-10699
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 10.0.0.CR2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.CR3
>
>
> Currently the error message returned to the client when a transcoding exception occurs is not very detailed as the stack trace is where the `HotRodClientException` is thrown and the server error message does not detail the transcoder that encountered the issue.
> We should include the name of the transcoder in the server exception to aid debugging.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10618) If Expiration is enabled the cretionDate is modified to the current server start date if preload is enabled for a persistence
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-10618?page=com.atlassian.jira.plugin... ]
Pedro Zapata Fernandez reassigned ISPN-10618:
---------------------------------------------
Assignee: Will Burns
> If Expiration is enabled the cretionDate is modified to the current server start date if preload is enabled for a persistence
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-10618
> URL: https://issues.jboss.org/browse/ISPN-10618
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 10.0.0.CR2
> Environment: Cache configuration with preload
> <local-cache name="default">
> <persistence>
> <file-store shared="false" preload="true" fetch-state="true"/>
> </persistence>
> </local-cache>
> Reporter: Wolf-Dieter Fink
> Assignee: Will Burns
> Priority: Blocker
>
> If a cache store entries with expiration the MetaData creationTime is used to calculate the expiration.
> This works correct if the server is not restarted or preload=false for the store.
> If preload is enabled and the server preload the date the creationTime is set to the current server start time.
> In this case all expiration for existing entries is not working correctly
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10685) File stores locations do not respect the Global State persistent location
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10685?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10685:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> File stores locations do not respect the Global State persistent location
> --------------------------------------------------------------------------
>
> Key: ISPN-10685
> URL: https://issues.jboss.org/browse/ISPN-10685
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 10.0.0.CR2
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.0.0.CR3
>
>
> The file stores (Single, SoftIndex, RocksDB) should create files relative to the GlobalState persistent location unless specified.
> Additionally each of the file stores differs in the filesystem layout:
> * The SoftIndex store does not use the name of the cache in the file path, preventing sharing of directories between multiple caches.
> * The RocksDB store allows configuring data and expired locations to point to the same directory, which will result in data corruption
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months