[JBoss JIRA] (ISPN-9443) Fail when single region is accessed with multiple strategies
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9443?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9443:
----------------------------------
Fix Version/s: 10.0.0.Final
(was: 9.4.8.Final)
> Fail when single region is accessed with multiple strategies
> ------------------------------------------------------------
>
> Key: ISPN-9443
> URL: https://issues.jboss.org/browse/ISPN-9443
> Project: Infinispan
> Issue Type: Enhancement
> Components: Hibernate Cache
> Affects Versions: 9.3.1.Final
> Reporter: Radim Vansa
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> When we have two entities that share the same region but use different access strategies the Hibernate boot should fail. Right now there's an assertion in {{DomainDataRegionImpl.prepareFor*}} but this does not give much explanation and does not fail when assertions are disabled which leads to cryptic errors later on.
> Example:
> {code}
> @Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE, region = "item")
> public static class NonStrictReadWriteVersionedCacheableItem { ... }
> @Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region = "item")
> public static class ReadWriteVersionedCacheableItem { ... }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9957) InfinispanSubsystemXMLReader ignores configuration attribute on cache elements
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9957?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9957:
----------------------------------
Fix Version/s: 10.0.0.Final
(was: 9.4.8.Final)
> InfinispanSubsystemXMLReader ignores configuration attribute on cache elements
> ------------------------------------------------------------------------------
>
> Key: ISPN-9957
> URL: https://issues.jboss.org/browse/ISPN-9957
> Project: Infinispan
> Issue Type: Bug
> Components: Integration
> Affects Versions: 9.4.4.Final, 9.4.5.Final, 9.4.6.Final
> Reporter: Oliver Lüttin
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta2, 10.0.0.Final
>
> Attachments: example.cli
>
>
> InfinispanSubsystemXMLReader ignores configuration attribute on local-cache elements.
> The method
> {code:java}
> initPersistenceConfiguration(cacheConfigurationAddress, additionalConfigurationOperations);
> {code}
> , which is called from parseLocalCache,
> adds an entry to additionalConfigurationOperations.
> This causes the method
> {code:java}
> addCacheConfiguration(String cacheType, PathAddress containerAddress, Map<PathAddress, ModelNode> operations,
> boolean configurationOnly, ModelNode cacheConfiguration,
> Map<PathAddress, ModelNode> additionalConfigurationOperations, PathAddress cacheConfigurationAddress)
> {code}
> to call
> {code:java}
> addCacheConfiguration(String cacheType, PathAddress containerAddress, Map<PathAddress, ModelNode> operations,
> boolean configurationOnly, ModelNode cacheConfiguration,
> Map<PathAddress, ModelNode> additionalConfigurationOperations, PathAddress cacheConfigurationAddress)
> {code}
> without a configurationName.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9919) Partial updates in Hibernate 2L cache upon failure
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9919?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9919:
----------------------------------
Fix Version/s: (was: 9.4.8.Final)
> Partial updates in Hibernate 2L cache upon failure
> --------------------------------------------------
>
> Key: ISPN-9919
> URL: https://issues.jboss.org/browse/ISPN-9919
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 10.0.0.Alpha3, 9.4.6.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> This issue only affects 5.3:
> For a repl read-write, entity cache, if the failure happens on the async FutureUpdate call, that's fine because the Tombstone has already been sent and the cache won't return anything.
> If the failure happens when the Tombstone is sent, we seem to have a problem because it results in stale data in the node that failed to apply the Tombstone. The FutureUpdate that comes after the Tombstone cannot apply because it doesn't find the Tombstone.
> In 5.3, Sync logs any errors but does not propagate it, so it ends up with inconsistent state.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9917) JCachingProvider should not use weak ClassLoader references
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9917?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9917:
----------------------------------
Fix Version/s: 10.0.0.Final
(was: 9.4.8.Final)
> JCachingProvider should not use weak ClassLoader references
> -----------------------------------------------------------
>
> Key: ISPN-9917
> URL: https://issues.jboss.org/browse/ISPN-9917
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 10.0.0.Alpha3, 9.4.6.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> The idea behind {{WeakClassLoader}} is that we want users to be able to use {{Caching.getCachingProvider().getCacheManager()}} and not worry about closing the cache manager: instead Infinispan will close the manager when there are no more references to the provided {{ClassLoader}}.
> In order to close the manager automatically, {{AbstractJCachingProvider}} maintains a {{WeakHashMap}} of classloaders to managers, and if the cache manager had a strong reference to the classloader, the {{WeakHashMap}} entry would never be collected. However, this approach causes problems when a test creates a temporary {{ClassLoader}} instance and calls {{Caching.getCachingProvider().getCacheManager(tempClassLoader)}}, because the JVM is free to collect {{tempClassLoader}} immediately after it's used to create the {{WeakClassLoader}}. This can cause failures in the jcache tck with the IBM JDK:
> {noformat}
> [OK: 268, KO: 3, SKIP: 0] Test failed: CachingProviderTest.closeCacheManagerByURIAndClassLoader
> org.infinispan.commons.CacheConfigurationException: org.infinispan.commons.CacheException: Unable to construct a GlobalComponentRegistry!
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:344)
> at org.infinispan.jcache.embedded.JCacheManager.<init>(JCacheManager.java:70)
> at org.infinispan.jcache.embedded.JCachingProvider.createCacheManager(JCachingProvider.java:46)
> at org.infinispan.jcache.AbstractJCachingProvider.getCacheManager(AbstractJCachingProvider.java:67)
> at org.jsr107.tck.spi.CachingProviderTest.closeCacheManagerByURIAndClassLoader(CachingProviderTest.java:175)
> Caused by: org.infinispan.commons.CacheException: Unable to construct a GlobalComponentRegistry!
> at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:164)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:329)
> ... 39 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Unable to inject dependencies for component class org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl, path org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifier (a org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.performInjection(BasicComponentRegistryImpl.java:286)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.wireWrapper(BasicComponentRegistryImpl.java:176)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.registerComponent(BasicComponentRegistryImpl.java:360)
> at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:120)
> ... 40 more
> Caused by: org.infinispan.commons.CacheException: ClassLoader reference was garbage collected
> at org.infinispan.jcache.embedded.WeakClassLoader.requireClassLoader(WeakClassLoader.java:49)
> at org.infinispan.jcache.embedded.WeakClassLoader.findClass(WeakClassLoader.java:30)
> at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:925)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:870)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:853)
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:402)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:170)
> at org.infinispan.commons.util.Util.loadClass(Util.java:122)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.tryAutoInstantiation(BasicComponentRegistryImpl.java:249)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.findFactory(BasicComponentRegistryImpl.java:202)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.getComponent0(BasicComponentRegistryImpl.java:94)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.getDependency(BasicComponentRegistryImpl.java:327)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.setInjectionField(BasicComponentRegistryImpl.java:315)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.performInjection(BasicComponentRegistryImpl.java:276)
> ... 43 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9886) Use UFC_NB and MFC_NB in default embedded configurations
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9886?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9886:
----------------------------------
Fix Version/s: 10.0.0.Final
(was: 9.4.8.Final)
> Use UFC_NB and MFC_NB in default embedded configurations
> --------------------------------------------------------
>
> Key: ISPN-9886
> URL: https://issues.jboss.org/browse/ISPN-9886
> Project: Infinispan
> Issue Type: Task
> Components: Configuration
> Affects Versions: 10.0.0.Alpha2, 9.4.5.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Once properly configured, UFC_NB and MFC_NB are just as fast as their blocking siblings (ISPN-9828). We should use the non-blocking variants everywhere to simplify configuration.
> We should include UFC_NB even in the TCP configuration, to prevent async messages from overwhelming the receiver (JGRP-2301).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month