[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[JBoss JIRA] (WFLY-1431) org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-1431?page=com.atlassian.jira.plugin.... ]
Chao Wang commented on WFLY-1431:
---------------------------------
hi [~jaikiran] this one keeps failing on our test suite running on Thunder http://thunder.sin.redhat.com:8380/hudson/job/eap6-testsuite/27/testReport/ (May. 31 )and http://thunder.sin.redhat.com:8380/hudson/job/eap6-testsuite/22/testReport/ (May 30). I'm not seeing this failure in QE test run.
Before introduce the fix, if run two test methods without any pause, it passed at most of time, it seems testInterceptorPostConstructWithProceed uses some data left around by testInterceptorPostConstructWithoutProceed. And, break point will help to see the failure as something is cleared during that time.
Yes, running single testInterceptorPostConstructWithProceed, or running testInterceptorPostConstructWithProceed at first place (test suite might fail due to this), we can constantly see the failure.
> 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
10 years, 10 months
[JBoss JIRA] (WFLY-406) Redesign web session clustering
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-406?page=com.atlassian.jira.plugin.s... ]
Paul Ferraro updated WFLY-406:
------------------------------
Description:
The current web session replication code has been around for ages and suffers from a number of issues:
* By maintaining a separate local map of sessions in conjunction with the session data stored in the distributed cache, stale data is inevitable - a number of issues have cropped up in EAP testing.
* Extra concurrency measures are required to ensure synchronicity of the local session map with the distributed cache.
* Extra logic/locking is required to invalidate the local session map is required per request
* AtomicMaps, on which the current implementation relies, have proven buggy
* Session access outside of the scope of the replication valve is possible and problematic
* Maintaining sessions locally means that the clustering code needs to implement passivation and expiration manually - instead of leveraging Infinispan full capabilities.
* The current code base is tightly coupled to JBoss Web. Migrating the code to support Undertow will inevitably introduce issues and code duplication.
The new design will incorporate a proper SPI for the servlet container. Thus the logic to integrate with Undertow vs JBoss Web will be relatively thin.
was:
The current web session replication code has been around for ages and suffers from a number of issues:
* By maintaining a separate local map of sessions in conjunction with the session data stored in the distributed cache, stale data is inevitable - a number of issues have cropped up in EAP testing.
* Extra concurrency measures are required to ensure synchronicity of the local session map with the distributed cache.
* Extra logic/locking is required to invalidate the local session map is required per request
* AtomicMaps, on which the currently implementation relies, have proven buggy
* Session access outside of the scope of the replication valve is possible and problematic
* Maintaining sessions locally means that the clustering code needs to implement passivation and expiration manually - instead of leveraging Infinispan full capabilities.
* The current code base is tightly coupled to JBoss Web. Migrating the code to support Undertow will inevitably introduce issues and code duplication.
The new design will incorporate a proper SPI for the servlet container. Thus the logic to integrate with Undertow vs JBoss Web will be relatively thin.
> Redesign web session clustering
> -------------------------------
>
> Key: WFLY-406
> URL: https://issues.jboss.org/browse/WFLY-406
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 8.0.0.Alpha2
>
>
> The current web session replication code has been around for ages and suffers from a number of issues:
> * By maintaining a separate local map of sessions in conjunction with the session data stored in the distributed cache, stale data is inevitable - a number of issues have cropped up in EAP testing.
> * Extra concurrency measures are required to ensure synchronicity of the local session map with the distributed cache.
> * Extra logic/locking is required to invalidate the local session map is required per request
> * AtomicMaps, on which the current implementation relies, have proven buggy
> * Session access outside of the scope of the replication valve is possible and problematic
> * Maintaining sessions locally means that the clustering code needs to implement passivation and expiration manually - instead of leveraging Infinispan full capabilities.
> * The current code base is tightly coupled to JBoss Web. Migrating the code to support Undertow will inevitably introduce issues and code duplication.
> The new design will incorporate a proper SPI for the servlet container. Thus the logic to integrate with Undertow vs JBoss Web will be relatively thin.
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-406) Redesign web session clustering
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-406?page=com.atlassian.jira.plugin.s... ]
Paul Ferraro updated WFLY-406:
------------------------------
Description:
The current web session replication code has been around for ages and suffers from a number of issues:
* By maintaining a separate local map of sessions in conjunction with the session data stored in the distributed cache, stale data is inevitable - a number of issues have cropped up in EAP testing.
* Extra concurrency measures are required to ensure synchronicity of the local session map with the distributed cache.
* Extra logic/locking is required to invalidate the local session map is required per request
* AtomicMaps, on which the currently implementation relies, have proven buggy
* Session access outside of the scope of the replication valve is possible and problematic
* Maintaining sessions locally means that the clustering code needs to implement passivation and expiration manually - instead of leveraging Infinispan full capabilities.
* The current code base is tightly coupled to JBoss Web. Migrating the code to support Undertow will inevitably introduce issues and code duplication.
The new design will incorporate a proper SPI for the servlet container. Thus the logic to integrate with Undertow vs JBoss Web will be relatively thin.
was:
The current web session replication code has been around for ages and suffers from a number of issues:
* By maintaining a separate local map of sessions in conjunction with the session data stored in the distributed cache, stale data is inevitable - an number of issues have cropped up in EAP testing.
* Extra concurrency measures are required to ensure synchronicity of the local session map with the distributed cache.
* Extra logic/locking is required to invalidate the local session map is required per request
* AtomicMaps, on which the currently implementation relies, have proven buggy
* Session access outside of the scope of the replication valve is possible and problematic
* Maintaining sessions locally means that the clustering code needs to implement passivation and expiration manually - instead of leveraging Infinispan full capabilities.
* The current code base is tightly coupled to JBoss Web. Migrating the code to support Undertow will inevitably introduce issues and code duplication.
The new design will incorporate a proper SPI for the servlet container. Thus the logic to integrate with Undertow vs JBoss Web will be relatively thin.
> Redesign web session clustering
> -------------------------------
>
> Key: WFLY-406
> URL: https://issues.jboss.org/browse/WFLY-406
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 8.0.0.Alpha2
>
>
> The current web session replication code has been around for ages and suffers from a number of issues:
> * By maintaining a separate local map of sessions in conjunction with the session data stored in the distributed cache, stale data is inevitable - a number of issues have cropped up in EAP testing.
> * Extra concurrency measures are required to ensure synchronicity of the local session map with the distributed cache.
> * Extra logic/locking is required to invalidate the local session map is required per request
> * AtomicMaps, on which the currently implementation relies, have proven buggy
> * Session access outside of the scope of the replication valve is possible and problematic
> * Maintaining sessions locally means that the clustering code needs to implement passivation and expiration manually - instead of leveraging Infinispan full capabilities.
> * The current code base is tightly coupled to JBoss Web. Migrating the code to support Undertow will inevitably introduce issues and code duplication.
> The new design will incorporate a proper SPI for the servlet container. Thus the logic to integrate with Undertow vs JBoss Web will be relatively thin.
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-1435) Modcluster subsystem startup missing required dependencies from JBoss Web
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-1435?page=com.atlassian.jira.plugin.... ]
Paul Ferraro resolved WFLY-1435.
--------------------------------
Resolution: Duplicate Issue
> Modcluster subsystem startup missing required dependencies from JBoss Web
> --------------------------------------------------------------------------
>
> Key: WFLY-1435
> URL: https://issues.jboss.org/browse/WFLY-1435
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
>
> The mod cluster subsystem is not starting correctly due to missing (incorrect) dependencies on JBoss Web:
> {noformat}
> 16:59:36,549 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 33) JBAS010280: Activating Infinispan subsystem.
> 16:59:36,561 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 37) JBAS010260: Activating JGroups subsystem.
> [snip]
> 16:59:36,639 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Alpha15 starting
> 16:59:36,654 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 52) JBAS015537: Activating WebServices Extension
> 16:59:36,657 INFO [org.jboss.as.naming] (MSC service thread 1-4) JBAS011802: Starting Naming Service
> 16:59:36,661 INFO [org.jboss.as.mail.extension] (MSC service thread 1-8) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 16:59:36,669 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017502: Undertow 1.0.0.Alpha15 starting
> 16:59:36,755 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.0.Beta1
> 16:59:36,760 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 28) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 16:59:36,771 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) JBAS010417: Started Driver service with driver-name = h2
> 16:59:36,816 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting server server service: service jboss.undertow.server.default-server
> 16:59:36,839 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting host default-host
> 16:59:36,891 INFO [io.undertow] (ServerService Thread Pool -- 51) Creating file handler for path /home/nrla/projects/wildfly-git-repo/testsuite/integration/clust/target/wildfly-clustering-xsite-LON-0/welcome-content
> 16:59:36,904 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017525: Started http handler io.undertow.server.handlers.resource.ResourceHandler@26dce695.
> 16:59:36,905 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) registering handler org.jboss.msc.value.InjectedValue@ab2d3a9 under path '/'
> 16:59:36,927 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017519: Undertow AJP listener ajp-connector listening on /127.0.0.1:8009
> 16:59:36,926 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080
> 16:59:37,252 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 16:59:37,262 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 16:59:37,291 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 16:59:37,478 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 127.0.0.1:9999
> 16:59:37,479 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) JBAS015012: Started FileSystemDeploymentService for directory /home/nrla/projects/wildfly-git-repo/testsuite/integration/clust/target/wildfly-clustering-xsite-LON-0/standalone/deployments
> 16:59:37,478 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:4447
> 16:59:37,507 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "modcluster")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.mod-cluster is missing [jboss.web, jboss.web.connector.ajp]"]}
> 16:59:37,571 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.web (missing) dependents: [service jboss.mod-cluster]
> service jboss.web.connector.ajp (missing) dependents: [service jboss.mod-cluster]
> 16:59:37,706 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 16:59:37,707 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 16:59:37,707 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" started (with errors) in 3027ms - Started 157 of 252 services (1 services failed or missing dependencies, 116 services are lazy, passive or on-demand)
> {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
10 years, 10 months
[JBoss JIRA] (WFLY-1435) Modcluster subsystem startup missing required dependencies from JBoss Web
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-1435?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-1435:
------------------------------------
This is a known issue. The mod_cluster subsystem is in the process of being refactored to work with both the undertow and web subsystems. See WFLY-381.
> Modcluster subsystem startup missing required dependencies from JBoss Web
> --------------------------------------------------------------------------
>
> Key: WFLY-1435
> URL: https://issues.jboss.org/browse/WFLY-1435
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
>
> The mod cluster subsystem is not starting correctly due to missing (incorrect) dependencies on JBoss Web:
> {noformat}
> 16:59:36,549 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 33) JBAS010280: Activating Infinispan subsystem.
> 16:59:36,561 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 37) JBAS010260: Activating JGroups subsystem.
> [snip]
> 16:59:36,639 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Alpha15 starting
> 16:59:36,654 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 52) JBAS015537: Activating WebServices Extension
> 16:59:36,657 INFO [org.jboss.as.naming] (MSC service thread 1-4) JBAS011802: Starting Naming Service
> 16:59:36,661 INFO [org.jboss.as.mail.extension] (MSC service thread 1-8) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 16:59:36,669 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017502: Undertow 1.0.0.Alpha15 starting
> 16:59:36,755 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.0.Beta1
> 16:59:36,760 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 28) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 16:59:36,771 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) JBAS010417: Started Driver service with driver-name = h2
> 16:59:36,816 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting server server service: service jboss.undertow.server.default-server
> 16:59:36,839 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting host default-host
> 16:59:36,891 INFO [io.undertow] (ServerService Thread Pool -- 51) Creating file handler for path /home/nrla/projects/wildfly-git-repo/testsuite/integration/clust/target/wildfly-clustering-xsite-LON-0/welcome-content
> 16:59:36,904 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017525: Started http handler io.undertow.server.handlers.resource.ResourceHandler@26dce695.
> 16:59:36,905 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) registering handler org.jboss.msc.value.InjectedValue@ab2d3a9 under path '/'
> 16:59:36,927 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017519: Undertow AJP listener ajp-connector listening on /127.0.0.1:8009
> 16:59:36,926 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080
> 16:59:37,252 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 16:59:37,262 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 16:59:37,291 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 16:59:37,478 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 127.0.0.1:9999
> 16:59:37,479 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) JBAS015012: Started FileSystemDeploymentService for directory /home/nrla/projects/wildfly-git-repo/testsuite/integration/clust/target/wildfly-clustering-xsite-LON-0/standalone/deployments
> 16:59:37,478 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:4447
> 16:59:37,507 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "modcluster")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.mod-cluster is missing [jboss.web, jboss.web.connector.ajp]"]}
> 16:59:37,571 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.web (missing) dependents: [service jboss.mod-cluster]
> service jboss.web.connector.ajp (missing) dependents: [service jboss.mod-cluster]
> 16:59:37,706 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 16:59:37,707 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 16:59:37,707 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" started (with errors) in 3027ms - Started 157 of 252 services (1 services failed or missing dependencies, 116 services are lazy, passive or on-demand)
> {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
10 years, 10 months
[JBoss JIRA] (WFLY-463) Add utility for creating and destorying modules in tests
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-463?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on WFLY-463:
-------------------------------------
An example is org.jboss.as.test.integration.weld.multideployment.WeldModuleDeploymentTestCase
there are please of other tests that do the same thing. We also need to make sure that these modules are not being added to build/target, but rather to testsuite/target/jbossas.
At the moment we end up with some additional empty directories under build/target after the testsuite runs.
> Add utility for creating and destorying modules in tests
> --------------------------------------------------------
>
> Key: WFLY-463
> URL: https://issues.jboss.org/browse/WFLY-463
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Stuart Douglas
> Assignee: Ondrej Zizka
> Fix For: 8.0.0.Alpha2
>
>
> Lots of tests create and destroy a static module to test functionaility involving static modules. If possible all this code should be moved into some kind of static module builder utility.
--
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
10 years, 10 months