[JBoss JIRA] (ISPN-8522) PreferAvailabilityStrategy conflict resolution should occur if an expected member is not in max topology
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8522?page=com.atlassian.jira.plugin.... ]
Ryan Emerson resolved ISPN-8522.
--------------------------------
Resolution: Done
> PreferAvailabilityStrategy conflict resolution should occur if an expected member is not in max topology
> --------------------------------------------------------------------------------------------------------
>
> Key: ISPN-8522
> URL: https://issues.jboss.org/browse/ISPN-8522
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Alpha2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.2.0.Beta2
>
>
> The current method for determining whether a split brain heal is occurring during an on merge event is wrong. Instead we should assume healing whenever one or more of the expected members is not in the membership of the maxTopology received.
> Furthermore, we should also utilise the Union CH of all distinct CHs encountered for conflict resolution. This is necessary to ensure that we read the entries associated with all possible write owners before the rebalance occurs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8615) ClusteredLockImplTest.testTryLockWithTimeoutAfterLockWithSmallTimeout random failures
by Katia Aresti (JIRA)
[ https://issues.jboss.org/browse/ISPN-8615?page=com.atlassian.jira.plugin.... ]
Katia Aresti updated ISPN-8615:
-------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5645
> 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)
8 years
[JBoss JIRA] (ISPN-8615) ClusteredLockImplTest.testTryLockWithTimeoutAfterLockWithSmallTimeout random failures
by Katia Aresti (JIRA)
[ https://issues.jboss.org/browse/ISPN-8615?page=com.atlassian.jira.plugin.... ]
Work on ISPN-8615 started by Katia Aresti.
------------------------------------------
> 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)
8 years
[JBoss JIRA] (ISPN-8566) Rest server doesn't handle wildcards in the Accept header
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8566?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8566:
------------------------------------
Fix Version/s: (was: 9.1.4.Final)
> Rest server doesn't handle wildcards in the Accept header
> ---------------------------------------------------------
>
> Key: ISPN-8566
> URL: https://issues.jboss.org/browse/ISPN-8566
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.0.Beta1, 9.1.3.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.2.0.Final
>
>
> Typically a browser automatically adds multiple mime types in the accept header, like:
> "text/html, application/xhtml+xml,\*/\*"
> But when requesting a document in a cache encoded with protostream with the headers above, the response is
> "Cannot find transcoder between application/xml and application/x-protostream"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8634) Wildfly 11 fails to start with Infinispan 9.x modules installed
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8634?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-8634:
----------------------------------
Assignee: Ryan Emerson
> 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
> Assignee: Ryan Emerson
>
> 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)
8 years