[JBoss JIRA] (ISPN-6647) DecoratedCache.putForExternalRead method with Metadata ignores Metadata
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-6647?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-6647:
--------------------------------------
Fix Version/s: 8.2.4.Final
(was: 8.2.3.Final)
> DecoratedCache.putForExternalRead method with Metadata ignores Metadata
> -----------------------------------------------------------------------
>
> Key: ISPN-6647
> URL: https://issues.jboss.org/browse/ISPN-6647
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 8.2.2.Final
> Reporter: Karl von Randow
> Assignee: Karl von Randow
> Priority: Minor
> Fix For: 9.0.0.Alpha3, 8.2.4.Final
>
>
> The implementation of the {{putForExternalRead}} method ignores the {{Metadata}} parameter, instead of passing it on to the {{putForExternalRead}} method in the cache implementation. This is no doubt because the cache implementation previously didn't support {{Metadata}} for {{putForExternalRead}}.
> I will prepare a PR and attach it to this ticket shortly. It was a gargantuan effort to patch this up, as you'll see!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6614) [8.2.x] JCacheConfigurationPropertiesFileTest.testPropertiesConfiguration always fails
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-6614?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-6614:
--------------------------------------
Fix Version/s: 8.2.4.Final
(was: 8.2.3.Final)
> [8.2.x] JCacheConfigurationPropertiesFileTest.testPropertiesConfiguration always fails
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-6614
> URL: https://issues.jboss.org/browse/ISPN-6614
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.2.1.Final
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 8.2.4.Final
>
>
> Class {{SomeCustomConsistentHashV2}} appears to be missing on the 8.2.x branch:
> {noformat}
> org.infinispan.commons.CacheConfigurationException: Unable to instantiate class org.infinispan.client.hotrod.SomeCustomConsistentHashV2
> at org.infinispan.commons.util.Util.loadClass(Util.java:103)
> at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.consistentHashImpl(ConfigurationBuilder.java:171)
> at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.withProperties(ConfigurationBuilder.java:291)
> at org.infinispan.jcache.remote.JCacheManager.getConfigurationBuilder(JCacheManager.java:60)
> at org.infinispan.jcache.remote.JCacheManager.<init>(JCacheManager.java:38)
> at org.infinispan.jcache.remote.JCachingProvider.createCacheManager(JCachingProvider.java:37)
> at org.infinispan.jcache.AbstractJCachingProvider.getCacheManager(AbstractJCachingProvider.java:67)
> at org.infinispan.jcache.AbstractJCachingProvider.getCacheManager(AbstractJCachingProvider.java:80)
> at org.infinispan.jcache.remote.JCacheConfigurationPropertiesFileTest.testPropertiesConfiguration(JCacheConfigurationPropertiesFileTest.java:24)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6799) OOB thread pool fills with threads trying to send remote get responses
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6799?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6799:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> OOB thread pool fills with threads trying to send remote get responses
> ----------------------------------------------------------------------
>
> Key: ISPN-6799
> URL: https://issues.jboss.org/browse/ISPN-6799
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.Alpha3
>
>
> Note: This is a scenario that happens in the stress tests, with 4 nodes in dist mode, and 200+ threads per node doing only reads. I have not been able to reproduce it locally, even with a much lower OOB thread pool size and UFC.max_credits.
> We don't use the {{NO_FC}} flag, so threads sending both requests and responses can block in UFC/MFC. Remote gets are executed directly on the OOB thread, so when we run out of credits for one node, the OOB pool can quickly become full with threads waiting to send a remote get response to that node.
> While we can't send responses to that node, we won't send credits to it, either, as credits are only sent *after* the message has been processed by the application. That means OOB threads on all nodes will start blocking, trying to send remote get responses to us.
> This is made a worse by our staggering of remote gets. As remote get responses block, the stagger timeout kicks in and we send even more remote gets, making it even harder for the system to recover.
> UFC/MFC can send a {{CREDIT_REQUEST}} message to ask for more credits. The {{REPLENISH}} messages are handled on JGroups' internal thread pool, so they are not blocked. However, the CREDIT_REQUEST can be sent at most once every {{UFC.max_block_time}} ms, so they can't be relied on to provide enough credits. With the default settings, the throughput would be {{max_credits / max_block_time == 2mb / 0.5s == 4mb/s}}, which is really small compared to regular throughput.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months