[JBoss JIRA] (ISPN-8631) GetAllCacheNotFoundResponseTest.createBeforeClass fails
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8631?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8631:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> GetAllCacheNotFoundResponseTest.createBeforeClass fails
> -------------------------------------------------------
>
> Key: ISPN-8631
> URL: https://issues.jboss.org/browse/ISPN-8631
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.2.0.Beta2
>
>
> With a controlled CHF, a segment can have fewer than {{numOwners}} owners while the cluster is smaller than expected. That means {{MultipleCacheManagersTest.createClusteredCaches()}} should call {{waitForClusterToForm()}} only after starting all the nodes, not in each iteration, or it will time out waiting for all segments to have {{numOwners}} owners.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8608) GetAllCacheNotFoundResponseTest fails
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8608?page=com.atlassian.jira.plugin.... ]
Dan Berindei closed ISPN-8608.
------------------------------
Resolution: Duplicate Issue
> GetAllCacheNotFoundResponseTest fails
> -------------------------------------
>
> Key: ISPN-8608
> URL: https://issues.jboss.org/browse/ISPN-8608
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Dan Berindei
>
> {noformat}
> Error Message
> Timed out waiting for rebalancing to complete on node
> GetAllCacheNotFoundResponseTest-NodeA-12369, current topology is
> CacheTopology{id=5, rebalanceId=2, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=3, owners =
> (2)[GetAllCacheNotFoundResponseTest-NodeA-12369: 3+0,
> GetAllCacheNotFoundResponseTest-NodeB-43554: 0+1]}, pendingCH=null, unionCH=null,
> phase=NO_REBALANCE, actualMembers=[GetAllCacheNotFoundResponseTest-NodeA-
> 12369, GetAllCacheNotFoundResponseTest-NodeB-43554], persistentUUIDs=[dea9edf3-
> cd8a-443e-8dc6-dcc208161f39, 77a3980e-a95a-4044-a9ba-293e29f7d25a]}.
> rebalanceInProgress=false, currentChIsBalanced=false
> {noformat}
> Stacktrace:
> {noformat}
> java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node GetAllCacheNotFoundResponseTest-NodeA-12369, current topology is CacheTopology{id=5, rebalanceId=2, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=3, owners = (2)[GetAllCacheNotFoundResponseTest-NodeA-12369: 3+0, GetAllCacheNotFoundResponseTest-NodeB-43554: 0+1]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[GetAllCacheNotFoundResponseTest-NodeA-12369, GetAllCacheNotFoundResponseTest-NodeB-43554], persistentUUIDs=[dea9edf3-cd8a-443e-8dc6-dcc208161f39, 77a3980e-a95a-4044-a9ba-293e29f7d25a]}. rebalanceInProgress=false, currentChIsBalanced=false
> at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:385)
> at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:421)
> at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:291)
> at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:296)
> at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:360)
> at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:374)
> at org.infinispan.commands.GetAllCacheNotFoundResponseTest.createCacheManagers(GetAllCacheNotFoundResponseTest.java:58)
> at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:113)
> at org.infinispan.test.MultipleCacheManagersTest.createBeforeClass(MultipleCacheManagersTest.java:107)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ... Removed 15 stack frames
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8615) ClusteredLockImplTest.testTryLockWithTimeoutAfterLockWithSmallTimeout random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8615?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8615:
-------------------------------
Status: Open (was: New)
> ClusteredLockImplTest.testTryLockWithTimeoutAfterLockWithSmallTimeout random failures
> -------------------------------------------------------------------------------------
>
> Key: ISPN-8615
> URL: https://issues.jboss.org/browse/ISPN-8615
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.2.0.Beta1
> Reporter: Dan Berindei
> Assignee: Katia Aresti
> Labels: testsuite_stability
> Fix For: 9.2.0.Beta2
>
>
> {noformat}
> java.lang.AssertionError:
> at org.infinispan.lock.impl.lock.ClusteredLockImplTest.testTryLockWithTimeoutAfterLockWithSmallTimeout(ClusteredLockImplTest.java:94)
> {noformat}
> It happens rarely in CI, but I can reproduce it every time if I change the timeout to 100 ms. IMO the difference between {{testTryLockWithTimeoutAfterLockWithSmallTimeout}} and {{testTryLockWithTimeoutAfterLockWithBigTimeout}} should be that the former waits for {{tryLock(smalltimeout, unit)}} to time out before unlocking, and the latter waits for a little time before unlocking and checks that {{tryLock(bigtimeout, unit)}} still succeeds.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8608) GetAllCacheNotFoundResponseTest fails
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8608?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-8608:
------------------------------------
With a controlled CHF, a segment can have fewer than numOwners owners while the cluster is smaller than expected. That means MultipleCacheManagersTest.createClusteredCaches() should call waitForClusterToForm() only after starting all the nodes, not in each iteration, or it will time out waiting for all segments to have numOwners owners.
> GetAllCacheNotFoundResponseTest fails
> -------------------------------------
>
> Key: ISPN-8608
> URL: https://issues.jboss.org/browse/ISPN-8608
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Dan Berindei
>
> {noformat}
> Error Message
> Timed out waiting for rebalancing to complete on node
> GetAllCacheNotFoundResponseTest-NodeA-12369, current topology is
> CacheTopology{id=5, rebalanceId=2, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=3, owners =
> (2)[GetAllCacheNotFoundResponseTest-NodeA-12369: 3+0,
> GetAllCacheNotFoundResponseTest-NodeB-43554: 0+1]}, pendingCH=null, unionCH=null,
> phase=NO_REBALANCE, actualMembers=[GetAllCacheNotFoundResponseTest-NodeA-
> 12369, GetAllCacheNotFoundResponseTest-NodeB-43554], persistentUUIDs=[dea9edf3-
> cd8a-443e-8dc6-dcc208161f39, 77a3980e-a95a-4044-a9ba-293e29f7d25a]}.
> rebalanceInProgress=false, currentChIsBalanced=false
> {noformat}
> Stacktrace:
> {noformat}
> java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node GetAllCacheNotFoundResponseTest-NodeA-12369, current topology is CacheTopology{id=5, rebalanceId=2, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=3, owners = (2)[GetAllCacheNotFoundResponseTest-NodeA-12369: 3+0, GetAllCacheNotFoundResponseTest-NodeB-43554: 0+1]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[GetAllCacheNotFoundResponseTest-NodeA-12369, GetAllCacheNotFoundResponseTest-NodeB-43554], persistentUUIDs=[dea9edf3-cd8a-443e-8dc6-dcc208161f39, 77a3980e-a95a-4044-a9ba-293e29f7d25a]}. rebalanceInProgress=false, currentChIsBalanced=false
> at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:385)
> at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:421)
> at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:291)
> at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:296)
> at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:360)
> at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:374)
> at org.infinispan.commands.GetAllCacheNotFoundResponseTest.createCacheManagers(GetAllCacheNotFoundResponseTest.java:58)
> at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:113)
> at org.infinispan.test.MultipleCacheManagersTest.createBeforeClass(MultipleCacheManagersTest.java:107)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ... Removed 15 stack frames
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8608) GetAllCacheNotFoundResponseTest fails
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8608?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-8608:
----------------------------------
Assignee: Dan Berindei
> GetAllCacheNotFoundResponseTest fails
> -------------------------------------
>
> Key: ISPN-8608
> URL: https://issues.jboss.org/browse/ISPN-8608
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Dan Berindei
>
> {noformat}
> Error Message
> Timed out waiting for rebalancing to complete on node
> GetAllCacheNotFoundResponseTest-NodeA-12369, current topology is
> CacheTopology{id=5, rebalanceId=2, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=3, owners =
> (2)[GetAllCacheNotFoundResponseTest-NodeA-12369: 3+0,
> GetAllCacheNotFoundResponseTest-NodeB-43554: 0+1]}, pendingCH=null, unionCH=null,
> phase=NO_REBALANCE, actualMembers=[GetAllCacheNotFoundResponseTest-NodeA-
> 12369, GetAllCacheNotFoundResponseTest-NodeB-43554], persistentUUIDs=[dea9edf3-
> cd8a-443e-8dc6-dcc208161f39, 77a3980e-a95a-4044-a9ba-293e29f7d25a]}.
> rebalanceInProgress=false, currentChIsBalanced=false
> {noformat}
> Stacktrace:
> {noformat}
> java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node GetAllCacheNotFoundResponseTest-NodeA-12369, current topology is CacheTopology{id=5, rebalanceId=2, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=3, owners = (2)[GetAllCacheNotFoundResponseTest-NodeA-12369: 3+0, GetAllCacheNotFoundResponseTest-NodeB-43554: 0+1]}, pendingCH=null, unionCH=null, phase=NO_REBALANCE, actualMembers=[GetAllCacheNotFoundResponseTest-NodeA-12369, GetAllCacheNotFoundResponseTest-NodeB-43554], persistentUUIDs=[dea9edf3-cd8a-443e-8dc6-dcc208161f39, 77a3980e-a95a-4044-a9ba-293e29f7d25a]}. rebalanceInProgress=false, currentChIsBalanced=false
> at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:385)
> at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:421)
> at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:291)
> at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:296)
> at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:360)
> at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:374)
> at org.infinispan.commands.GetAllCacheNotFoundResponseTest.createCacheManagers(GetAllCacheNotFoundResponseTest.java:58)
> at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:113)
> at org.infinispan.test.MultipleCacheManagersTest.createBeforeClass(MultipleCacheManagersTest.java:107)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ... Removed 15 stack frames
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8634) Wildfly 11 fails to start with Infinispan 9.x modules installed
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/ISPN-8634?page=com.atlassian.jira.plugin.... ]
Scott Van Wart edited comment on ISPN-8634 at 12/14/17 5:07 PM:
----------------------------------------------------------------
I also reported: https://issues.jboss.org/browse/ISPN-8633.
It looks like Wildfly 11 doesn't include a module named "org.jboss.sasl". Wildfly 10 did: wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/sasl.
If you look at the stack trace (second problem) in ISPN-8633, the exception thrown is java.lang.IllegalStateException
at org.jboss.as.controller.ParallelBootOperationContext.getManagementModel(ParallelBootOperationContext.java:133)
ParallelBootOperationContext.getManagementModel() has just a single line in it that throws this exception so it looks like an unintended use of the configuration model during startup (i.e. calling reloadRequired()).
Starting this configuration works just fine as long as no cache configurations are defined. It also seems to work all right (at first) if you wait for Wildfly 11 to boot, and then use the CLI to add a cache container (e.g. /subsystem=infinispan/cache-container=my-cache-container:add).
I'm not sure how the client JAR relates to my initial forum post but it looks like a separate issue from ISPN-8633.
was (Author: silvaran):
I also reported: https://issues.jboss.org/browse/ISPN-8633.
It looks like Wildfly 11 doesn't include a module named "org.jboss.sasl". Wildfly 10 did: wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/sasl.
If you look at the stack trace (second problem) in ISPN-8633, the exception thrown is java.lang.IllegalStateException
at org.jboss.as.controller.ParallelBootOperationContext.getManagementModel(ParallelBootOperationContext.java:133)
ParallelBootOperationContext.getManagementModel() has a single line in it that throws this exception so it looks like an unintended use of the configuration model during startup (i.e. calling reloadRequired()).
Starting this configuration works just fine as long as no cache configurations are defined. It also seems to work all right (at first) if you wait for Wildfly 11 to boot, and then use the CLI to add a cache container (e.g. /subsystem=infinispan/cache-container=my-cache-container:add).
I'm not sure how the client JAR relates to my initial forum post but it looks like a separate issue from ISPN-8633.
> Wildfly 11 fails to start with Infinispan 9.x modules installed
> ---------------------------------------------------------------
>
> Key: ISPN-8634
> URL: https://issues.jboss.org/browse/ISPN-8634
> Project: Infinispan
> Issue Type: Bug
> Components: Integration
> Affects Versions: 9.2.0.Beta1, 9.1.3.Final
> Reporter: Alan Field
>
> A user on the forums reported that he got the following errors starting up Wildfly 11 with the Infinispan 9.1 modules installed and the extensions added to the {{standalone.xml}} file:
> {noformat}
> 14:25:14,340 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
> at org.jboss.as.server.ServerService.boot(ServerService.java:387)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:370)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.infinispan.server.endpoint:ispn-9.2
> at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:154)
> at org.jboss.as.server.parsing.StandaloneXml$DefaultExtensionHandler.parseExtensions(StandaloneXml.java:131)
> at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:219)
> at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:142)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:126)
> ... 3 more
> Caused by: java.util.concurrent.ExecutionException: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:146)
> ... 11 more
> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module
> at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:195)
> at org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:68)
> at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:126)
> at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:123)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: org.jboss.modules.ModuleNotFoundException: org.jboss.sasl
> at org.jboss.modules.Module.addPaths(Module.java:1217)
> at org.jboss.modules.Module.link(Module.java:1573)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1601)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:287)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:271)
> at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:177)
> ... 8 more
> {noformat}
> This also happens with the 9.2.0.Beta1 modules. Wildfly 11 includes a {{bin/client/README-EJB-JMS.txt}} file that states:
> {noformat}
> jboss-client.jar is a combined client jar for WildFly, for use in non-maven environments. This jar should be used
> with standalone clients only, not with deployments are that deployed to a WildFly instance.
> This jar contains the classes required for remote JMS and EJB usage, and consists of the following shaded artifacts:
> org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec
> org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec
> org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec
> com.google.guava:guava
> commons-beanutils:commons-beanutils
> commons-collections:commons-collections
> io.netty:netty-all
> org.apache.activemq:artemis-commons
> org.apache.activemq:artemis-core-client
> org.apache.activemq:artemis-hqclient-protocol
> org.apache.activemq:artemis-jms-client
> org.jboss:jboss-ejb-client
> org.jboss:jboss-remote-naming
> org.jboss.logging:jboss-logging
> org.jboss.marshalling:jboss-marshalling
> org.jboss.marshalling:jboss-marshalling-river
> org.jboss.remoting:jboss-remoting
> org.jboss.remotingjmx:remoting-jmx
> org.jboss.sasl:jboss-sasl
> org.jboss.xnio:xnio-api
> org.jboss.xnio:xnio-nio
> org.jgroups:jgroups
> org.slf4j:slf4j-api
> org.slf4j:jcl-over-slf4j
> Maven users should not use this jar, but should use the following BOM dependencies instead
> <dependencies>
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-ejb-client-bom</artifactId>
> <type>pom</type>
> </dependency>
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-jms-client-bom</artifactId>
> <type>pom</type>
> </dependency>
> </dependencies>
> This is because using maven with a shaded jar has a very high chance of causing class version conflicts, which is why
> we do not publish this jar to the maven repository.
> {noformat}
> The modules will need to modified to deal with this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8634) Wildfly 11 fails to start with Infinispan 9.x modules installed
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/ISPN-8634?page=com.atlassian.jira.plugin.... ]
Scott Van Wart commented on ISPN-8634:
--------------------------------------
I also reported: https://issues.jboss.org/browse/ISPN-8633.
It looks like Wildfly 11 doesn't include a module named "org.jboss.sasl". Wildfly 10 did: wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/sasl.
If you look at the stack trace (second problem) in ISPN-8633, the exception thrown is java.lang.IllegalStateException
at org.jboss.as.controller.ParallelBootOperationContext.getManagementModel(ParallelBootOperationContext.java:133)
ParallelBootOperationContext.getManagementModel() has a single line in it that throws this exception so it looks like an unintended use of the configuration model during startup (i.e. calling reloadRequired()).
Starting this configuration works just fine as long as no cache configurations are defined. It also seems to work all right (at first) if you wait for Wildfly 11 to boot, and then use the CLI to add a cache container (e.g. /subsystem=infinispan/cache-container=my-cache-container:add).
I'm not sure how the client JAR relates to my initial forum post but it looks like a separate issue from ISPN-8633.
> Wildfly 11 fails to start with Infinispan 9.x modules installed
> ---------------------------------------------------------------
>
> Key: ISPN-8634
> URL: https://issues.jboss.org/browse/ISPN-8634
> Project: Infinispan
> Issue Type: Bug
> Components: Integration
> Affects Versions: 9.2.0.Beta1, 9.1.3.Final
> Reporter: Alan Field
>
> A user on the forums reported that he got the following errors starting up Wildfly 11 with the Infinispan 9.1 modules installed and the extensions added to the {{standalone.xml}} file:
> {noformat}
> 14:25:14,340 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
> at org.jboss.as.server.ServerService.boot(ServerService.java:387)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:370)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.infinispan.server.endpoint:ispn-9.2
> at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:154)
> at org.jboss.as.server.parsing.StandaloneXml$DefaultExtensionHandler.parseExtensions(StandaloneXml.java:131)
> at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:219)
> at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:142)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:126)
> ... 3 more
> Caused by: java.util.concurrent.ExecutionException: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:146)
> ... 11 more
> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module
> at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:195)
> at org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:68)
> at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:126)
> at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:123)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: org.jboss.modules.ModuleNotFoundException: org.jboss.sasl
> at org.jboss.modules.Module.addPaths(Module.java:1217)
> at org.jboss.modules.Module.link(Module.java:1573)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1601)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:287)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:271)
> at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:177)
> ... 8 more
> {noformat}
> This also happens with the 9.2.0.Beta1 modules. Wildfly 11 includes a {{bin/client/README-EJB-JMS.txt}} file that states:
> {noformat}
> jboss-client.jar is a combined client jar for WildFly, for use in non-maven environments. This jar should be used
> with standalone clients only, not with deployments are that deployed to a WildFly instance.
> This jar contains the classes required for remote JMS and EJB usage, and consists of the following shaded artifacts:
> org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec
> org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec
> org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec
> com.google.guava:guava
> commons-beanutils:commons-beanutils
> commons-collections:commons-collections
> io.netty:netty-all
> org.apache.activemq:artemis-commons
> org.apache.activemq:artemis-core-client
> org.apache.activemq:artemis-hqclient-protocol
> org.apache.activemq:artemis-jms-client
> org.jboss:jboss-ejb-client
> org.jboss:jboss-remote-naming
> org.jboss.logging:jboss-logging
> org.jboss.marshalling:jboss-marshalling
> org.jboss.marshalling:jboss-marshalling-river
> org.jboss.remoting:jboss-remoting
> org.jboss.remotingjmx:remoting-jmx
> org.jboss.sasl:jboss-sasl
> org.jboss.xnio:xnio-api
> org.jboss.xnio:xnio-nio
> org.jgroups:jgroups
> org.slf4j:slf4j-api
> org.slf4j:jcl-over-slf4j
> Maven users should not use this jar, but should use the following BOM dependencies instead
> <dependencies>
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-ejb-client-bom</artifactId>
> <type>pom</type>
> </dependency>
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-jms-client-bom</artifactId>
> <type>pom</type>
> </dependency>
> </dependencies>
> This is because using maven with a shaded jar has a very high chance of causing class version conflicts, which is why
> we do not publish this jar to the maven repository.
> {noformat}
> The modules will need to modified to deal with this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8633) Wildfly/EAP modules are unusable on Wildfly 11
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/ISPN-8633?page=com.atlassian.jira.plugin.... ]
Scott Van Wart updated ISPN-8633:
---------------------------------
Forum Reference: https://developer.jboss.org/message/978805
> Wildfly/EAP modules are unusable on Wildfly 11
> ----------------------------------------------
>
> Key: ISPN-8633
> URL: https://issues.jboss.org/browse/ISPN-8633
> Project: Infinispan
> Issue Type: Bug
> Components: Integration , WildFly modules
> Affects Versions: 8.2.8.Final, 9.2.0.Beta1, 9.1.3.Final
> Reporter: Scott Van Wart
> Labels: infinispan, integration, wildfly
> Attachments: infinispan-9.1.3-wildfly-11.0.0-log1.txt, infinispan-9.1.3-wildfly-11.0.0-log2.txt
>
>
> I started with a fresh installation of Wildfly 11 and followed the instructions in the Infinispan User Guide: http://infinispan.org/docs/stable/user_guide/user_guide.html#infinispan_m... . I didn't need to build or deploy an application to reproduce this. I followed 21.9 Infinispan modules for Wildfly under the section "Configuration" (steps 1-4, although I skipped step 4 since I didn't need any endpoints).
> First run produced the attached log (infinispan-9.1.3-wildfly-11.0.0-log1.txt). I then edited $JBOSS_HOME/modules/org/infinispan/server/endpoint/ispn-9.1/module.xml, as well as module.xml in server/hotrod and org/jgroups/extension to remove dependencies on "org.jboss.sasl". On startup, this produced the second stack trace (infinispan-9.1.3-wildfly-11.0.0-log2.txt).
> I tried Infinispan 8.2.8 (the version packaged with Wildfly 11.0.0) and Infinispan 9.2.0.Beta1 and got the same results. I made a forum post as well: https://developer.jboss.org/thread/276791
> Though I only tried 9.1.3 on Wildfly 10.1.0, the instructions seem to work fine with that version of Wildfly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8635) Improve embedded lock tests
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-8635?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek updated ISPN-8635:
----------------------------------
Status: Open (was: New)
> Improve embedded lock tests
> ---------------------------
>
> Key: ISPN-8635
> URL: https://issues.jboss.org/browse/ISPN-8635
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.2.0.Beta1
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
>
> Some embedded lock tests don't test possible paths and therefore don't fail when expected condition is not met (e.g. {{ClusteredLockSplitBrainTest#testLockUseAfterPartitionWithoutMajority}} tests only which exception is thrown, but doesn't fail when no exception is thrown).
> {{ClusteredLockTest}} should contain tests which where several nodes tries to get the same lock in parallel.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years