[JBoss JIRA] (ISPN-12230) Deprecate client keySizeEstimate and valueSizeEstimate attributes
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-12230?page=com.atlassian.jira.plugi... ]
Katia Aresti closed ISPN-12230.
-------------------------------
> Deprecate client keySizeEstimate and valueSizeEstimate attributes
> -----------------------------------------------------------------
>
> Key: ISPN-12230
> URL: https://issues.redhat.com/browse/ISPN-12230
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Hot Rod
> Affects Versions: 11.0.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.0.0.Dev03
>
>
> The core configuration has long ago removed the {{keySizeEstimate}} and {{valueSizeEstimate}} attributes, using instead a {{BufferSizePredictor}} to dynamically estimate the size of the next key/value. {{ProtostreamMarshaller}} goes even further and ignores the estimate.
> We should stop using {{keySizeEstimate}} and {{valueSizeEstimate}} on the client as well, and instead use a fixed buffer size ({{ProtostreamMarshaller}} uses 512).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (ISPN-12263) RemoteCacheMetricBinderTest fails
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-12263?page=com.atlassian.jira.plugi... ]
Katia Aresti closed ISPN-12263.
-------------------------------
> RemoteCacheMetricBinderTest fails
> ---------------------------------
>
> Key: ISPN-12263
> URL: https://issues.redhat.com/browse/ISPN-12263
> Project: Infinispan
> Issue Type: Bug
> Components: Spring Integration
> Affects Versions: 12.0.0.Dev02
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 12.0.0.Dev03
>
>
> {{RemoteCacheMetricBinderTest}} currently doesn't run at all, because of ISPN-12255. After fixing ISPN-12255, it still doesn't pass, but with Surefire the setup failure is reported just as
> {noformat}
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 70.094 s - in test.org.infinispan.spring.starter.remote.actuator.RemoteCacheMetricBinderTest
> {noformat}
> When run in the IDE, multiple problems become apparent:
> * {{InfinispanServerExtension.beforeTestExecution()}} runs too late, so the {{TestClient}} is not available in {{InfinispanCacheMetricBinderTest.binder()}}
> * {{InfinispanServerExtension.afterTestExecution()}} runs too early, so the {{TestClient}} is no longer available in {{InfinispanCacheMetricBinderTest.cleanCache()}}
> * The {{mycache}} cache is not defined on the server
> * The {{RemoteCacheManager}} does not have statistics enabled
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (ISPN-12231) Cache fails to start with IllegalStateException: We already had a newer topology
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-12231?page=com.atlassian.jira.plugi... ]
Katia Aresti closed ISPN-12231.
-------------------------------
> Cache fails to start with IllegalStateException: We already had a newer topology
> --------------------------------------------------------------------------------
>
> Key: ISPN-12231
> URL: https://issues.redhat.com/browse/ISPN-12231
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 11.0.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.0.0.Dev03
>
>
> {{LocalTopologyManagerImpl.join()}} registers the {{LocalCacheStatus}} outside the {{ActionSequencer}} call, allowing another topology update command to install a topology before the join response is processed.
> This is very unlikely to happen outside of tests, but I was able to reproduce it reliably when starting lots of nodes in parallel.
> {noformat}
> org.infinispan.commons.CacheConfigurationException: Error starting component org.infinispan.statetransfer.StateTransferManager
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:560)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.access$700(BasicComponentRegistryImpl.java:30)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:775)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:341)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:237)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:210)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:1008)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:512)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:697)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:643)
> at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:532)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:510)
> at org.infinispan.stress.LargeClusterStressTest.lambda$testLargeClusterStart$0(LargeClusterStressTest.java:92)
> at java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> at java.base/java.lang.Thread.run(Thread.java:832)
> Caused by: java.util.concurrent.CompletionException: java.lang.IllegalStateException: We already had a newer topology by the time we received the join response
> at org.infinispan.util.concurrent.CompletionStages.join(CompletionStages.java:82)
> at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:133)
> at org.infinispan.statetransfer.CorePackageImpl$1.start(CorePackageImpl.java:48)
> at org.infinispan.statetransfer.CorePackageImpl$1.start(CorePackageImpl.java:27)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.invokeStart(BasicComponentRegistryImpl.java:592)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.doStartWrapper(BasicComponentRegistryImpl.java:583)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:552)
> ... 20 more
> Caused by: java.lang.IllegalStateException: We already had a newer topology by the time we received the join response
> at org.infinispan.topology.LocalTopologyManagerImpl.lambda$handleJoinResponse$5(LocalTopologyManagerImpl.java:227)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1183)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2299)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:143)
> at org.infinispan.topology.LocalTopologyManagerImpl.handleJoinResponse(LocalTopologyManagerImpl.java:225)
> at org.infinispan.topology.LocalTopologyManagerImpl.lambda$join$0(LocalTopologyManagerImpl.java:161)
> at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1146)
> at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2137)
> at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:67)
> at org.infinispan.remoting.transport.impl.SingleTargetRequest.onResponse(SingleTargetRequest.java:45)
> at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:52)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1405)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1308)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (ISPN-12173) Explanation for eviction leads confusion
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-12173?page=com.atlassian.jira.plugi... ]
Katia Aresti closed ISPN-12173.
-------------------------------
> Explanation for eviction leads confusion
> ----------------------------------------
>
> Key: ISPN-12173
> URL: https://issues.redhat.com/browse/ISPN-12173
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation
> Affects Versions: 12.0.0.Dev01
> Reporter: Wolf-Dieter Fink
> Assignee: Donald Naro
> Priority: Major
> Labels: eviction
> Fix For: 12.0.0.Dev03
>
>
> chapter 8.2. Eviction ([https://infinispan.org/docs/dev/titles/configuring/configuring.html#evict...]
> Starts with a sentence that leads confusion
> "Eviction lets you control the size of the data container by removing cache entries to make space when adding new entries."
>
> The wording "removing cache entries to make space" sound like the entry will be removed like a remove('key') invocation or expiration.
> But this is not the case. It should be clear that the entry is evicted from memory on exactly this instance, no other instance is affected.
> To prevent from not deterministic behaviour if different instances within the cluster are used for request eviction should not be configured without persistence (as mentioned) but the initial statement should be more precise
>
> Proposal
> Eviction lets you contol the size of data container in this local instance by dropping (evict) one choosen entry from memory only without further effects.
> This is a local action for this node and does not affect any other node within the cluster
> To prevent from inconsistency eviction should not be used without a configured persistence
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months