[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
12 years, 11 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
12 years, 11 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
12 years, 11 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
12 years, 11 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
12 years, 11 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
12 years, 11 months
[JBoss JIRA] (JASSIST-201) VerifyError: Inconsistent args_size for opc_invokeinterface occured for nested statement
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-201?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-201.
---------------------------------
> VerifyError: Inconsistent args_size for opc_invokeinterface occured for nested statement
> ----------------------------------------------------------------------------------------
>
> Key: JASSIST-201
> URL: https://issues.jboss.org/browse/JASSIST-201
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.1-GA
> Environment: Sun JRE6 1.6.0_25 64bits
> Reporter: Hua Zhang
> Assignee: Shigeru Chiba
> Priority: Critical
> Labels: VerifyError, nested, opc_invokeinterface
> Fix For: 3.18.0-GA
>
>
> Please see source in "steps to reproduce".
> Running the code will throw error:
> Exception in thread "main" java.lang.VerifyError: (class: Clazz, method: method signature: ()V) Inconsistent args_size for opc_invokeinterface
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
> at java.lang.Class.getConstructors(Unknown Source)
> at test.<init>(test.java:27)
> at test.main(test.java:31)
> The key is on "new HashMap().toString()" in the statement:
> theMethod.setBody("{map.put(\"name\", new HashMap().toString());System.out.println(\"OK\");}");
> The behaviour is really strange. Try to modify it, sometimes it can be run successfully, sometimes failed. But they all can be compiled successfully.
> FAILED:
> theMethod.setBody("{StringBuffer buffer = new StringBuffer();map.put(\"name\", buffer.toString());System.out.println(\"OK\");}");
> SUCCESS:
> theMethod.setBody("{map.put(\"name\", map.toString());System.out.println(\"OK\");}");
> SUCCESS: (workaround)
> theMethod.setBody("{String V = new HashMap().toString();map.put(\"name\", V);System.out.println(\"OK\");}");
--
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
12 years, 11 months
[JBoss JIRA] (JASSIST-188) CtClass detach does not completely clean class from pool.
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-188?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-188.
---------------------------------
> CtClass detach does not completely clean class from pool.
> ---------------------------------------------------------
>
> Key: JASSIST-188
> URL: https://issues.jboss.org/browse/JASSIST-188
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.17.0-GA
> Environment: Ubuntu, Windows, JDK 1.6/1.7
> Reporter: J D
> Assignee: Shigeru Chiba
> Priority: Critical
> Fix For: 3.18.0-GA
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Description:
> Class with same qualified name cannot be recreated even if previous class was detached successfully from pool.
> Creation#1: Consider class eg.foo.MyClass is created using default pool and private int myArg1 private member along with some getter/setter methods. After its creation, the CtClass.detach is invoked successfully.
> Creation#2: Subsequently, create eg.foo.MyClass using same default pool succeeds but any attempt to add members e.g. private int myArg1 fails with error:
> Field myArg1 in eg.foo.MyClass is private.
> Bug Analysis:
> MemberCodeGen.isAccessibleField has f.getDeclaringClass from Creation#1 but thisClass is from Creation#2. This was traced to MemberResolver.invalidNamesMap. When Creation#1 detached the CtClass, it got removed from pool but not from the invalidNamesMap for default pool. Subsequently when MemberResolver.lookupClass looks for "eg.foo.MyClass", the Creation#1's CtClass gets returned. This is a bug because that class was detached earlier and must not be reused for any processing - we are creating another instance because a new definition is needed for that class.
> The bug is critical as erroneous unintended cached class definitions could be used even when not intended leading to potentially very severe runtime problems. Remember that cache is a good only if it accurately provided cached results. In this case, stale/incorrect results will be returned.
> Proposed Fix:
> Add a static method detachInvalidNames in MemberResolver that removes a qualified class-name from invalidNamesMap for that class's pool. CtClass.detach must invoke this detachInvalidNames.
--
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
12 years, 11 months