[JBoss JIRA] (MODCLUSTER-427) mod_cluster can break stickiness for the first request on new child processes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-427?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on MODCLUSTER-427:
----------------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1136976|https://bugzilla.redhat.com/show_bug.cgi?id=1136976] from NEW to POST
> mod_cluster can break stickiness for the first request on new child processes
> -----------------------------------------------------------------------------
>
> Key: MODCLUSTER-427
> URL: https://issues.jboss.org/browse/MODCLUSTER-427
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.2.9.Final, 1.3.1.Alpha1
> Environment: JBoss EAP 6.3.0
> Reporter: Aaron Ogburn
> Assignee: Jean-Frederic Clere
> Fix For: 1.2.10.Final, 1.3.1.Alpha3
>
>
> mod_cluster can break stickiness for the first request on new child processes. It looks like this occurs specifically when "CreateBalancers 1" is used. Prefork typically makes this much worse as well.
> My debugging showed that the proxy_balancer would exist, but it would essentially be empty in the new child process. find_session_route/find_route_worker would be called as expected, but the for loop in find_route_worker wasn't even doing anything because balancer->workers->nelts was 0. The balancer would then finally be populated in the new child when the first request hits internal_find_best_byrequests and calls update_workers_node.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
8 years, 5 months
[JBoss JIRA] (MODCLUSTER-430) CreateBalancers behave the same with option 0 or 2
by John Jerome (JIRA)
John Jerome created MODCLUSTER-430:
--------------------------------------
Summary: CreateBalancers behave the same with option 0 or 2
Key: MODCLUSTER-430
URL: https://issues.jboss.org/browse/MODCLUSTER-430
Project: mod_cluster
Issue Type: Bug
Components: Native (httpd modules)
Affects Versions: 1.3.0.Final
Environment: RHEL 6.4.0
Apache HTTPD 2.4.10
JBoss 6.1.1
Mod_cluster 1.3.0 Final
Reporter: John Jerome
Assignee: Jean-Frederic Clere
The directive CreateBalancers with directive 0 or 2 creates the balancers on all httpd vhosts.
With option 2, the balancers should be created on the main server only, not in the vhosts.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
8 years, 5 months
tomcat 8
by Mennat Mokhtar
Does mod_cluster currently support tomcat 8?
--
test
<../../Pictures/Screenshots/Emirates_REIT_Management_-_Logo_-_125x156.png>
Mennat Mokhtar
IT Manager and System Administrator
Direct Line: +971 4 405 7356
Mobile: +971 55 949 0704
Email: mennat.mokhtar(a)reit.ae
Emirates REIT Management (Private) Limited
DIFC, Gate Village 4, Level 5, PO Box 482015, Dubai, UAE
Tel: +971 4 405 REIT (+971 4 405 7348)
http://www.reit.ae
Regulated by the DFSA
/This message, including any attachments may contain confidential and
privileged material; it is intended only for the person to whom it is
addressed. The contents of this email does not constitute a commitment
by Emirates REIT Management (Private) Limited except where provided for
in a written agreement. Emirates REIT Management (Private) Limited
assumes no liability or responsibility for the consequences arising out
of a delay and/or loss in transit of this message, or for corruption or
other error(s) arising in its transmission and for any misuse or
fraudulent use which may be made thereof. If you are not the intended
recipient, please contact us and abstain from any disclosure, use or
dissemination. To the extent that this message contains recommendations,
these are provided on the same basis as Emirates REIT Management
(Private) Limited’s published research and the recipient must have
regard to all disclosures and disclaimers contained therein. Emirates
REIT Management (Private) Limited is duly licensed and regulated by the
Dubai Financial Services Authority (DFSA). /
8 years, 6 months
[JBoss JIRA] (MODCLUSTER-390) add failonstatus to mod_cluster
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-390?page=com.atlassian.jira.pl... ]
Michal Babacek commented on MODCLUSTER-390:
-------------------------------------------
Very well, I've written an automated test that reflects the _comment #4_ and it works:
h3. mod_cluster before the feature was implemented
Some initial requests, HTTP 200...
{code}
Trying to retrieve content from http://192.168.122.204:2181/clusterbench/httpcode/?http_code=200, response code = 200
HTTP Code was: 200
JVM route: jboss-eap-6.2
Session ID: 4VKyGpxfi2MvHCOKC4A-l-5i.jboss-eap-6.2
Session isNew: false
Trying to retrieve content from http://192.168.122.204:2181/clusterbench/httpcode/?http_code=200, response code = 200
HTTP Code was: 200
JVM route: jboss-eap-6.2
Session ID: 4VKyGpxfi2MvHCOKC4A-l-5i.jboss-eap-6.2
Session isNew: false
{code}
Now, let's use HTTP 201, the *failonstatus=201* setting...
{code}
Trying to retrieve content from http://192.168.122.204:2181/clusterbench/httpcode/?http_code=201, response code = 201
HTTP Code was: 201
JVM route: jboss-eap-6.2
Session ID: 4VKyGpxfi2MvHCOKC4A-l-5i.jboss-eap-6.2
Session isNew: false
{code}
The response comes from the same node, that's fine, but the subsequent requests come from that node as well, i.e. the feature is not implemented:
{code}
Trying to retrieve content from http://192.168.122.204:2181/clusterbench/httpcode/?http_code=200, response code = 200
HTTP Code was: 200
JVM route: jboss-eap-6.2
Session ID: 4VKyGpxfi2MvHCOKC4A-l-5i.jboss-eap-6.2
Session isNew: false
Trying to retrieve content from http://192.168.122.204:2181/clusterbench/httpcode/?http_code=200, response code = 200
HTTP Code was: 200
JVM route: jboss-eap-6.2
Session ID: 4VKyGpxfi2MvHCOKC4A-l-5i.jboss-eap-6.2
Session isNew: false
{code}
h3. current mod_cluster 1.2.9, feature implemented
Some initial requests, HTTP 200...
{code}
Trying to retrieve content from http://192.168.122.204:2181/clusterbench/httpcode/?http_code=200, response code = 200
HTTP Code was: 200
JVM route: jboss-eap-6.3
Session ID: cETRQkQtnJk9R0I4eaGaoril.jboss-eap-6.3
Session isNew: false
Trying to retrieve content from http://192.168.122.204:2181/clusterbench/httpcode/?http_code=200, response code = 200
HTTP Code was: 200
JVM route: jboss-eap-6.3
Session ID: cETRQkQtnJk9R0I4eaGaoril.jboss-eap-6.3
Session isNew: false
{code}
Now, let's use HTTP 201, the *failonstatus=201* setting...
{code}
Trying to retrieve content from http://192.168.122.204:2181/clusterbench/httpcode/?http_code=201, response code = 201
HTTP Code was: 201
JVM route: jboss-eap-6.3
Session ID: cETRQkQtnJk9R0I4eaGaoril.jboss-eap-6.3
Session isNew: false
{code}
The response comes from the same node, that's fine, but the subsequent requests come from a different node, i.e. the feature is implemented:
{code}
Trying to retrieve content from http://192.168.122.204:2181/clusterbench/httpcode/?http_code=200, response code = 200
HTTP Code was: 200
JVM route: jboss-eap-6.3-2
Session ID: cETRQkQtnJk9R0I4eaGaoril.jboss-eap-6.3-2
Session isNew: false
Trying to retrieve content from http://192.168.122.204:2181/clusterbench/httpcode/?http_code=200, response code = 200
HTTP Code was: 200
JVM route: jboss-eap-6.3-2
Session ID: cETRQkQtnJk9R0I4eaGaoril.jboss-eap-6.3-2
Session isNew: false
{code}
h3. Regarding Status
As to your other question, the *jboss-eap-6.3* worker was in *NOTOK* for a period of time just until the next *STATUS* message was received. After that, both *jboss-eap-6.3* and *jboss-eap-6.3-2* have been in *OK* status.
So, what shall we do about it? I think it's probably all right.
1. I have a certain set of HTTP codes that I want to trigger a failover
2. it works, failover occurs (on the *second* request)
3. the worker is put back in business, because there is no reason to believe it's broken, i.e. the fact that a web app returned a specific code does not suggest that the whole box should be kept in *NOTOK*...
WDYT?
> add failonstatus to mod_cluster
> -------------------------------
>
> Key: MODCLUSTER-390
> URL: https://issues.jboss.org/browse/MODCLUSTER-390
> Project: mod_cluster
> Issue Type: Enhancement
> Affects Versions: 1.2.6.Final, 1.3.0.Final
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.2.8.Final, 1.3.1.Alpha3
>
> Attachments: error_log.zip
>
>
> The feature was added in httpd-2.2.17 in the mod_proxy_balancer we just need to copy that code and find a way to configure it,
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
8 years, 6 months
[JBoss JIRA] (MODCLUSTER-390) add failonstatus to mod_cluster
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-390?page=com.atlassian.jira.pl... ]
Jean-Frederic Clere commented on MODCLUSTER-390:
------------------------------------------------
Please reread my comments:
1 - comment #4 the response it sent and the worker is marked in error.
2 - the STATUS will retry the worker and mark it up.
Probalby 2 isn't what your test is excepting but that is what you are testing (wait enough for the STATUS to be received by httpd and the worker will be marked OK).
Please retest to confirm.
Actually the behaviour doesn't make much sense I think the STATUS should put the worker in OK state when failonstatus is used I am going to look how to fix that.
> add failonstatus to mod_cluster
> -------------------------------
>
> Key: MODCLUSTER-390
> URL: https://issues.jboss.org/browse/MODCLUSTER-390
> Project: mod_cluster
> Issue Type: Enhancement
> Affects Versions: 1.2.6.Final, 1.3.0.Final
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.2.8.Final, 1.3.1.Alpha3
>
> Attachments: error_log.zip
>
>
> The feature was added in httpd-2.2.17 in the mod_proxy_balancer we just need to copy that code and find a way to configure it,
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
8 years, 6 months
[JBoss JIRA] (MODCLUSTER-390) add failonstatus to mod_cluster
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-390?page=com.atlassian.jira.pl... ]
Jean-Frederic Clere commented on MODCLUSTER-390:
------------------------------------------------
forcerecovery isn't supported in mod_cluster... Basically it will be ignored.
> add failonstatus to mod_cluster
> -------------------------------
>
> Key: MODCLUSTER-390
> URL: https://issues.jboss.org/browse/MODCLUSTER-390
> Project: mod_cluster
> Issue Type: Enhancement
> Affects Versions: 1.2.6.Final, 1.3.0.Final
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.2.8.Final, 1.3.1.Alpha3
>
> Attachments: error_log.zip
>
>
> The feature was added in httpd-2.2.17 in the mod_proxy_balancer we just need to copy that code and find a way to configure it,
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
8 years, 6 months
[JBoss JIRA] (MODCLUSTER-390) add failonstatus to mod_cluster
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-390?page=com.atlassian.jira.pl... ]
Jean-Frederic Clere commented on MODCLUSTER-390:
------------------------------------------------
Looking to the log I have seen that the STATUS message is retrying the worker without taking care of the retry value.
> add failonstatus to mod_cluster
> -------------------------------
>
> Key: MODCLUSTER-390
> URL: https://issues.jboss.org/browse/MODCLUSTER-390
> Project: mod_cluster
> Issue Type: Enhancement
> Affects Versions: 1.2.6.Final, 1.3.0.Final
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.2.8.Final, 1.3.1.Alpha3
>
> Attachments: error_log.zip
>
>
> The feature was added in httpd-2.2.17 in the mod_proxy_balancer we just need to copy that code and find a way to configure it,
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
8 years, 6 months