January 2015 - mod_cluster-issues

[JBoss JIRA] (MODCLUSTER-448) mod_cluster crashes apache thread if multiple nodes report the same AJP connect string

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-448?page=com.atlassian.jira.pl... ] Michal Babacek updated MODCLUSTER-448: -------------------------------------- Description: Reported on behalf of [Toby Murray|https://github.com/ToeBee]: Tracking issue #[138|https://github.com/modcluster/mod_cluster/issues/138] Let's carry on with any discussion here, on JIRA... was: Reported on behalf of [Toby Murray|https://github.com/ToeBee]: Tracking issue #[138|https://github.com/modcluster/mod_cluster/issues/138] > mod_cluster crashes apache thread if multiple nodes report the same AJP connect string > -------------------------------------------------------------------------------------- > > Key: MODCLUSTER-448 > URL: https://issues.jboss.org/browse/MODCLUSTER-448 > Project: mod_cluster > Issue Type: Feature Request > Components: Native (httpd modules) > Affects Versions: 1.2.6.Final > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > > Reported on behalf of [Toby Murray|https://github.com/ToeBee]: > Tracking issue #[138|https://github.com/modcluster/mod_cluster/issues/138] > Let's carry on with any discussion here, on JIRA... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-448) mod_cluster crashes apache thread if multiple nodes report the same AJP connect string

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-448?page=com.atlassian.jira.pl... ] Michal Babacek updated MODCLUSTER-448: -------------------------------------- Component/s: Native (httpd modules) > mod_cluster crashes apache thread if multiple nodes report the same AJP connect string > -------------------------------------------------------------------------------------- > > Key: MODCLUSTER-448 > URL: https://issues.jboss.org/browse/MODCLUSTER-448 > Project: mod_cluster > Issue Type: Feature Request > Components: Native (httpd modules) > Affects Versions: 1.2.6.Final > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > > Reported on behalf of [Toby Murray|https://github.com/ToeBee]: > Tracking issue #[138|https://github.com/modcluster/mod_cluster/issues/138] -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-448) mod_cluster crashes apache thread if multiple nodes report the same AJP connect string

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-448?page=com.atlassian.jira.pl... ] Michal Babacek updated MODCLUSTER-448: -------------------------------------- Affects Version/s: 1.2.6.Final > mod_cluster crashes apache thread if multiple nodes report the same AJP connect string > -------------------------------------------------------------------------------------- > > Key: MODCLUSTER-448 > URL: https://issues.jboss.org/browse/MODCLUSTER-448 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.6.Final > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > > Reported on behalf of [Toby Murray|https://github.com/ToeBee]: > Tracking issue #[138|https://github.com/modcluster/mod_cluster/issues/138] -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-448) mod_cluster crashes apache thread if multiple nodes report the same AJP connect string

by Michal Babacek (JIRA)

Michal Babacek created MODCLUSTER-448: ----------------------------------------- Summary: mod_cluster crashes apache thread if multiple nodes report the same AJP connect string Key: MODCLUSTER-448 URL: https://issues.jboss.org/browse/MODCLUSTER-448 Project: mod_cluster Issue Type: Feature Request Reporter: Michal Babacek Assignee: Jean-Frederic Clere Reported on behalf of [Toby Murray|https://github.com/ToeBee]: Tracking issue #[138|https://github.com/modcluster/mod_cluster/issues/138] -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-442) Can't build mod_cluster from master

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-442?page=com.atlassian.jira.pl... ] Radoslav Husar closed MODCLUSTER-442. ------------------------------------- Resolution: Rejected > Can't build mod_cluster from master > ----------------------------------- > > Key: MODCLUSTER-442 > URL: https://issues.jboss.org/browse/MODCLUSTER-442 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.1.Alpha2 > Reporter: Maxime Beck > Assignee: Radoslav Husar > > When trying to build mod_cluster from it's github repository (version 1.3.1.Alpha2), I get two failures on the core module as seen bellow. > $ mvn install > ++++ > Results : > Failed tests: > AdvertiseListenerImplTestCase.testBasicOperation:135 > Wanted but not invoked: > mCMPHandler.addProxy(<Capturing argument>); > -> at org.jboss.modcluster.advertise.AdvertiseListenerImplTestCase.testBasicOperation(AdvertiseListenerImplTestCase.java:135) > Actually, there were zero interactions with this mock. > MulticastSocketFactoryImplTestCase.testMulticastSocketNoCrossTalk:63->testMulticastSocket:112 null > Tests run: 46, Failures: 2, Errors: 0, Skipped: 0 > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] mod_cluster (parent) ............................... SUCCESS [ 0.618 s] > [INFO] mod_cluster: Container SPI ......................... SUCCESS [ 0.412 s] > [INFO] mod_cluster: Core .................................. FAILURE [ 4.163 s] > [INFO] mod_cluster: Container (parent) .................... SKIPPED > [INFO] mod_cluster: Container - Catalina .................. SKIPPED > [INFO] mod_cluster: Container - Catalina (standalone) ..... SKIPPED > [INFO] mod_cluster: Container - Tomcat 6 .................. SKIPPED > [INFO] mod_cluster: Container - Tomcat 7 .................. SKIPPED > [INFO] mod_cluster: Container - Tomcat 8 .................. SKIPPED > [INFO] mod_cluster: Container - JBoss Web ................. SKIPPED > [INFO] mod_cluster: Demo (parent) ......................... SKIPPED > [INFO] mod_cluster: Demo - Client ......................... SKIPPED > [INFO] mod_cluster: Demo - Server ......................... SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 5.506 s > [INFO] Finished at: 2014-11-12T18:04:39+01:00 > [INFO] Final Memory: 15M/298M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project mod_cluster-core: There are test failures. > [ERROR] > [ERROR] Please refer to /home/mbeck/dev/mod_cluster/core/target/surefire-reports for the individual test results. > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn <goals> -rf :mod_cluster-core > +++ -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-442) Can't build mod_cluster from master

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-442?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-442: -------------------------------------- Labels: (was: mod_cluster) > Can't build mod_cluster from master > ----------------------------------- > > Key: MODCLUSTER-442 > URL: https://issues.jboss.org/browse/MODCLUSTER-442 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.1.Alpha2 > Reporter: Maxime Beck > Assignee: Radoslav Husar > > When trying to build mod_cluster from it's github repository (version 1.3.1.Alpha2), I get two failures on the core module as seen bellow. > $ mvn install > ++++ > Results : > Failed tests: > AdvertiseListenerImplTestCase.testBasicOperation:135 > Wanted but not invoked: > mCMPHandler.addProxy(<Capturing argument>); > -> at org.jboss.modcluster.advertise.AdvertiseListenerImplTestCase.testBasicOperation(AdvertiseListenerImplTestCase.java:135) > Actually, there were zero interactions with this mock. > MulticastSocketFactoryImplTestCase.testMulticastSocketNoCrossTalk:63->testMulticastSocket:112 null > Tests run: 46, Failures: 2, Errors: 0, Skipped: 0 > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] mod_cluster (parent) ............................... SUCCESS [ 0.618 s] > [INFO] mod_cluster: Container SPI ......................... SUCCESS [ 0.412 s] > [INFO] mod_cluster: Core .................................. FAILURE [ 4.163 s] > [INFO] mod_cluster: Container (parent) .................... SKIPPED > [INFO] mod_cluster: Container - Catalina .................. SKIPPED > [INFO] mod_cluster: Container - Catalina (standalone) ..... SKIPPED > [INFO] mod_cluster: Container - Tomcat 6 .................. SKIPPED > [INFO] mod_cluster: Container - Tomcat 7 .................. SKIPPED > [INFO] mod_cluster: Container - Tomcat 8 .................. SKIPPED > [INFO] mod_cluster: Container - JBoss Web ................. SKIPPED > [INFO] mod_cluster: Demo (parent) ......................... SKIPPED > [INFO] mod_cluster: Demo - Client ......................... SKIPPED > [INFO] mod_cluster: Demo - Server ......................... SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 5.506 s > [INFO] Finished at: 2014-11-12T18:04:39+01:00 > [INFO] Final Memory: 15M/298M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project mod_cluster-core: There are test failures. > [ERROR] > [ERROR] Please refer to /home/mbeck/dev/mod_cluster/core/target/surefire-reports for the individual test results. > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn <goals> -rf :mod_cluster-core > +++ -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-442) Can't build mod_cluster from master

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-442?page=com.atlassian.jira.pl... ] Radoslav Husar reopened MODCLUSTER-442: --------------------------------------- > Can't build mod_cluster from master > ----------------------------------- > > Key: MODCLUSTER-442 > URL: https://issues.jboss.org/browse/MODCLUSTER-442 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.1.Alpha2 > Reporter: Maxime Beck > Assignee: Radoslav Husar > > When trying to build mod_cluster from it's github repository (version 1.3.1.Alpha2), I get two failures on the core module as seen bellow. > $ mvn install > ++++ > Results : > Failed tests: > AdvertiseListenerImplTestCase.testBasicOperation:135 > Wanted but not invoked: > mCMPHandler.addProxy(<Capturing argument>); > -> at org.jboss.modcluster.advertise.AdvertiseListenerImplTestCase.testBasicOperation(AdvertiseListenerImplTestCase.java:135) > Actually, there were zero interactions with this mock. > MulticastSocketFactoryImplTestCase.testMulticastSocketNoCrossTalk:63->testMulticastSocket:112 null > Tests run: 46, Failures: 2, Errors: 0, Skipped: 0 > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] mod_cluster (parent) ............................... SUCCESS [ 0.618 s] > [INFO] mod_cluster: Container SPI ......................... SUCCESS [ 0.412 s] > [INFO] mod_cluster: Core .................................. FAILURE [ 4.163 s] > [INFO] mod_cluster: Container (parent) .................... SKIPPED > [INFO] mod_cluster: Container - Catalina .................. SKIPPED > [INFO] mod_cluster: Container - Catalina (standalone) ..... SKIPPED > [INFO] mod_cluster: Container - Tomcat 6 .................. SKIPPED > [INFO] mod_cluster: Container - Tomcat 7 .................. SKIPPED > [INFO] mod_cluster: Container - Tomcat 8 .................. SKIPPED > [INFO] mod_cluster: Container - JBoss Web ................. SKIPPED > [INFO] mod_cluster: Demo (parent) ......................... SKIPPED > [INFO] mod_cluster: Demo - Client ......................... SKIPPED > [INFO] mod_cluster: Demo - Server ......................... SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 5.506 s > [INFO] Finished at: 2014-11-12T18:04:39+01:00 > [INFO] Final Memory: 15M/298M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project mod_cluster-core: There are test failures. > [ERROR] > [ERROR] Please refer to /home/mbeck/dev/mod_cluster/core/target/surefire-reports for the individual test results. > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn <goals> -rf :mod_cluster-core > +++ -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-442) Can't build mod_cluster from master

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-442?page=com.atlassian.jira.pl... ] Radoslav Husar closed MODCLUSTER-442. ------------------------------------- Resolution: Rejected The test is currently disabled and needs to be verified before final release MODCLUSTER-432. https://github.com/modcluster/mod_cluster/blob/master/core/src/test/java/... > Can't build mod_cluster from master > ----------------------------------- > > Key: MODCLUSTER-442 > URL: https://issues.jboss.org/browse/MODCLUSTER-442 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.1.Alpha2 > Reporter: Maxime Beck > Assignee: Radoslav Husar > Labels: mod_cluster > > When trying to build mod_cluster from it's github repository (version 1.3.1.Alpha2), I get two failures on the core module as seen bellow. > $ mvn install > ++++ > Results : > Failed tests: > AdvertiseListenerImplTestCase.testBasicOperation:135 > Wanted but not invoked: > mCMPHandler.addProxy(<Capturing argument>); > -> at org.jboss.modcluster.advertise.AdvertiseListenerImplTestCase.testBasicOperation(AdvertiseListenerImplTestCase.java:135) > Actually, there were zero interactions with this mock. > MulticastSocketFactoryImplTestCase.testMulticastSocketNoCrossTalk:63->testMulticastSocket:112 null > Tests run: 46, Failures: 2, Errors: 0, Skipped: 0 > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] mod_cluster (parent) ............................... SUCCESS [ 0.618 s] > [INFO] mod_cluster: Container SPI ......................... SUCCESS [ 0.412 s] > [INFO] mod_cluster: Core .................................. FAILURE [ 4.163 s] > [INFO] mod_cluster: Container (parent) .................... SKIPPED > [INFO] mod_cluster: Container - Catalina .................. SKIPPED > [INFO] mod_cluster: Container - Catalina (standalone) ..... SKIPPED > [INFO] mod_cluster: Container - Tomcat 6 .................. SKIPPED > [INFO] mod_cluster: Container - Tomcat 7 .................. SKIPPED > [INFO] mod_cluster: Container - Tomcat 8 .................. SKIPPED > [INFO] mod_cluster: Container - JBoss Web ................. SKIPPED > [INFO] mod_cluster: Demo (parent) ......................... SKIPPED > [INFO] mod_cluster: Demo - Client ......................... SKIPPED > [INFO] mod_cluster: Demo - Server ......................... SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 5.506 s > [INFO] Finished at: 2014-11-12T18:04:39+01:00 > [INFO] Final Memory: 15M/298M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project mod_cluster-core: There are test failures. > [ERROR] > [ERROR] Please refer to /home/mbeck/dev/mod_cluster/core/target/surefire-reports for the individual test results. > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn <goals> -rf :mod_cluster-core > +++ -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-443) mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-443?page=com.atlassian.jira.pl... ] Michal Babacek updated MODCLUSTER-443: -------------------------------------- Bugzilla Update: (was: Perform) > mod_cluster doesn't recognize ; as a proper context delimiter causing 404s on requests with URL jsessionids > ----------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-443 > URL: https://issues.jboss.org/browse/MODCLUSTER-443 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.9.Final, 1.3.1.Alpha2 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Beta1, 1.2.11.Final > > > This is similar to MODCLUSTER-328, but in regards to ; instead of ?. > mod_cluster does not recognize ; as a delimiter when checking the request context. Thus with no trailing slash on index page requests, it treats ;jsessionid as part of the request context and tries to check the balancer for a deployed context of /helloworld;jsessionid=..., which doesn't exist and 404s. Adding the trailing slash, mod_cluster can properly delimit this and then sees the context (so /helloworld/;jsessionid=... works just fine). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-399) Draining pending requests fails with Oracle JDK8

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-399?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-399: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1161079|https://bugzilla.redhat.com/show_bug.cgi?id=1161079] from ON_QA to VERIFIED > Draining pending requests fails with Oracle JDK8 > ------------------------------------------------ > > Key: MODCLUSTER-399 > URL: https://issues.jboss.org/browse/MODCLUSTER-399 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.8.Final > Environment: RHEL7 x86_64, Apache/2.2.26 (Red Hat Enterprise Web Server), Oracle JDK 8 > Reporter: Michal Babacek > Assignee: Radoslav Husar > Attachments: 1-access_log.zip, 1-error_log.zip, 1-server.log, 2-access_log.zip, 2-error_log.zip, 2-server.log, 3-access_log.zip, 3-error_log.zip, 3-server.log, 4-access_log.zip, 4-error_log.zip, 4-server.log, 5-access_log.zip, 5-error_log.zip, 5-server.log, clusterbench.war, Flood.py, JDK7-JDK8.log, mod_cluster.conf, simplecontext-666.war, standalone-ha.xml, trace-logs-jdk17AndJdk18.zip > > > I've noticed several tests that run O.K. with Oracle JDK7 and fail with Oracle JDK8. One can reproduce these failures anytime, they are not just random glitches. > Notes on the setup: > * {{simplecontext-666}} is a simple JSP web app, non-distributable > * {{clusterbench}} is a distributable webapp > * all the tests use 1 worker node and 1 balancer > * many clients throwing many requests at the {{simplecontext-666}} context > h3. Stop Context Timeout test > First, there is the setup with {{stop-context-timeout="20"}}: > {code} > <subsystem xmlns="urn:jboss:domain:modcluster:1.2"> > <mod-cluster-config advertise-socket="modcluster" stop-context-timeout="20" connector="ajp"> > <dynamic-load-provider> > <load-metric type="busyness"/> > </dynamic-load-provider> > </mod-cluster-config> > </subsystem> > {code} > On *JDK7*, one may observe exactly the desired behavior. On a clean shutdown, message {{Failed to drain 294 remaining pending requests from default-host:/simplecontext-666 within 20.0 seconds}} is displayed. See the whole log here: [^1-server.log]. > {noformat} > [org.jboss.web] (ServerService Thread Pool -- 22) JBAS018224: Unregister web context: /simplecontext-666 > [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment simplecontext-666.war (runtime-name: simplecontext-666.war) in 284ms > [org.jboss.modcluster] (ServerService Thread Pool -- 9) MODCLUSTER000024: All active sessions drained from default-host:/simplecontext-666 in 20.0 seconds > [org.jboss.modcluster] (ServerService Thread Pool -- 9) MODCLUSTER000022: Failed to drain 294 remaining pending requests from default-host:/simplecontext-666 within 20.0 seconds > [org.jboss.modcluster] (ServerService Thread Pool -- 9) MODCLUSTER000002: Initiating mod_cluster shutdown > [org.apache.coyote.ajp] (MSC service thread 1-8) JBWEB003048: Pausing Coyote AJP/1.3 on ajp-/10.16.88.17:8009 > [org.apache.coyote.ajp] (MSC service thread 1-8) JBWEB003051: Stopping Coyote AJP/1.3 on ajp-/10.16.88.17:8009 > [org.jboss.as] (MSC service thread 1-11) JBAS015950: JBoss EAP 6.3.0.Alpha2 (AS 7.4.0.Final-redhat-6) stopped in 20035ms > {noformat} > On the other hand, with *JDK8*, this utterly fails. No waiting for pending requests, no message. See the whole log here: [^2-server.log]. > {noformat} > [org.jboss.web] (ServerService Thread Pool -- 18) JBAS018224: Unregister web context: /simplecontext-666 > [org.apache.tomcat.util] (http-/10.16.88.17:8080-Acceptor) JBWEB003022: Channel processing failed > [org.jboss.modcluster] (ServerService Thread Pool -- 16) MODCLUSTER000002: Initiating mod_cluster shutdown > [org.apache.coyote.ajp] (MSC service thread 1-13) JBWEB003048: Pausing Coyote AJP/1.3 on ajp-/10.16.88.17:8009 > [org.apache.coyote.ajp] (MSC service thread 1-13) JBWEB003051: Stopping Coyote AJP/1.3 on ajp-/10.16.88.17:8009 > [org.jboss.as.server.deployment] (MSC service thread 1-10) JBAS015877: Stopped deployment simplecontext-666.war (runtime-name: simplecontext-666.war) in 310ms > [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.3.0.Alpha2 (AS 7.4.0.Final-redhat-6) stopped in 348ms > {noformat} > These are the Apache HTTP Server logs, showing exactly what was the test doing: > Note that thousands of {{"GET /simplecontext-666/ HTTP/1.1"}} messages were omitted from these snippets. > *JDK7*, access_log, (See the complete log here [^1-access_log.zip]) > {noformat} > [06:47:04] "GET /mcm HTTP/1.1" 200 446 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)" > [06:47:12] "INFO / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:47:12] "CONFIG / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:47:12] "ENABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:47:12] "ENABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:47:12] "STATUS / HTTP/1.1" 200 60 "-" "ClusterListener/1.0" > [06:47:13] "GET /mcm HTTP/1.1" 200 1916 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)" > [06:47:19] "DISABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:47:19] "DISABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:47:20] "STOP-APP / HTTP/1.1" 200 84 "-" "ClusterListener/1.0" > [06:47:40] "STOP-APP / HTTP/1.1" 200 86 "-" "ClusterListener/1.0" > [06:47:40] "REMOVE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:47:40] "REMOVE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:47:40] "REMOVE-APP /* HTTP/1.1" 200 - "-" "ClusterListener/1.0" > {noformat} > *JDK8*, access_log, (See the complete log here [^2-access_log.zip]) > {noformat} > [06:43:10] "GET /mcm HTTP/1.1" 200 446 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)" > [06:43:17] "INFO / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:43:17] "CONFIG / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:43:17] "ENABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:43:17] "ENABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:43:17] "STATUS / HTTP/1.1" 200 62 "-" "ClusterListener/1.0" > [06:43:19] "GET /mcm HTTP/1.1" 200 1916 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)" > [06:43:25] "DISABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:43:25] "STOP-APP / HTTP/1.1" 200 84 "-" "ClusterListener/1.0" > [06:43:25] "REMOVE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:43:25] "REMOVE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [06:43:25] "REMOVE-APP /* HTTP/1.1" 200 - "-" "ClusterListener/1.0" > {noformat} > In the aforementioned snippets, it is noteworthy that the *JDK8* run sent only one {{STOP-APP}} message. This is confirmed in error logs: > *JDK7*, error_log, {{grep STOP-APP}} (See the complete log here [^1-error_log.zip]) > {noformat} > [06:47:20] mod_manager.c(1901): manager_trans STOP-APP (/) > [06:47:20] mod_manager.c(2617): manager_handler STOP-APP (/) processing: "JVMRoute=jboss-eap-6.3&Alias=default-host%2Clocalhost%2Cexample.com&Context=%2Fclusterbench" > [06:47:20] mod_manager.c(1429): process_appl_cmd: STOP-APP nbrequests 0 > [06:47:20] mod_manager.c(2666): manager_handler STOP-APP OK > [06:47:40] mod_manager.c(1901): manager_trans STOP-APP (/) > [06:47:40] mod_manager.c(2617): manager_handler STOP-APP (/) processing: "JVMRoute=jboss-eap-6.3&Alias=default-host%2Clocalhost%2Cexample.com&Context=%2Fsimplecontext-666" > [06:47:40] mod_manager.c(1429): process_appl_cmd: STOP-APP nbrequests 294 > [06:47:40] mod_manager.c(2666): manager_handler STOP-APP OK > {noformat} > *JDK8*, error_log, {{grep STOP-APP}} (See the complete log here [^2-error_log.zip]) > {noformat} > [06:43:25] mod_manager.c(1901): manager_trans STOP-APP (/) > [06:43:25] mod_manager.c(2617): manager_handler STOP-APP (/) processing: "JVMRoute=jboss-eap-6.3&Alias=default-host%2Clocalhost%2Cexample.com&Context=%2Fclusterbench" > [06:43:25] mod_manager.c(1429): process_appl_cmd: STOP-APP nbrequests 0 > [06:43:25] mod_manager.c(2666): manager_handler STOP-APP OK > {noformat} > One could argue that there was a test error and the *JDK8* test run actually didn't access {{simplecontext-666}} application. Let me dissolve this argument right away: > {noformat} > grep -c "GET /simplecontext-666/ HTTP/1.1\" 200" ./targetJDK8/httpd/logs/access_log > 27250 > grep -c "GET /simplecontext-666/ HTTP/1.1\" 200" ./targetJDK7/httpd/logs/access_log > 27927 > {noformat} > h3. Default settings, the same problem... > Trial with the default settings reveals the same problem with some additional findings in the Apache's error log. > {code} > <subsystem xmlns="urn:jboss:domain:modcluster:1.2"> > <mod-cluster-config advertise-socket="modcluster" connector="ajp"> > <dynamic-load-provider> > <load-metric type="busyness"/> > </dynamic-load-provider> > </mod-cluster-config> > </subsystem> > {code} > On *JDK7*, one may observe exactly the desired behavior, this time with the default 10 seconds timeout. See the whole log here: [^3-server.log]. > {noformat} > [org.jboss.web] (ServerService Thread Pool -- 3) JBAS018224: Unregister web context: /simplecontext-666 > [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment simplecontext-666.war (runtime-name: simplecontext-666.war) in 263ms > [org.jboss.modcluster] (ServerService Thread Pool -- 7) MODCLUSTER000024: All active sessions drained from default-host:/simplecontext-666 in 10.0 seconds > [org.jboss.modcluster] (ServerService Thread Pool -- 7) MODCLUSTER000022: Failed to drain 340 remaining pending requests from default-host:/simplecontext-666 within 10.0 seconds > [org.jboss.modcluster] (ServerService Thread Pool -- 7) MODCLUSTER000002: Initiating mod_cluster shutdown > [org.apache.coyote.ajp] (MSC service thread 1-13) JBWEB003048: Pausing Coyote AJP/1.3 on ajp-/10.16.88.17:8009 > [org.apache.coyote.ajp] (MSC service thread 1-13) JBWEB003051: Stopping Coyote AJP/1.3 on ajp-/10.16.88.17:8009 > [org.jboss.as] (MSC service thread 1-9) JBAS015950: JBoss EAP 6.3.0.Alpha2 (AS 7.4.0.Final-redhat-6) stopped in 10082ms > {noformat} > *JDK8* fails. No waiting for pending requests, no message. This time even with ISE :(. See the whole log here: [^4-server.log]. > {noformat} > [org.jboss.web] (ServerService Thread Pool -- 16) JBAS018224: Unregister web context: /simplecontext-666 > [org.jboss.modcluster] (ServerService Thread Pool -- 19) MODCLUSTER000021: All pending requests drained from default-host:/clusterbench in 0.0 seconds > [org.jboss.as.txn] (ajp-/10.16.88.17:8009-21) JBAS010151: Unable to get transaction state: java.lang.IllegalStateException > at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) > at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.checkTransactionStatus(TransactionRollbackSetupAction.java:112) > at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.teardown(TransactionRollbackSetupAction.java:66) > at org.jboss.as.web.ThreadSetupBindingListener.unbind(ThreadSetupBindingListener.java:61) [jboss-as-web-7.4.0.Final-redhat-6.jar:7.4.0.Final-redhat-6] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:184) [jbossweb-7.4.0.Final.jar:7.4.0.Final] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.0.Final.jar:7.4.0.Final] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.0.Final.jar:7.4.0.Final] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340) [jbossweb-7.4.0.Final.jar:7.4.0.Final] > at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490) [jbossweb-7.4.0.Final.jar:7.4.0.Final] > at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420) [jbossweb-7.4.0.Final.jar:7.4.0.Final] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.0.Final.jar:7.4.0.Final] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > +++ > [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment simplecontext-666.war (runtime-name: simplecontext-666.war) in 301ms > [org.jboss.as] (MSC service thread 1-15) JBAS015950: JBoss EAP 6.3.0.Alpha2 (AS 7.4.0.Final-redhat-6) stopped in 313ms > {noformat} > In the access logs, it is noteworthy that both {{clusterbench}} and {{simplecontext-666}} sent {{ENABLE-APP}}, but there was only one {{STOP-APP}} message. Furthermore, who and why used {{OPTIONS}} method? > *JDK7*, access_log, (See the complete log here [^3-access_log.zip]) > Note that thousands of {{"GET /simplecontext-666/ HTTP/1.1"}} messages were omitted from these snippets. > {noformat} > [07:31:49] "GET /mcm HTTP/1.1" 200 446 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)" > [07:31:57] "INFO / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:31:57] "CONFIG / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:31:57] "ENABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:31:57] "ENABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:31:57] "STATUS / HTTP/1.1" 200 63 "-" "ClusterListener/1.0" > [07:31:58] "GET /mcm HTTP/1.1" 200 1916 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)" > [07:32:05] "DISABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:32:14] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.26 (Red Hat Enterprise Web Server) (internal dummy connection)" > [07:32:15] "STOP-APP / HTTP/1.1" 200 86 "-" "ClusterListener/1.0" > [07:32:15] "REMOVE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:32:15] "REMOVE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:32:15] "REMOVE-APP /* HTTP/1.1" 200 - "-" "ClusterListener/1.0" > {noformat} > *JDK8*, access_log, (See the complete log here [^4-access_log.zip]) > {noformat} > [07:29:25] "GET /mcm HTTP/1.1" 200 446 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)" > [07:29:32] "INFO / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:29:32] "CONFIG / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:29:32] "ENABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:29:32] "ENABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:29:32] "STATUS / HTTP/1.1" 200 63 "-" "ClusterListener/1.0" > [07:29:34] "GET /mcm HTTP/1.1" 200 1916 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)" > [07:29:40] "DISABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:29:40] "STOP-APP / HTTP/1.1" 200 84 "-" "ClusterListener/1.0" > [07:29:40] "REMOVE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:29:40] "REMOVE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:29:40] "REMOVE-APP /* HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:29:40] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.26 (Red Hat Enterprise Web Server) (internal dummy connection)" > {noformat} > Error log shows what context was the {{STOP-APP}} message linked to: > *JDK7*, error_log, {{grep STOP-APP}} (See the complete log here [^3-error_log.zip]) > {noformat} > [07:32:15] mod_manager.c(1901): manager_trans STOP-APP (/) > [07:32:15] mod_manager.c(2617): manager_handler STOP-APP (/) processing: "JVMRoute=jboss-eap-6.3&Alias=default-host%2Clocalhost%2Cexample.com&Context=%2Fsimplecontext-666" > [07:32:15] mod_manager.c(1429): process_appl_cmd: STOP-APP nbrequests 340 > [07:32:15] mod_manager.c(2666): manager_handler STOP-APP OK > {noformat} > *JDK8*, error_log, {{grep STOP-APP}} (See the complete log here [^4-error_log.zip]) > {noformat} > [07:29:40] mod_manager.c(1901): manager_trans STOP-APP (/) > [07:29:40] mod_manager.c(2617): manager_handler STOP-APP (/) processing: "JVMRoute=jboss-eap-6.3&Alias=default-host%2Clocalhost%2Cexample.com&Context=%2Fclusterbench" > [07:29:40] mod_manager.c(1429): process_appl_cmd: STOP-APP nbrequests 0 > [07:29:40] mod_manager.c(2666): manager_handler STOP-APP OK > {noformat} > h3. Default settings, again > I had considered the {{JBAS010151: Unable to get transaction state: java.lang.IllegalStateException}} being probably an unrelated glitch, so I tried the default test run with *JDK8* again. Test failed, yet this time without any exception. Nothing has changed since the last run as far as environment and configuration are concerned. > *JDK8* fails. No waiting for pending requests on {{/simplecontext-666}}. See the whole log here: [^5-server.log]. > {noformat} > [org.jboss.web] (ServerService Thread Pool -- 16) JBAS018224: Unregister web context: /clusterbench > [org.apache.catalina.core] (MSC service thread 1-6) JBWEB001079: Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started > [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-14) JBWEB003075: Coyote HTTP/1.1 pausing on: http-/10.16.88.17:8080 > [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-14) JBWEB003077: Coyote HTTP/1.1 stopping on : http-/10.16.88.17:8080 > [org.jboss.web] (ServerService Thread Pool -- 3) JBAS018224: Unregister web context: /simplecontext-666 > [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-15) JBAS010409: Unbound data source [java:jboss/datasources/ExampleDS] > [org.jboss.modcluster] (ServerService Thread Pool -- 16) MODCLUSTER000021: All pending requests drained from default-host:/clusterbench in 0.1 seconds > [org.jboss.modcluster] (ServerService Thread Pool -- 14) MODCLUSTER000021: All pending requests drained from default-host:/clusterbench in 0.1 seconds > [org.jboss.modcluster] (ServerService Thread Pool -- 14) MODCLUSTER000002: Initiating mod_cluster shutdown > [org.apache.coyote.ajp] (MSC service thread 1-1) JBWEB003048: Pausing Coyote AJP/1.3 on ajp-/10.16.88.17:8009 > [org.apache.coyote.ajp] (MSC service thread 1-1) JBWEB003051: Stopping Coyote AJP/1.3 on ajp-/10.16.88.17:8009 > [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 9) JBAS010282: Stopped repl cache from web container > [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 16) JBAS010282: Stopped default-host/clusterbench cache from web container > [org.jboss.as.server.deployment] (MSC service thread 1-13) JBAS015877: Stopped deployment simplecontext-666.war (runtime-name: simplecontext-666.war) in 306ms > [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment clusterbench.war (runtime-name: clusterbench.war) in 310ms > [org.jboss.as] (MSC service thread 1-16) JBAS015950: JBoss EAP 6.3.0.Alpha2 (AS 7.4.0.Final-redhat-6) stopped in 333ms > {noformat} > *JDK8*, access_log, (See the complete log here [^5-access_log.zip]) > {noformat} > [07:45:25] "GET /mcm HTTP/1.1" 200 446 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)" > [07:45:33] "INFO / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:45:33] "CONFIG / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:45:33] "ENABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:45:33] "ENABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:45:33] "STATUS / HTTP/1.1" 200 62 "-" "ClusterListener/1.0" > [07:45:34] "GET /mcm HTTP/1.1" 200 1916 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)" > [07:45:39] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.26 (Red Hat Enterprise Web Server) (internal dummy connection)" > [07:45:40] "DISABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:45:40] "DISABLE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:45:40] "STOP-APP / HTTP/1.1" 200 84 "-" "ClusterListener/1.0" > [07:45:40] "STOP-APP / HTTP/1.1" 200 84 "-" "ClusterListener/1.0" > [07:45:40] "REMOVE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:45:40] "REMOVE-APP / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:45:40] "REMOVE-APP /* HTTP/1.1" 200 - "-" "ClusterListener/1.0" > [07:45:40] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.26 (Red Hat Enterprise Web Server) (internal dummy connection)" > [07:45:41] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.26 (Red Hat Enterprise Web Server) (internal dummy connection)" > {noformat} > This time, there were two {{STOP-APP}} messages all right, but instead one of them being for {{clusterbench}} and the other one for {{simplecontext-666}}, they were both for {{clusterbench}}. I find this behavior being a rather disturbing one. > *JDK8*, error_log, {{grep STOP-APP}} (See the complete log here [^5-error_log.zip]) > {noformat} > [07:45:40] mod_manager.c(1901): manager_trans STOP-APP (/) > [07:45:40] mod_manager.c(2617): manager_handler STOP-APP (/) processing: "JVMRoute=jboss-eap-6.3&Alias=default-host%2Clocalhost%2Cexample.com&Context=%2Fclusterbench" > [07:45:40] mod_manager.c(1429): process_appl_cmd: STOP-APP nbrequests 0 > [07:45:40] mod_manager.c(2666): manager_handler STOP-APP OK > [07:45:40] mod_manager.c(1901): manager_trans STOP-APP (/) > [07:45:40] mod_manager.c(2617): manager_handler STOP-APP (/) processing: "JVMRoute=jboss-eap-6.3&Alias=default-host%2Clocalhost%2Cexample.com&Context=%2Fclusterbench" > [07:45:40] mod_manager.c(1429): process_appl_cmd: STOP-APP nbrequests 0 > [07:45:40] mod_manager.c(2666): manager_handler STOP-APP OK > {noformat} > Again, there were plenty of requests sent to {{simplecontext-666/}}: > {noformat} > grep -c "GET /simplecontext-666/ HTTP/1.1\" 200" ./targetJDK8/httpd/logs/access_log > 27587 > {noformat} > WDYT? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues January 2015