[jboss-jira] [JBoss JIRA] (AS7-3156) Cannot add clustered caches to a cache container started without a transport
Richard Achmatowicz (JIRA)
jira-events at lists.jboss.org
Wed Jan 11 18:42:22 EST 2012
[ https://issues.jboss.org/browse/AS7-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655361#comment-12655361 ]
Richard Achmatowicz edited comment on AS7-3156 at 1/11/12 6:40 PM:
-------------------------------------------------------------------
Just for the record, a short summary of how the mechanism works (my understanding) at the moment to include or not include a transport:
{noformat}
- CacheContainerAdd.performRuntime():
- creates TransportConfig and populates from <transport/> element in <cache-container/> element
- creates EmbeddedCacheManagerDependencies (mbean server, listener executor, eviction executor,
replication queue executor, transport configuration) and populates the injection points
- creates EmbeddedCacheManagerService(name, defaultCache, dependencies) and adds
an OPTIONAL dep on ChannelService(containerName) and starts ON_DEMAND
- creates ChannelService(containerName), adds an alias TransportService(name)
and installs it in mode NEVER
Thus, the EmbeddedCacheManagerService dependency on TransportService is OPTIONAL, and this its
presence or absence will not affect its start up.
Also, ChannelService (alias TransportService) is installed and configured, but not started
unless another service modifies its NEVER state back to ON_DEMAND.
- EmbeddedCacheManagerService.start():
- takes in EmbeddedCacheManagerDependencies populated
- uses Dependencies to configure GlobalConfigurationBuilder with injection poingts
- the EmbeddedCacheManager is only configured to use a transport (by configuring TransportConfigurationBuilder)
if ChannelService(name) is UP as a service when start() is called.
Thus, the EmbeddedCacheManager will only be ISPN-configured to use a transport if some service has set the
start mode of its ChannelService to ON_DEMAND *after* it is installed and *before* it starts.
- CacheAdd.performRuntime():
- populates ConfigurationBuilder instance with cache configuration from ModelNode
- creates CacheConfigurationService which holds ConfigurationBuilder and
CachConfigurationDependencies (container, tm, tsr)
- creates CacheService depending on CacheConfigurationService and
CacheDependencies (container, recoveryReg)
- if cache is clustered, adds dependency on TransportService(containerName)
and sets the TransportService(containerName) start mode to ON_DEMAND
- the CacheService is then installed
Thus, installing a clustered cache "activates" the ChannelService of its container, and so
triggers the EmbeddedCacheManagerService to configure a transport for its EmbededCacheManager
instance. But this only has effect if this happens before the EmbeddedCacheManagerService
is started (by HotRod or any other service which requests the start of a cache container
directly).
- CacheConfigurationService.start():
- add the injections from the tm and tsr to the ConfigurationBuilder
- build the Configuration
- define the configuration in the cache container
- CacheService.start():
- get the cache instance from the container
- add the XARecoveryRegistry for the container to the system wide recovery
registry
Thus, if a clustered cache is installed before the EmbeddedCacheManagerService is started,
the ChannelService start mode will have been set to ON_DEMAND, and both the EmbeddedCacheManagerService
and the CacheService will have a dependency on the ChannelService, which means that it will be started
before the EmbeddedCacheManagerService is started. When EmbeddedCacheManagerService is started, it will
find that the ChannelService is up, and it will then configure the EmbeddedCacheManager to use the available
transport.
This will not work if a component (e.g. perhaps HotRod) starts up a cache container and the creates a clustered
cache in that container.
{noformat}
was (Author: rachmato):
Just for the record, a short summary of how the mechanism works at the moment to include or not include a transport:
{noformat}
- CacheContainerAdd.performRuntime():
- creates TransportConfig and populates from <transport/> element in <cache-container/> element
- creates EmbeddedCacheManagerDependencies (mbean server, listener executor, eviction executor,
replication queue executor, transport configuration) and populates the injection points
- creates EmbeddedCacheManagerService(name, defaultCache, dependencies) and adds
an OPTIONAL dep on ChannelService(containerName) and starts ON_DEMAND
- creates ChannelService(containerName), adds an alias TransportService(name)
and installs it in mode NEVER
Thus, the EmbeddedCacheManagerService dependency on TransportService is OPTIONAL, and this its
presence or absence will not affect its start up.
Also, ChannelService (alias TransportService) is installed and configured, but not started
unless another service modifies its NEVER state back to ON_DEMAND.
- EmbeddedCacheManagerService.start():
- takes in EmbeddedCacheManagerDependencies populated
- uses Dependencies to configure GlobalConfigurationBuilder with injection poingts
- the EmbeddedCacheManager is only configured to use a transport (by configuring TransportConfigurationBuilder)
if ChannelService(name) is UP as a service when start() is called.
Thus, the EmbeddedCacheManager will only be ISPN-configured to use a transport if some service has set the
start mode of its ChannelService to ON_DEMAND *after* it is installed and *before* it starts.
- CacheAdd.performRuntime():
- populates ConfigurationBuilder instance with cache configuration from ModelNode
- creates CacheConfigurationService which holds ConfigurationBuilder and
CachConfigurationDependencies (container, tm, tsr)
- creates CacheService depending on CacheConfigurationService and
CacheDependencies (container, recoveryReg)
- if cache is clustered, adds dependency on TransportService(containerName)
and sets the TransportService(containerName) start mode to ON_DEMAND
- the CacheService is then installed
Thus, installing a clustered cache "activates" the ChannelService of its container, and so
triggers the EmbeddedCacheManagerService to configure a transport for its EmbededCacheManager
instance. But this only has effect if this happens before the EmbeddedCacheManagerService
is started (by HotRod or any other service which requests the start of a cache container
directly).
- CacheConfigurationService.start():
- add the injections from the tm and tsr to the ConfigurationBuilder
- build the Configuration
- define the configuration in the cache container
- CacheService.start():
- get the cache instance from the container
- add the XARecoveryRegistry for the container to the system wide recovery
registry
Thus, if a clustered cache is installed before the EmbeddedCacheManagerService is started,
the ChannelService start mode will have been set to ON_DEMAND, and both the EmbeddedCacheManagerService
and the CacheService will have a dependency on the ChannelService, which means that it will be started
before the EmbeddedCacheManagerService is started. When EmbeddedCacheManagerService is started, it will
find that the ChannelService is up, and it will then configure the EmbeddedCacheManager to use the available
transport.
This will not work if a component (e.g. perhaps HotRod) starts up a cache container and the creates a clustered
cache in that container.
{noformat}
> Cannot add clustered caches to a cache container started without a transport
> ----------------------------------------------------------------------------
>
> Key: AS7-3156
> URL: https://issues.jboss.org/browse/AS7-3156
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.0.CR1b
> Reporter: Tristan Tarrant
> Assignee: Paul Ferraro
> Fix For: 7.1.0.Final
>
>
> Because a transport is bound to a cache container only if there are clustered caches in the initial configuration, adding a clustered cache to such a cache container will result in Infinispan complaining about not having a transport.
> This can be solved by either always starting with a transport, or by making a distinction between local and clustered cache containers.
> Furthermore, making a clustered cache EAGER within the configuration XML file (they are LAZY by default), will trigger this problem even on startup:
> MSC00001: Failed to start service jboss.infinispan.sfsb.repl: org.jboss.msc.service.StartException in service jboss.infinispan.sfsb.repl: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1780) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
> Caused by: org.infinispan.config.ConfigurationException: Cache cannot use a clustered mode (REPL_ASYNC) mode and not define a transport!
> at org.infinispan.config.Configuration.assertValid(Configuration.java:1664)
> at org.infinispan.manager.DefaultCacheManager.wireCache(DefaultCacheManager.java:683)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:645)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:541)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:555)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:118)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:109)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:80)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
> ... 3 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list