[JBoss JIRA] (ISPN-2709) Lib dir in distribution archive does not contain the proper versions for some dependencies
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2709?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-2709:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> Lib dir in distribution archive does not contain the proper versions for some dependencies
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-2709
> URL: https://issues.jboss.org/browse/ISPN-2709
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.CR1
> Reporter: Adrian Nistor
> Assignee: Tristan Tarrant
> Fix For: 6.0.0.Final
>
> Attachments: actual.txt, should_be.txt
>
>
> Not all the jars referenced by runtime-classpath.txt files of modules are actually present in the lib dir. In some cases the jar is present but not the needed version. Some of the jars are there but are not actually used.
> It all happens because the set of dependencies for runtime-classpath.txt is computed for each individual module while the lib dir in the distro is created by assembly plugin after 'merging' the dependencies of all modules which means that only the highest version will be included. Also, maven dependency plugin is known to miss some dependencies.
> To avoid the version problem we could define globally a single version for each of these dependencies in parent pom dependencyManagement and also explicitly add the dependency in the respective modules.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-2729) [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2729?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-2729:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> [FineGrainedAtomicMap] Class Cast Exception in Clustered + Repeatable Read + Write Skew
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-2729
> URL: https://issues.jboss.org/browse/ISPN-2729
> Project: Infinispan
> Issue Type: Bug
> Components: Core API, Fine-grained API, Locking and Concurrency
> Environment: Mac OSx 10.5, Java 1.6 sun-jdk, maven 3.0.4
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: atomic_map, clustered, write-skew
> Fix For: 6.0.0.Final
>
>
> Test case available in here [1]
> When a transaction commits, the write skew check performs the validation by casting the cache entry to a ClusteredRepeatableReadEntry. However, the entry is a DeltaAwareCacheEntry.
> This happens when you have operations over a map inside a transaction.
> The tests failing are:
> WriteSkewFineGrainedAtomicMapAPITest.testSizeOnCache()
> WriteSkewFineGrainedAtomicMapAPITest.testCreateMapInTx()
> [1]https://github.com/pruivo/infinispan/commits/t_atomic_map_issue
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-2735) The global component registry sometimes fails to start components injected on the fly
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2735?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-2735:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> The global component registry sometimes fails to start components injected on the fly
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2735
> URL: https://issues.jboss.org/browse/ISPN-2735
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 6.0.0.Final
>
>
> If a global component is used by an incoming command, it could be created before the component registry is in the "running" state, yet after it has started invoking the components' start methods.
> If this happens, the component's start method(s) will never be invoked - neither "inline", in ACR.registerComponentInternal, nor in the regular startup procedure (ACR.internalStart).
> Specifically, the problem ocurred with LocalTopologyManager, which is injected in incoming CacheTopologyControlCommands. Since these commands are broadcasted to the entire cluster, a node can receive them before it had finished starting its global component registry.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-2727) Transactional put failed after master node with enabled InfinispanIndexManager is killed
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2727?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-2727:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> Transactional put failed after master node with enabled InfinispanIndexManager is killed
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-2727
> URL: https://issues.jboss.org/browse/ISPN-2727
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Fix For: 6.0.0.Final
>
> Attachments: MultiNodeDistributedTest.java, MultiNodeLocalTest.java, MultiNodeLocalTxTest.java, MultiNodeReplicatedTest.java, MultiNodeReplicatedTxTest.java
>
>
> I've added new test, which uses the following Infinispan configuration: REPL_SYNC clustering mode, with transaction enabled, as well as enabled indexing with InfinispanIndexManager.
> The test adds several nodes with the described configuration, adds entries to different nodes, and checks that the query for the entries returns the same result for all nodes.
> Then master node is killed, and then again new data is inserted and checked on all nodes. (Similiar test to https://github.com/infinispan/infinispan/blob/master/query/src/test/java/... but with enabled transaction).
> When the test tries to insert new entry to one of the caches, after the master node kill, the following exception appears:
> {code}
> testIndexingWorkDistribution(org.infinispan.query.distributed.MultiNodeReplicatedTxTest) Time elapsed: 1.656 sec <<< FAILURE!
> javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1177)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
> at org.infinispan.query.distributed.MultiNodeDistributedTest.storeOn(MultiNodeDistributedTest.java:78)
> at org.infinispan.query.distributed.MultiNodeDistributedTest.testIndexingWorkDistribution(MultiNodeDistributedTest.java:102)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.infinispan.CacheException: Could not prepare.
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> ... 24 more
> Caused by: javax.transaction.xa.XAException
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:161)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:123)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
> ... 29 more
> {code}
> You can find the test attached. The test which fails is MultiNodeReplicatedTxTest.java . The rest are the tests which are the parents and a bit modified compared to the version in infinispan repo.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-2799) Deprecated OverrideDefault annotation is the only way to prevent construction of the default CacheManager
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2799?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-2799:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> Deprecated OverrideDefault annotation is the only way to prevent construction of the default CacheManager
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2799
> URL: https://issues.jboss.org/browse/ISPN-2799
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.2.0.Final
> Reporter: Emond Papegaaij
> Assignee: Pete Muir
> Fix For: 6.0.0.Final
>
>
> The signature of DefaultEmbeddedCacheManagerProducer.getDefaultEmbeddedCacheManager, with @OverrideDefault, causes the providedDefaultEmbeddedCacheManager to only be satisfied when your producer method is annotated with @OverrideDefault.
> For example:
> {code}
> @Produces
> @ApplicationScoped
> @Default
> @OverrideDefault
> public EmbeddedCacheManager defaultEmbeddedCacheManager() {
> return new DefaultCacheManager(
> new GlobalConfigurationBuilder()
> .globalJmxStatistics().allowDuplicateDomains(true)
> .cacheManagerName("CDICacheManager").enable().build(),
> new ConfigurationBuilder().jmxStatistics().disable()
> .eviction().strategy(EvictionStrategy.LRU)
> .maxEntries(10000).build());
> }
> {code}
> If I remove @OverrideDefault, my CacheManager is still used as the default CacheManager, but the CacheManager from DefaultEmbeddedCacheManagerProducer is also instantiated. This happens because DefaultCacheResolver iterates over all EmbeddedCacheManagers to check if one of them contains a specific cache.
> The default CacheManager is giving me problems because it conflicts with another CacheManager (probably from JBoss AS) in JMX.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-2793) REST Server WAR default config
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2793?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-2793:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> REST Server WAR default config
> ------------------------------
>
> Key: ISPN-2793
> URL: https://issues.jboss.org/browse/ISPN-2793
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 5.2.0.Final
> Reporter: Michal Linhard
> Assignee: Tristan Tarrant
> Priority: Minor
> Fix For: 6.0.0.Final
>
>
> REST Server war file comes with this web.xml
> {code}
> <!-- Specify your cache configuration file -->
> <init-param>
> <param-name>infinispan.config</param-name>
> <param-value>config-samples/sample.xml</param-value>
> </init-param>
> {code}
> that depend's on certain file to exist, otherwise the deployment will throw an exception:
> {code}
> 09:20:14,148 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/infinispan]] (MSC service thread 1-2) Servlet /infinispan threw load() exception: java.io.FileNotFoundException: config-samples/sample.xml (No such file or directory)
> at java.io.FileInputStream.open(Native Method) [rt.jar:1.6.0_37]
> at java.io.FileInputStream.<init>(FileInputStream.java:120) [rt.jar:1.6.0_37]
> at java.io.FileInputStream.<init>(FileInputStream.java:79) [rt.jar:1.6.0_37]
> at org.infinispan.util.AbstractFileLookup.lookupFileStrict(AbstractFileLookup.java:83) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:326) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:313) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.rest.StartupListener.init(StartupListener.scala:59) [classes:]
> at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:89) [jboss-as-web-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}
> What about commenting this out, so that default config is used.
> I'll do the pull if you agree..
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ISPN-2752) IllegalStateException on shutdown
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2752?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-2752:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> IllegalStateException on shutdown
> ---------------------------------
>
> Key: ISPN-2752
> URL: https://issues.jboss.org/browse/ISPN-2752
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.CR2
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 6.0.0.Final
>
>
> This happens on graceful shutdown of 8 or 6 nodes of 5.2.0.CR2:
> {code}
> 07:17:45,892 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] ISPN000196: Failed to recover cluster state after the current node became the coordinator: java.util.concurrent.ExecutionException: org.infinispan.CacheException: Remote (node0005/default) failed unexpectedly
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask.get(FutureTask.java:91) [rt.jar:1.6.0_33]
> at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:567) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:432) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:231) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:597) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_33]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_33]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_33]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_33]
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> Caused by: org.infinispan.CacheException: Remote (node0005/default) failed unexpectedly
> at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:96) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:541) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:549) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:546) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-2.jar:2.0.0.GA-redhat-2]
> Caused by: java.lang.IllegalStateException: transport was closed
> at org.jgroups.blocks.GroupRequest.transportClosed(GroupRequest.java:273) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.stop(RequestCorrelator.java:269) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher.stop(MessageDispatcher.java:152) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher.channelDisconnected(MessageDispatcher.java:455) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.Channel.notifyChannelDisconnected(Channel.java:507) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.JChannel.disconnect(JChannel.java:363) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.stop(JGroupsTransport.java:258) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_33]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_33]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_33]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_33]
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:883) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:690) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:568) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.GlobalComponentRegistry.stop(GlobalComponentRegistry.java:260) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:742) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.manager.AbstractDelegatingEmbeddedCacheManager.stop(AbstractDelegatingEmbeddedCacheManager.java:179) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.jboss.as.clustering.infinispan.subsystem.EmbeddedCacheManagerService.stop(EmbeddedCacheManagerService.java:76) [jboss-datagrid-infinispan-6.1.0.ER9-redhat-1.jar:6.1.0.ER9-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA-redhat-2.jar:1.0.2.GA-redhat-2]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA-redhat-2.jar:1.0.2.GA-redhat-2]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months