[JBoss JIRA] (ISPN-9541) Module initialization is not thread-safe
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9541?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9541:
----------------------------------
Fix Version/s: 9.4.8.Final
(was: 9.4.7.Final)
> Module initialization is not thread-safe
> ----------------------------------------
>
> Key: ISPN-9541
> URL: https://issues.jboss.org/browse/ISPN-9541
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Server
> Affects Versions: 9.4.0.CR3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.4.8.Final
>
>
> In my ISPN-9127 fix I created a {{BasicComponentRegistry}} interface that represents a mostly-read-only collection of components. It has {{replaceComponent()}} method and a {{rewire()}} method for testing purposes, but it turns out modules were also relying on the ability to replace existing components in order to work.
> Replacing global components is normally safe during the {{ModuleLifecycle.cacheManagerStarting()}}, because none of the components are started yet, so when a component starts later we can still start its dependencies first. But because some modules starts some global components, e.g. by calling {{manager.getCache(name)}}, that assumption breaks.
> The {{infinispan-server-event-logger}} module is a bit more sneaky: it doesn't replace a component, instead it replaces the actual implementation of the event logger in the {{EventLogManager}} component. Events that happen before the module's {{cacheManagerStarting()}} or after {{cacheManagerStopping()}} will be silently dropped from the persistent event log.
> I am investigating making the module a factory of factories. Instead of having a monolitic {{cacheManagerStarting()}} method, it could define a set of components that it can create, and a set of components that should be started before the cache manager is "running". We probably need a way to depend on other modules as well, maybe reusing the {{@Inject}} and {{@ComponentName}} annotations.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 11 months
[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: 9.4.8.Final
(was: 9.4.7.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: 9.4.8.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)
5 years, 11 months
[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: 9.4.8.Final
(was: 9.4.7.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.Beta1, 9.4.8.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)
5 years, 11 months
[JBoss JIRA] (ISPN-9699) Cluster member owning no data
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9699?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9699:
----------------------------------
Fix Version/s: 9.4.8.Final
(was: 9.4.7.Final)
> Cluster member owning no data
> -----------------------------
>
> Key: ISPN-9699
> URL: https://issues.jboss.org/browse/ISPN-9699
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 9.4.1.Final
> Reporter: Thomas Segismont
> Assignee: Katia Aresti
> Priority: Major
> Fix For: 10.0.0.Beta1, 9.4.8.Final
>
>
> Currently, you can set {{capacity-factor}} to zero on a cache if you don't want a node to own any segment.
> If you want a node to own no data at all, you could set this property on all declared caches. But this wouldn't work for internal caches anyway (locks, counters).
> It would be nice to have a global switch.
> This would be useful when your app needs to be a cluster member for discovery/membership but is deployed mostly for processing. Indeed, when such nodes are added/removed from the cluster:
> * there would be no data loss
> * the cluster would be back in healthy state faster as no data would be moved around.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 11 months