[JBoss JIRA] (MODCLUSTER-365) Reset MCMPs are sent to all available proxies
by Aaron Ogburn (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-365?page=com.atlassian.jira.pl... ]
Aaron Ogburn updated MODCLUSTER-365:
------------------------------------
Git Pull Request: https://github.com/modcluster/mod_cluster/pull/48
> Reset MCMPs are sent to all available proxies
> ---------------------------------------------
>
> Key: MODCLUSTER-365
> URL: https://issues.jboss.org/browse/MODCLUSTER-365
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.6.Final
> Environment: -JBoss Enterprise Application Platform (EAP) 6.1.1
> Reporter: Aaron Ogburn
> Assignee: Jean-Frederic Clere
>
> Consider a JBoss server with multiple httpd servers defined in its proxy-list. If one of those httpd servers goes down and then comes back up, then reset MCMPs (CONFIG, ENABLE-APP) would be sent to the restarted httpd proxy but needlessly to all other proxies as well. This is because DefaultMCMPHandler.status just calls sendRequests, which will send to all proxies by design.
> This has negative implications if auto-enable-contexts is set to false and can break desired behavior. Reproducer steps detail the issue introduced in that scenario.
--
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, 6 months
[JBoss JIRA] (MODCLUSTER-365) Reset MCMPs are sent to all available proxies
by Aaron Ogburn (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-365?page=com.atlassian.jira.pl... ]
Aaron Ogburn updated MODCLUSTER-365:
------------------------------------
> Reset MCMPs are sent to all available proxies
> ---------------------------------------------
>
> Key: MODCLUSTER-365
> URL: https://issues.jboss.org/browse/MODCLUSTER-365
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.6.Final
> Environment: -JBoss Enterprise Application Platform (EAP) 6.1.1
> Reporter: Aaron Ogburn
> Assignee: Jean-Frederic Clere
>
> Consider a JBoss server with multiple httpd servers defined in its proxy-list. If one of those httpd servers goes down and then comes back up, then reset MCMPs (CONFIG, ENABLE-APP) would be sent to the restarted httpd proxy but needlessly to all other proxies as well. This is because DefaultMCMPHandler.status just calls sendRequests, which will send to all proxies by design.
> This has negative implications if auto-enable-contexts is set to false and can break desired behavior. Reproducer steps detail the issue introduced in that scenario.
--
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, 6 months
[JBoss JIRA] (MODCLUSTER-365) Reset MCMPs are sent to all available proxies
by Aaron Ogburn (JIRA)
Aaron Ogburn created MODCLUSTER-365:
---------------------------------------
Summary: Reset MCMPs are sent to all available proxies
Key: MODCLUSTER-365
URL: https://issues.jboss.org/browse/MODCLUSTER-365
Project: mod_cluster
Issue Type: Bug
Affects Versions: 1.2.6.Final
Environment: -JBoss Enterprise Application Platform (EAP) 6.1.1
Reporter: Aaron Ogburn
Assignee: Jean-Frederic Clere
Consider a JBoss server with multiple httpd servers defined in its proxy-list. If one of those httpd servers goes down and then comes back up, then reset MCMPs (CONFIG, ENABLE-APP) would be sent to the restarted httpd proxy but needlessly to all other proxies as well. This is because DefaultMCMPHandler.status just calls sendRequests, which will send to all proxies by design.
This has negative implications if auto-enable-contexts is set to false and can break desired behavior. Reproducer steps detail the issue introduced in that scenario.
--
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, 6 months
[JBoss JIRA] (MODCLUSTER-359) stickysession not working with httpd-2.4.6 / mod_cluster-1.2.5.Final
by Marco Danti (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-359?page=com.atlassian.jira.pl... ]
Marco Danti commented on MODCLUSTER-359:
----------------------------------------
{quote}
A quick looks shows: (httpd-2.4.6_mpm_prefork_modcluster-1.2.6_error_log)
JVMRoute=stw-1&Host=172.16.0.133&Maxattempts=1&Port=7009&StickySessionForce=No&Type=ajp&ping=10
there must be something wrong in your tests.
{quote}
So, is *StickySessionForce=yes* a required setting?
> stickysession not working with httpd-2.4.6 / mod_cluster-1.2.5.Final
> ---------------------------------------------------------------------
>
> Key: MODCLUSTER-359
> URL: https://issues.jboss.org/browse/MODCLUSTER-359
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.5.Final, 1.2.6.Final
> Environment: OS. SLES-11-SP1 x86_64
> Reporter: Marco Danti
> Assignee: Jean-Frederic Clere
> Labels: httpd, mod_cluster, stickysession
> Attachments: MODCLUSTER-359-debug-info.tar.gz, tses.war
>
>
> Setup: HTTPD configured as reverse proxy / load balancer for two instances of JBOSS-AS-7.2.0.Final running in HA configuration on two separate nodes.
> Consider the following configuration (defined inside my virtual hosts)
>
> <Proxy balancer://mycluster>
> ProxySet stickysession=JSESSIONID|jsessionid
> </Proxy>
> On httpd-2.2.24 / mod_cluster-1.2.0.Final it shows the following behaviour:
> - 'stickysession' is working as expected
> After upgrading to httpd-2.4.6/mod_cluster-1.2.5.Final things are worse:
> - 'stickysession' is ignored and any client request gets dispatched alternatively
> to each one of the two JBoss servers (exactly as if lbmethod=byrequest were defined)
> As a final consideration, I read in the docs that stickysession should be enabled by default in mod_cluster anyway, but that is not the case for me.
--
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, 6 months
[JBoss JIRA] (MODCLUSTER-335) Regression in ProxyPass integration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-335?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on MODCLUSTER-335:
----------------------------------------------------
Michal Babacek <mbabacek(a)redhat.com> made a comment on [bug 960243|https://bugzilla.redhat.com/show_bug.cgi?id=960243]
Cool now. m_c 1.2.6.Final / EAP 6.2.ER4
> Regression in ProxyPass integration
> -----------------------------------
>
> Key: MODCLUSTER-335
> URL: https://issues.jboss.org/browse/MODCLUSTER-335
> Project: mod_cluster
> Issue Type: Feature Request
> Affects Versions: 1.2.4.Final
> Environment: RHEL6 x86_64, the rest is to be confirmed...
> Reporter: Michal Babacek
> Assignee: Jean-Frederic Clere
> Fix For: 1.2.5.Final
>
> Attachments: logs-and-configs-m_c-1.2.3.zip, logs-and-configs-m_c-1.2.4.zip, test-run-modProxyOnlyPartOfUrlSpaceTest-mod_cluster-1.2.3.log, test-run-modProxyOnlyPartOfUrlSpaceTest-mod_cluster-1.2.4.log
>
>
> This configuration & test worked just fine with 1.2.3.Final and it is broken in 1.2.4.Final, so we have a *regression* here, I guess.
> {code}
> ProxyPassMatch ^/app/static/ !
> ProxyPass /app balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on
> ProxyPass / !
> ProxyPassReverse /app balancer://qacluster
> ProxyPassReverseCookieDomain / /app/
> ProxyPassReverseCookiePath / /app/
> ProxyPreserveHost on
> {code}
> Accessing e.g. {{/app/clusterbench/requestinfo/}} returns HTTP 503. *requestinfo* comes from the famous [CommonRequestInfoServlet.java|https://github.com/Karm/clusterbench/blob/s...].
> h3. mod_cluster 1.2.3 ProxyPass test:
> *Failed tests*
> * modProxyOnlyPartOfUrlSpaceTest: Known fail: [JBQA-7899] Assert #10 Session ID must always be the same.
> * modProxyWithoutSessionId: Assert #1, fail, known as [MODCLUSTER-334], http://10.16.45.160:2080/clusterbench/requestinfo/ should have been available...
> h3. mod_cluster 1.2.4 ProxyPass test:
> *Failed tests*
> * modProxyOnlyPartOfUrlSpaceTest: Assert #1, fail, http://10.16.45.160:2080/app/clusterbench/requestinfo/ should have been available...
> * modProxyWithoutSessionId: Assert #1, fail, known as [MODCLUSTER-334], http://10.16.45.160:2080/clusterbench/requestinfo/ should have been available...
> What the test does is it accesses various URLs, getting either static content from httpd or a dynamic one from application server.
> Browse the attached files for complete configs, debug logs and test results. Ping me, if the zipped file structure does not make sense to you...
--
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, 6 months
[JBoss JIRA] (MODCLUSTER-335) Regression in ProxyPass integration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-335?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on MODCLUSTER-335:
----------------------------------------------------
Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 960243|https://bugzilla.redhat.com/show_bug.cgi?id=960243] from ON_QA to VERIFIED
> Regression in ProxyPass integration
> -----------------------------------
>
> Key: MODCLUSTER-335
> URL: https://issues.jboss.org/browse/MODCLUSTER-335
> Project: mod_cluster
> Issue Type: Feature Request
> Affects Versions: 1.2.4.Final
> Environment: RHEL6 x86_64, the rest is to be confirmed...
> Reporter: Michal Babacek
> Assignee: Jean-Frederic Clere
> Fix For: 1.2.5.Final
>
> Attachments: logs-and-configs-m_c-1.2.3.zip, logs-and-configs-m_c-1.2.4.zip, test-run-modProxyOnlyPartOfUrlSpaceTest-mod_cluster-1.2.3.log, test-run-modProxyOnlyPartOfUrlSpaceTest-mod_cluster-1.2.4.log
>
>
> This configuration & test worked just fine with 1.2.3.Final and it is broken in 1.2.4.Final, so we have a *regression* here, I guess.
> {code}
> ProxyPassMatch ^/app/static/ !
> ProxyPass /app balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on
> ProxyPass / !
> ProxyPassReverse /app balancer://qacluster
> ProxyPassReverseCookieDomain / /app/
> ProxyPassReverseCookiePath / /app/
> ProxyPreserveHost on
> {code}
> Accessing e.g. {{/app/clusterbench/requestinfo/}} returns HTTP 503. *requestinfo* comes from the famous [CommonRequestInfoServlet.java|https://github.com/Karm/clusterbench/blob/s...].
> h3. mod_cluster 1.2.3 ProxyPass test:
> *Failed tests*
> * modProxyOnlyPartOfUrlSpaceTest: Known fail: [JBQA-7899] Assert #10 Session ID must always be the same.
> * modProxyWithoutSessionId: Assert #1, fail, known as [MODCLUSTER-334], http://10.16.45.160:2080/clusterbench/requestinfo/ should have been available...
> h3. mod_cluster 1.2.4 ProxyPass test:
> *Failed tests*
> * modProxyOnlyPartOfUrlSpaceTest: Assert #1, fail, http://10.16.45.160:2080/app/clusterbench/requestinfo/ should have been available...
> * modProxyWithoutSessionId: Assert #1, fail, known as [MODCLUSTER-334], http://10.16.45.160:2080/clusterbench/requestinfo/ should have been available...
> What the test does is it accesses various URLs, getting either static content from httpd or a dynamic one from application server.
> Browse the attached files for complete configs, debug logs and test results. Ping me, if the zipped file structure does not make sense to you...
--
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, 6 months
[JBoss JIRA] (MODCLUSTER-335) Regression in ProxyPass integration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-335?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on MODCLUSTER-335:
----------------------------------------------------
Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 960243|https://bugzilla.redhat.com/show_bug.cgi?id=960243] from NEW to ON_QA
> Regression in ProxyPass integration
> -----------------------------------
>
> Key: MODCLUSTER-335
> URL: https://issues.jboss.org/browse/MODCLUSTER-335
> Project: mod_cluster
> Issue Type: Feature Request
> Affects Versions: 1.2.4.Final
> Environment: RHEL6 x86_64, the rest is to be confirmed...
> Reporter: Michal Babacek
> Assignee: Jean-Frederic Clere
> Fix For: 1.2.5.Final
>
> Attachments: logs-and-configs-m_c-1.2.3.zip, logs-and-configs-m_c-1.2.4.zip, test-run-modProxyOnlyPartOfUrlSpaceTest-mod_cluster-1.2.3.log, test-run-modProxyOnlyPartOfUrlSpaceTest-mod_cluster-1.2.4.log
>
>
> This configuration & test worked just fine with 1.2.3.Final and it is broken in 1.2.4.Final, so we have a *regression* here, I guess.
> {code}
> ProxyPassMatch ^/app/static/ !
> ProxyPass /app balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on
> ProxyPass / !
> ProxyPassReverse /app balancer://qacluster
> ProxyPassReverseCookieDomain / /app/
> ProxyPassReverseCookiePath / /app/
> ProxyPreserveHost on
> {code}
> Accessing e.g. {{/app/clusterbench/requestinfo/}} returns HTTP 503. *requestinfo* comes from the famous [CommonRequestInfoServlet.java|https://github.com/Karm/clusterbench/blob/s...].
> h3. mod_cluster 1.2.3 ProxyPass test:
> *Failed tests*
> * modProxyOnlyPartOfUrlSpaceTest: Known fail: [JBQA-7899] Assert #10 Session ID must always be the same.
> * modProxyWithoutSessionId: Assert #1, fail, known as [MODCLUSTER-334], http://10.16.45.160:2080/clusterbench/requestinfo/ should have been available...
> h3. mod_cluster 1.2.4 ProxyPass test:
> *Failed tests*
> * modProxyOnlyPartOfUrlSpaceTest: Assert #1, fail, http://10.16.45.160:2080/app/clusterbench/requestinfo/ should have been available...
> * modProxyWithoutSessionId: Assert #1, fail, known as [MODCLUSTER-334], http://10.16.45.160:2080/clusterbench/requestinfo/ should have been available...
> What the test does is it accesses various URLs, getting either static content from httpd or a dynamic one from application server.
> Browse the attached files for complete configs, debug logs and test results. Ping me, if the zipped file structure does not make sense to you...
--
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, 6 months
[JBoss JIRA] (MODCLUSTER-359) stickysession not working with httpd-2.4.6 / mod_cluster-1.2.5.Final
by Marco Danti (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-359?page=com.atlassian.jira.pl... ]
Marco Danti commented on MODCLUSTER-359:
----------------------------------------
This is weird because it is in contrast with the documentation at http://docs.jboss.org/mod_cluster/1.2.0/html_single/#proxy, where it says that 'sticky-session' default value is TRUE.
Up to now, I had the following configuration:
<mod-cluster-config advertise-socket="modcluster" advertise-security-key="secret" connector="ajp">
If I try:
<mod-cluster-config advertise-socket="modcluster" sticky-session="true" advertise-security-key="secret" connector="ajp">
it makes no difference whatsoever (request is always routed alternatively to both jboss servers); it seems that sticky-session is not considered at all
However, if I try
<mod-cluster-config advertise-socket="modcluster" sticky-session-force="true" advertise-security-key="secret" connector="ajp">
then the sticky session behaviour is correct (the request is always routed to the same server), which may be ok as a workaround but makes no sense because sticky-session-force purpose seems to be completely different.
These last tests were done using mod_cluster-1.2.6.Final on both AS-7.2.0.Final and Httpd-2.4.6
> stickysession not working with httpd-2.4.6 / mod_cluster-1.2.5.Final
> ---------------------------------------------------------------------
>
> Key: MODCLUSTER-359
> URL: https://issues.jboss.org/browse/MODCLUSTER-359
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.5.Final, 1.2.6.Final
> Environment: OS. SLES-11-SP1 x86_64
> Reporter: Marco Danti
> Assignee: Jean-Frederic Clere
> Labels: httpd, mod_cluster, stickysession
> Attachments: MODCLUSTER-359-debug-info.tar.gz, tses.war
>
>
> Setup: HTTPD configured as reverse proxy / load balancer for two instances of JBOSS-AS-7.2.0.Final running in HA configuration on two separate nodes.
> Consider the following configuration (defined inside my virtual hosts)
>
> <Proxy balancer://mycluster>
> ProxySet stickysession=JSESSIONID|jsessionid
> </Proxy>
> On httpd-2.2.24 / mod_cluster-1.2.0.Final it shows the following behaviour:
> - 'stickysession' is working as expected
> After upgrading to httpd-2.4.6/mod_cluster-1.2.5.Final things are worse:
> - 'stickysession' is ignored and any client request gets dispatched alternatively
> to each one of the two JBoss servers (exactly as if lbmethod=byrequest were defined)
> As a final consideration, I read in the docs that stickysession should be enabled by default in mod_cluster anyway, but that is not the case for me.
--
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, 6 months