[JBoss JIRA] (JGRP-1638) Memory leak
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1638?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1638:
--------------------------------
* 3.3.0.Beta1 is OK --> can send 100 million messages each
* 3.3.0.Beta2 fails with 20 million
==> The problem was introduced between beta1 and beta2
> Memory leak
> -----------
>
> Key: JGRP-1638
> URL: https://issues.jboss.org/browse/JGRP-1638
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.4
>
>
> Running MPerf with conf/fast-local.xml (2 members on the same host, 20 million messages each) creates a memory leak in 3.4.x.
> This runs perfectly 3.2.8.Final, so it must be something that was introduced in 3.3.x (3.4.x at this time has almost no diffs to 3.3.0.Final).
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-894) javax.ws.rs.ext.FactoryFinder use application's Class Loader which causes CL Memory Leak
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-894?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas resolved WFLY-894.
---------------------------------
Resolution: Won't Fix
Due to the way the API is designed there is no easy way to fix this, as the API classes themselves hold a static reference to the implementation.
Fortunatly in Wildfly upstream it is much easier to exlude our JAX-RS API implementation as a dependency, allowing you to package the JAX-RS API classes in the jar, which will prevent a leak.
> javax.ws.rs.ext.FactoryFinder use application's Class Loader which causes CL Memory Leak
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-894
> URL: https://issues.jboss.org/browse/WFLY-894
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Environment: Seam 2.2.2 webapp with Resteasy 2.3.1
> Reporter: Philippe Guinot
> Assignee: Stuart Douglas
> Labels: CacheControl, Cookie, EntityTag, FactoryFinder, MediaType, NewCookie, RuntimeDelegate, classloader, javax.ws.rs.api, leak, resteasy
>
> Deploying a Seam 2 application with Resteasy (deployed as JAR withing EarContent/lib) actually causes the following issue:
> * When Seam access classes such as CacheControl, Cookie, EntityTag, MediaType or NewCookie, it loads my application's Resteasy classes, as using the CurrentThread's context class loader.
> * So I ended up with the static field delegate of those classes keeping a reference to my application's class loader which cause a CL Memory Leak.
> Since, the javax.ws.rs.core.Cookie/Entitytag, etc.. are server side components, I don't think they should refer to any deployed application.
> To avoid this, the only way to do so, was at the server start-up to initialize those components in that way:
> {code}
> try {
> javax.ws.rs.core.CacheControl.valueOf("");
> } catch (IllegalArgumentException e) {
> }
> try {
> javax.ws.rs.core.Cookie.valueOf("");
> } catch (IllegalArgumentException e) {
> }
> try {
> javax.ws.rs.core.EntityTag.valueOf("");
> } catch (IllegalArgumentException e) {
> }
> try {
> javax.ws.rs.core.MediaType.valueOf("");
> } catch (IllegalArgumentException e) {
> }
> try {
> javax.ws.rs.core.NewCookie.valueOf("");
> } catch (IllegalArgumentException e) {
> }{code}
> (I put this in org.jboss.as.server.Main before line 91, but this is not the best place of course. Perhaps a class such as JreMemoryLeakPreventionListener should be used, but for the moment the use of this listener is disabled in JBoss Web 7, see https://community.jboss.org/thread/164760 )
> But, since the RuntimeDelegate needed to find the Resteasy classed, I had to use the module ClassLoader instead of the current context class loader in the javax.ws.rs.ext.FactoryFinder.getContextClassLoader() method. Then, as the javax.ws.rs.api module actually depends on the org.jboss.resteasy.resteasy-jaxrs, this works well and avoids any dependency to my application's class loader.
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-838) Can't get implementing classname for JSR77 MBean
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-838?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas updated WFLY-838:
--------------------------------
Fix Version/s: Awaiting Volunteers
Assignee: (was: Stuart Douglas)
> Can't get implementing classname for JSR77 MBean
> ------------------------------------------------
>
> Key: WFLY-838
> URL: https://issues.jboss.org/browse/WFLY-838
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Reporter: Anders Welen
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> The following exception are thrown when asking the MBean server for the classname implementing "jboss.jsr77:j2eeType=WebModule,name=MyWar.war,J2EEServer=default".
> It should be a legal call. Why are the code clearly states it's illegal?
>
> java.lang.IllegalStateException: JBAS019905: Should not get called
> at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers$J2EEModuleHandler.queryObjectNames(J2EEDeployedObjectHandlers.java:245)
> at org.jboss.as.jsr77.managedobject.BaseHandler.getMBeanInfo(BaseHandler.java:64)
> at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers.getMBeanInfo(J2EEDeployedObjectHandlers.java:147)
> at org.jboss.as.jsr77.managedobject.ManagedObjectHandlerRegistry.getMBeanInfo(ManagedObjectHandlerRegistry.java:112)
> at org.jboss.as.jsr77.subsystem.JSR77ManagementMBeanServer.getMBeanInfo(JSR77ManagementMBeanServer.java:179)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanInfo(PluggableMBeanServerImpl.java:212)
>
> The error can easily be triggered by using JConsole to browse the same MBean.
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-962) Unable to combine Resource Archive (RAR) <dependencies> and <exclusions> directives in jboss-deployment-structure.xml without <exclusions> being ignored
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-962?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas resolved WFLY-962.
---------------------------------
Resolution: Won't Fix
The underlying cause of this issue is that exclusions will not exclude a module if it is not a direct dependency but is instead being exported from another module.
Unfortunatly the amount of engineering effort required to fix this is significant, and would require fairly invasive changes to how jboss-modules works, and as such I can't see this getting fixed any time soon.
In Wildfly this will be less of an issue, as we are trying to reduce the usage of exported dependencies.
> Unable to combine Resource Archive (RAR) <dependencies> and <exclusions> directives in jboss-deployment-structure.xml without <exclusions> being ignored
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-962
> URL: https://issues.jboss.org/browse/WFLY-962
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Environment: Linux (CentOS 6.3), JDK 1.6.0_37
> Reporter: Matthew White
> Assignee: Stuart Douglas
> Attachments: jbossas-bugexample.zip
>
>
> I have an EAR file where for a WAR sub-deployment I want to declare a startup dependency on another Resource Archive (RAR) deployment (in my application's case, the WebSphere MQ RAR - but I have recreated this with other Resource Archives) and also have a module exclusion (in this case, on the org.apache.log4j module so that my application can use internally defined Log4J configuration).
> The jboss-deployment-structure.xml for the EAR looks like this :-
> {code:xml}
> <jboss-deployment-structure>
> <sub-deployment name="application.war">
> <dependencies>
> <module name="deployment.wmq.jmsra.rar" />
> </dependencies>
> <exclusions>
> <module name="org.apache.log4j" />
> </exclusions>
> </sub-deployment>
> </jboss-deployment-structure>
> {code}
> When I startup the EAR, the <dependencies> directive for the sub-deployment takes effect - the WAR is not started until the WebSphere MQ RAR is available. However, my <exclusions> directive is ignored and the application Log4J configuration is not used.
> If I restructure the jboss-deployment-structure.xml and remove the <dependencies> directive from the sub-deployment :-
> {code:xml}
> <jboss-deployment-structure>
> <sub-deployment name="application.war">
> <exclusions>
> <module name="org.apache.log4j" />
> </exclusions>
> </sub-deployment>
> </jboss-deployment-structure>
> {code}
> The <exclusions> directive is interpreted correctly and the application Log4J configuration is used.
> Also, if I go the other way and remove the <exclusions> directive and put the the <dependencies> directive back :-
> {code:xml}
> <jboss-deployment-structure>
> <sub-deployment name="application.war">
> <dependencies>
> <module name="deployment.wmq.jmsra.rar" />
> </dependencies>
> </sub-deployment>
> </jboss-deployment-structure>
> {code}
> The <dependencies> continues to be interpreted correctly and the WAR does not start until the dependency is available.
> It would just seem that I can't combine the two directives and have them both be interpreted correctly. I have tried changing the order of defining them in the file but that (unsurprisingly) didn't make a lot of difference.
> I have also tried this with the dependency being any other type of deployment - EAR, WAR, JAR, etc - and in those cases everything works correctly. It seems to only be an issue if the dependency is a Resource Archive.
> I've also given it a go on a recent 7.2.0 Nightly (3 Jan 2013) and it is also exhibiting the same behaviour.
> I have attached a sample application to replicate this behaviour. It uses the Apache Jackrabbit RAR (since the WebSphere MQ one is not distributable) as the Resource Archive dependency and creates 2 EAR files that are trying to use log4j to log to a file - one with just the <exclusions> directive and one with both the <dependencies> and <exclusions> directives. See the README file in the zip for more details.
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-143) Improve testing of Infinispan subsystem management features
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-143?page=com.atlassian.jira.plugin.s... ]
Chao Wang commented on WFLY-143:
--------------------------------
linked a wrong reference to this upstream issue, sorry for the inconvenience
> Improve testing of Infinispan subsystem management features
> -----------------------------------------------------------
>
> Key: WFLY-143
> URL: https://issues.jboss.org/browse/WFLY-143
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Domain Management
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.Alpha2
>
>
> We current use InfinispanSubsystemTest to test the integrity of the Infinispan subsystem implementation.
> From the documentation:
> {noformat}
> Tests the ability to create a model from an xml configuration, marshal the model back to xml, re-read that marshalled model
> into a new model that matches the first one, execute a "describe" operation for the model, create yet another model
> from executing the results of that describe operation, and compare that model to first model.
> {noformat}
> Over and above these tests, we need more specific tests which cover use cases such as:
> - every attribute can be read/written as required and that the subsequent reload-required state is as expected
> - operation sequences such as add/remove/add, add/add give expected results for all resources in the subsystem
> - validating that the XML configuration specified gets translated into the desired Infinispan configuration
> - and many others
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-1431) org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1431?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1431:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=969915
> org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1431
> URL: https://issues.jboss.org/browse/WFLY-1431
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Attachments: WFLY-1431.patch
>
>
> org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed with
> {noformat}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertTrue(Assert.java:54)
> at org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase.testInterceptorPostConstructWithProceed(InterceptorLifecycleSFSBTestCase.java:67)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:214)
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:915)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> {noformat}
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-143) Improve testing of Infinispan subsystem management features
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-143?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated WFLY-143:
-----------------------------------------
Bugzilla Update: (was: Perform)
Bugzilla References: (was: https://bugzilla.redhat.com/show_bug.cgi?id=969915)
> Improve testing of Infinispan subsystem management features
> -----------------------------------------------------------
>
> Key: WFLY-143
> URL: https://issues.jboss.org/browse/WFLY-143
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Domain Management
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.Alpha2
>
>
> We current use InfinispanSubsystemTest to test the integrity of the Infinispan subsystem implementation.
> From the documentation:
> {noformat}
> Tests the ability to create a model from an xml configuration, marshal the model back to xml, re-read that marshalled model
> into a new model that matches the first one, execute a "describe" operation for the model, create yet another model
> from executing the results of that describe operation, and compare that model to first model.
> {noformat}
> Over and above these tests, we need more specific tests which cover use cases such as:
> - every attribute can be read/written as required and that the subsequent reload-required state is as expected
> - operation sequences such as add/remove/add, add/add give expected results for all resources in the subsystem
> - validating that the XML configuration specified gets translated into the desired Infinispan configuration
> - and many others
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-143) Improve testing of Infinispan subsystem management features
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-143?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-143:
----------------------------------------------
Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 969915|https://bugzilla.redhat.com/show_bug.cgi?id=969915] from NEW to ASSIGNED
> Improve testing of Infinispan subsystem management features
> -----------------------------------------------------------
>
> Key: WFLY-143
> URL: https://issues.jboss.org/browse/WFLY-143
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Domain Management
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.Alpha2
>
>
> We current use InfinispanSubsystemTest to test the integrity of the Infinispan subsystem implementation.
> From the documentation:
> {noformat}
> Tests the ability to create a model from an xml configuration, marshal the model back to xml, re-read that marshalled model
> into a new model that matches the first one, execute a "describe" operation for the model, create yet another model
> from executing the results of that describe operation, and compare that model to first model.
> {noformat}
> Over and above these tests, we need more specific tests which cover use cases such as:
> - every attribute can be read/written as required and that the subsequent reload-required state is as expected
> - operation sequences such as add/remove/add, add/add give expected results for all resources in the subsystem
> - validating that the XML configuration specified gets translated into the desired Infinispan configuration
> - and many others
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-143) Improve testing of Infinispan subsystem management features
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-143?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-143:
----------------------------------------------
Chao Wang <chaowan(a)redhat.com> made a comment on [bug 969915|https://bugzilla.redhat.com/show_bug.cgi?id=969915]
Description of problem:
Failed line at #67 used a wrong LifecycleInterceptorNoProceed instead of LifecycleInterceptorWithProceed.
Version-Release number of selected component (if applicable):
EAP 6.1.0, upstream
How reproducible:
running single testInterceptorPostConstructWithProceed, or running testInterceptorPostConstructWithProceed at first place, we can constantly see the failure.
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
> Improve testing of Infinispan subsystem management features
> -----------------------------------------------------------
>
> Key: WFLY-143
> URL: https://issues.jboss.org/browse/WFLY-143
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Domain Management
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.Alpha2
>
>
> We current use InfinispanSubsystemTest to test the integrity of the Infinispan subsystem implementation.
> From the documentation:
> {noformat}
> Tests the ability to create a model from an xml configuration, marshal the model back to xml, re-read that marshalled model
> into a new model that matches the first one, execute a "describe" operation for the model, create yet another model
> from executing the results of that describe operation, and compare that model to first model.
> {noformat}
> Over and above these tests, we need more specific tests which cover use cases such as:
> - every attribute can be read/written as required and that the subsequent reload-required state is as expected
> - operation sequences such as add/remove/add, add/add give expected results for all resources in the subsystem
> - validating that the XML configuration specified gets translated into the desired Infinispan configuration
> - and many others
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-143) Improve testing of Infinispan subsystem management features
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-143?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated WFLY-143:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=969915
> Improve testing of Infinispan subsystem management features
> -----------------------------------------------------------
>
> Key: WFLY-143
> URL: https://issues.jboss.org/browse/WFLY-143
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Domain Management
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.Alpha2
>
>
> We current use InfinispanSubsystemTest to test the integrity of the Infinispan subsystem implementation.
> From the documentation:
> {noformat}
> Tests the ability to create a model from an xml configuration, marshal the model back to xml, re-read that marshalled model
> into a new model that matches the first one, execute a "describe" operation for the model, create yet another model
> from executing the results of that describe operation, and compare that model to first model.
> {noformat}
> Over and above these tests, we need more specific tests which cover use cases such as:
> - every attribute can be read/written as required and that the subsequent reload-required state is as expected
> - operation sequences such as add/remove/add, add/add give expected results for all resources in the subsystem
> - validating that the XML configuration specified gets translated into the desired Infinispan configuration
> - and many others
--
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
13 years, 1 month