June 2014 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-178) Domains: non sticky requests should be contained within a given domain

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-178?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-178: ------------------------------------------- {quote}first we stick to a node, then in case of a failure of that node we failover to another node within same domain, and only in case of a second node failure, we will send request to Domain2.{quote} If I am reading this right, what you just described are *sticky* sessions and that is how they currently work. What this Jira is about are non-sticky sessions (i.e. they do not stick to particular node) but they do not currently stick to the domain either. Implementing this and enabling this would keep sessions sticky to the domain only. > Domains: non sticky requests should be contained within a given domain > ---------------------------------------------------------------------- > > Key: MODCLUSTER-178 > URL: https://issues.jboss.org/browse/MODCLUSTER-178 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Jean-Frederic Clere > Attachments: cluster-small.png, cluster.jpg > > > If we have a couple of domains, then non-sticky requests can go to *any* server in *any* domain. > It would be nice if we could at least make the domain sticky, so e.g. non-sticky requests always pick the same domain, as long as there are servers in that domain. > Maybe this should be a new flag, e.g. stickyDomain. If stickySession is false, then we'd check stickyDomain. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-178) Domains: non sticky requests should be contained within a given domain

by Roman Jurkov (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-178?page=com.atlassian.jira.pl... ] Roman Jurkov commented on MODCLUSTER-178: ----------------------------------------- this ticket could be simple, however can become tricky if we want to expand this functionality. use case one is where we stick to a node (which is supported as we already know) second use case stick to a domain (which is what this ticket describes) third use case (which would be tricky i think) is to support combination of both !cluster-small.png! first we stick to a node, then in case of a failure of that node we failover to another node within same domain, and only in case of a second node failure, we will send request to Domain2. do you think we would ever want to implement third use case? i was looking into implementing this one. > Domains: non sticky requests should be contained within a given domain > ---------------------------------------------------------------------- > > Key: MODCLUSTER-178 > URL: https://issues.jboss.org/browse/MODCLUSTER-178 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Jean-Frederic Clere > Attachments: cluster-small.png, cluster.jpg > > > If we have a couple of domains, then non-sticky requests can go to *any* server in *any* domain. > It would be nice if we could at least make the domain sticky, so e.g. non-sticky requests always pick the same domain, as long as there are servers in that domain. > Maybe this should be a new flag, e.g. stickyDomain. If stickySession is false, then we'd check stickyDomain. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-178) Domains: non sticky requests should be contained within a given domain

by Roman Jurkov (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-178?page=com.atlassian.jira.pl... ] Roman Jurkov updated MODCLUSTER-178: ------------------------------------ Attachment: cluster-small.png > Domains: non sticky requests should be contained within a given domain > ---------------------------------------------------------------------- > > Key: MODCLUSTER-178 > URL: https://issues.jboss.org/browse/MODCLUSTER-178 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Jean-Frederic Clere > Attachments: cluster-small.png, cluster.jpg > > > If we have a couple of domains, then non-sticky requests can go to *any* server in *any* domain. > It would be nice if we could at least make the domain sticky, so e.g. non-sticky requests always pick the same domain, as long as there are servers in that domain. > Maybe this should be a new flag, e.g. stickyDomain. If stickySession is false, then we'd check stickyDomain. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-178) Domains: non sticky requests should be contained within a given domain

by Roman Jurkov (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-178?page=com.atlassian.jira.pl... ] Roman Jurkov updated MODCLUSTER-178: ------------------------------------ Attachment: cluster.jpg > Domains: non sticky requests should be contained within a given domain > ---------------------------------------------------------------------- > > Key: MODCLUSTER-178 > URL: https://issues.jboss.org/browse/MODCLUSTER-178 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Jean-Frederic Clere > Attachments: cluster.jpg > > > If we have a couple of domains, then non-sticky requests can go to *any* server in *any* domain. > It would be nice if we could at least make the domain sticky, so e.g. non-sticky requests always pick the same domain, as long as there are servers in that domain. > Maybe this should be a new flag, e.g. stickyDomain. If stickySession is false, then we'd check stickyDomain. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-404) ModClusterService stop commands are always draining sessions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-404?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-404: ---------------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1098576|https://bugzilla.redhat.com/show_bug.cgi?id=1098576] from MODIFIED to ON_QA > ModClusterService stop commands are always draining sessions > ------------------------------------------------------------ > > Key: MODCLUSTER-404 > URL: https://issues.jboss.org/browse/MODCLUSTER-404 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.0.Final, 1.2.8.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Final, 1.2.9.Final > > > Using the ModClusterService stop or stopContext commands via CLI always fails to move a context to the STOPPED state after failing to drain the active sessions. So these commands then aren't very useful for quickly stopping the context when desired if you can't do it without draining. > I think it'd make sense for any draining done by manual stops to also follow the session draining strategy used by typical stops from undeploy events. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-235) Support hot-standby worker nodes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-235?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-235: ---------------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 987259|https://bugzilla.redhat.com/show_bug.cgi?id=987259] from MODIFIED to ON_QA > Support hot-standby worker nodes > -------------------------------- > > Key: MODCLUSTER-235 > URL: https://issues.jboss.org/browse/MODCLUSTER-235 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.1.2.Final > Reporter: Samuel Mendenhall > Assignee: Jean-Frederic Clere > > Like in mod_proxy and mod_jk, mod_cluster should support the ability to keep a worker node in hot-standby. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-391) mod_cluster and mod_proxy integration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-391?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-391: ---------------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 987259|https://bugzilla.redhat.com/show_bug.cgi?id=987259] from MODIFIED to ON_QA > mod_cluster and mod_proxy integration > ------------------------------------- > > Key: MODCLUSTER-391 > URL: https://issues.jboss.org/browse/MODCLUSTER-391 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: All platforms we build mod_cluster for. > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Labels: native_libraries > Fix For: 1.3.1.Final, 1.2.10.Final > > Attachments: error_log, mod_cluster.conf, mod_proxy.conf, standalone-ha.xml > > > This Jira encapsulates all concerns regarding mod_cluster - mod_proxy integration. For instance, while basic {{ProxyPass}} settings work just fine, e.g. serving some files on {{/static}} from the Apache HTTP itself: > {code} > ProxyPassMatch ^/static/ ! > ProxyPass / balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on > ProxyPassReverse / balancer://qacluster > ProxyPreserveHost on > {code} > there are more complex setups, involving {{BalancerMember}} configurations, that do not work as expected. In the following example, one wanted to have {{/clusterbench}} application managed by mod_cluster, dynamically, while at the same time, in a different VirtualHost, having {{/tses}} application handled by manually created mod_proxy balancer settings. > Attached [^mod_cluster.conf], [^mod_proxy.conf], [^standalone-ha.xml](modcluster subsystem element only) and [^error_log]. > The aforementioned setup resulted in: > |HTTP 200|(From worker)|http://10.16.88.19:8847/clusterbench/requestinfo/|OK|(/)| > |HTTP 404|(From httpd)|http://10.16.88.19:8847/tses/session.jsp|Expected fail|(/)| > |HTTP 503|(From httpd)|http://10.16.88.19:2182/tses/session.jsp|Unexpected fail|(x)| -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-410) OPTIONS call not returning available methods

by Roman Jurkov (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-410?page=com.atlassian.jira.pl... ] Roman Jurkov updated MODCLUSTER-410: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/86 > OPTIONS call not returning available methods > -------------------------------------------- > > Key: MODCLUSTER-410 > URL: https://issues.jboss.org/browse/MODCLUSTER-410 > Project: mod_cluster > Issue Type: Bug > Reporter: Roman Jurkov > Assignee: Jean-Frederic Clere > Priority: Minor > > options call returning just standard registered methods, that is because mod_cluster doesn't register methods through httpd api ap_method_register(). > by using apache api we can get free validation, and faster checks against method_number() instead of method name and strcmp(). -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-407) worker-timeout can cause httpd thread stalls

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-407?page=com.atlassian.jira.pl... ] Aaron Ogburn updated MODCLUSTER-407: ------------------------------------ Steps to Reproduce: 1) Configure jboss with worker-timeout="1" in the modcluster subsystem 2) Start httpd and JBoss. Run httpd on a multicore system (4+ cores). 3) Confirm JBoss is reachable through httpd/mod_cluster then kill JBoss so the mod_cluster worker-timeout retry logic is used 4) Load up httpd with highly concurrent request traffic for JBoss for some time. Then check for stalled requests/threads. Each request should finish by ~1 second. But this could take minutes once stalled. You can check access logs with %T to check response times once they're done, pstack to check threads, or the mod_status page (it'll show may threads in W state with many seconds since their requests started, which keeps growing).. was: 1) Configure jboss with worker-timeout="1" in the modcluster subsystem 2) Start httpd and JBoss 3) Confirm JBoss is reachable through httpd/mod_cluster then kill JBoss so the mod_cluster worker-timeout retry logic is used 4) Load up httpd with requests for JBoss (a couple seconds holding refresh in a browser even will do the trick) Then check for stalled requests/threads. Each request should finish by ~1 second. But this could take minutes once stalled. You can check access logs with %T to check response times once they're done, pstack to check threads, or the mod_status page (it'll show may threads in W state with many seconds since their requests started, which keeps growing).. > worker-timeout can cause httpd thread stalls > -------------------------------------------- > > Key: MODCLUSTER-407 > URL: https://issues.jboss.org/browse/MODCLUSTER-407 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.8.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Final, 1.2.9.Final > > > Setting a modcluster worker-timeout can stall requests and threads on the httpd side when the requests are received with workers in a down state. A stack of the problem thread looks like the following (recursive loops through mod_proxy_cluster from #160 to #2): > #0 0x00007ff8eb547533 in select () from /lib64/libc.so.6 > #1 0x00007ff8eba39185 in apr_sleep () from /usr/lib64/libapr-1.so.0 > #2 0x00007ff8e84be0d1 in ?? () from /etc/httpd/modules/mod_proxy_cluster.so > ... > #160 0x00007ff8e84beb9f in ?? () from /etc/httpd/modules/mod_proxy_cluster.so > #161 0x00007ff8e88d2116 in proxy_run_pre_request () from /etc/httpd/modules/mod_proxy.so > #162 0x00007ff8e88d9186 in ap_proxy_pre_request () from /etc/httpd/modules/mod_proxy.so > #163 0x00007ff8e88d63c2 in ?? () from /etc/httpd/modules/mod_proxy.so -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-376) multiple workers with the same id following a tomcat crash/kill

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-376?page=com.atlassian.jira.pl... ] Jean-Frederic Clere edited comment on MODCLUSTER-376 at 6/3/14 8:22 AM: ------------------------------------------------------------------------ Patch used at the customer... But NOT merged upstream... was (Author: jfclere): Patch used at the customer... But merged upstream... > multiple workers with the same id following a tomcat crash/kill > --------------------------------------------------------------- > > Key: MODCLUSTER-376 > URL: https://issues.jboss.org/browse/MODCLUSTER-376 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.0.10 > Environment: -JBoss Enterprise Web Server 1.0.2 > -mod_cluster 1.0.10.GA_CP04 > -Red Hat Enterprise Linux 5 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Attachments: 131122.patch > > > Following a kill or crash of tomcat, multiple workers are seen for a single id when a new tomcat node reconnects and reuses the id from the previously crashed worker. > The STATUS's ping check sees the old crashed worker first for the id and so pings the wrong destination. Thus the ping fails, and load factor is not applied. The persistent -1 load state leads to 503s. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues June 2014