[JBoss JIRA] (ISPN-8635) Improve embedded lock tests
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-8635:
-------------------------------------
Summary: 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
[JBoss JIRA] (ISPN-8634) Wildfly 11 fails to start with Infinispan 9.x modules installed
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/ISPN-8634?page=com.atlassian.jira.plugin.... ]
Alan Field commented on ISPN-8634:
----------------------------------
Wildfly 11 also uses Elytron for security which could be causing this.
> 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 Alan Field (JIRA)
Alan Field created ISPN-8634:
--------------------------------
Summary: 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.1.3.Final, 9.2.0.Beta1
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)
Scott Van Wart created ISPN-8633:
------------------------------------
Summary: 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: 9.1.3.Final, 9.2.0.Beta1, 8.2.8.Final
Reporter: Scott Van Wart
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-8632) ConflictManager can cause deadlock on cache shutdown
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8632?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-8632:
-------------------------------
Status: Open (was: New)
> ConflictManager can cause deadlock on cache shutdown
> ----------------------------------------------------
>
> Key: ISPN-8632
> URL: https://issues.jboss.org/browse/ISPN-8632
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Beta1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.2.0.Beta2
>
>
> If stop is called on an EmbeddedCacheManager when the conflict resolution stage of a merge in ongoing, then it is impossible for ClusterCacheStatus::doLeave to proceed as ClusterCacheStatus::onPartitionMerge holds the ClusterCacheStatus lock. This is fine if conflict resolution completes successfully, however it is possible that the StateProviderImpl on the remote nodes has shutdown and therefore it's not possible for the ReplicaSpliterator to complete its execution and deadlock occurs.
> To prevent the above scenario we should improve how the StateReceiverImpl and DefaultConflictManager handle stopping caches. Furthermore, we should also introduce a timeout when attempting to discover cache conflicts.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8632) ConflictManager can cause deadlock on cache shutdown
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8632?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-8632:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5588
> ConflictManager can cause deadlock on cache shutdown
> ----------------------------------------------------
>
> Key: ISPN-8632
> URL: https://issues.jboss.org/browse/ISPN-8632
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Beta1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.2.0.Beta2
>
>
> If stop is called on an EmbeddedCacheManager when the conflict resolution stage of a merge in ongoing, then it is impossible for ClusterCacheStatus::doLeave to proceed as ClusterCacheStatus::onPartitionMerge holds the ClusterCacheStatus lock. This is fine if conflict resolution completes successfully, however it is possible that the StateProviderImpl on the remote nodes has shutdown and therefore it's not possible for the ReplicaSpliterator to complete its execution and deadlock occurs.
> To prevent the above scenario we should improve how the StateReceiverImpl and DefaultConflictManager handle stopping caches. Furthermore, we should also introduce a timeout when attempting to discover cache conflicts.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8632) ConflictManager can cause deadlock on cache shutdown
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-8632:
----------------------------------
Summary: ConflictManager can cause deadlock on cache shutdown
Key: ISPN-8632
URL: https://issues.jboss.org/browse/ISPN-8632
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.2.0.Beta1
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 9.2.0.Beta2
If stop is called on an EmbeddedCacheManager when the conflict resolution stage of a merge in ongoing, then it is impossible for ClusterCacheStatus::doLeave to proceed as ClusterCacheStatus::onPartitionMerge holds the ClusterCacheStatus lock. This is fine if conflict resolution completes successfully, however it is possible that the StateProviderImpl on the remote nodes has shutdown and therefore it's not possible for the ReplicaSpliterator to complete its execution and deadlock occurs.
To prevent the above scenario we should improve how the StateReceiverImpl and DefaultConflictManager handle stopping caches. Furthermore, we should also introduce a timeout when attempting to discover cache conflicts.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8631) GetAllCacheNotFoundResponseTest.createBeforeClass fails
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8631?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8631:
-------------------------------
Status: Open (was: New)
> 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