[JBoss JIRA] (ISPN-8616) DistAsyncFuncTest.testMergeFromNonOwner random failures
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8616?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-8616:
----------------------------------
Assignee: Ryan Emerson
> DistAsyncFuncTest.testMergeFromNonOwner random failures
> -------------------------------------------------------
>
> Key: ISPN-8616
> URL: https://issues.jboss.org/browse/ISPN-8616
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.2.0.Beta1
> Reporter: Dan Berindei
> Assignee: Ryan Emerson
> Labels: testsuite_stability
>
> {noformat}
> java.lang.AssertionError: Fail on owner cache DistAsyncFuncTest[DIST_ASYNC, tx=false]-NodeA-42474: dc.get(k1) returned null
> at org.infinispan.distribution.BaseDistFunctionalTest.assertOwnershipAndNonOwnership(BaseDistFunctionalTest.java:191)
> at org.infinispan.distribution.BaseDistFunctionalTest.assertOnAllCachesAndOwnership(BaseDistFunctionalTest.java:162)
> at org.infinispan.distribution.BaseDistFunctionalTest.initAndTest(BaseDistFunctionalTest.java:142)
> at org.infinispan.distribution.DistSyncFuncTest.testMergeFromNonOwner(DistSyncFuncTest.java:387)
> {noformat}
> The test method is new and the interceptors have changed, but it's probably the same problem with {{asyncWait}} signaled in ISPN-3741. I commented out the entire implementation of {{asyncWait}} in {{DistAsyncFuncTest}} and it still passed when run by itself, so we need a way to delay the commands and check that the test is not sensitive to such delays.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (ISPN-8396) Add interceptor preventing going out of memory
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8396?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-8396:
------------------------------------
{{COUNT-EXCEPTION}} doesn't seem particularly useful to me.
WRT a separate property, how about adding an {{EXCEPTION}} value to {{EvictionStrategy}}? We already have {{MANUAL}} there, so {{EXCEPTION}} isn't a huge stretch.
> Add interceptor preventing going out of memory
> ----------------------------------------------
>
> Key: ISPN-8396
> URL: https://issues.jboss.org/browse/ISPN-8396
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud, Core
> Reporter: Sebastian Łaskawiec
> Assignee: William Burns
>
> We need an interceptor which will calculate the amount of required memory for PUT and report an error if that put will cause going out of memory.
> Note that this is strictly connected to eviction mechanism (we might want to evict some entries on write)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (ISPN-8629) Javadoc modules' build invokes a new instance of Maven
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8629?page=com.atlassian.jira.plugin.... ]
Ryan Emerson resolved ISPN-8629.
--------------------------------
Resolution: Done
> Javadoc modules' build invokes a new instance of Maven
> ------------------------------------------------------
>
> Key: ISPN-8629
> URL: https://issues.jboss.org/browse/ISPN-8629
> Project: Infinispan
> Issue Type: Bug
> Components: Build
> Affects Versions: 9.2.0.Beta1, 9.1.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.2.0.Beta2
>
>
> During the javadoc modules build, {{maven-javadoc-plugin}} tries to detect the apidocs location of each dependency. If a module dependency doesn't have an apidocs directory, it tries to run a new Maven instance in order to build it, leading to messages like this:
> {noformat}
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:3.0.0-M1:javadoc' has not been previously called for the module: 'org.infinispan:infinispan-extended-statistics:jar:9.2.0-SNAPSHOT'. Trying to invoke it...
> [ERROR] MavenInvocationException: Error when invoking Maven, consult the invoker log file: /home/dan/Work/infinispan/javadoc/javadoc-embedded/target/invoker/maven-javadoc-plugin2134174433.txt
> [WARNING] Creating fake javadoc directory to prevent repeated invocations: /home/dan/Work/infinispan/extended-statistics/target/apidocs
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[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:
----------------------------------
Hey [~silvaran], I'm not sure the client JAR is the correct way to fix this issue either. I was pointing out that this was the only reference to {{org.jboss.sasl}} in the Wildfly 11 distribution. I think the Infinispan security support in the Wildfly modules will need to be updated to work with Elytron. Thanks for reporting 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
> 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, 3 months