January 2019 - mod_cluster-issues

[JBoss JIRA] (MODCLUSTER-503) Write balancer's address to Azure Blob Storage via its REST api, libcurl

by Michal Karm Babacek (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-503?page=com.atlassian.jira.pl... ] Work on MODCLUSTER-503 stopped by Michal Karm Babacek. ------------------------------------------------------ > Write balancer's address to Azure Blob Storage via its REST api, libcurl > ------------------------------------------------------------------------ > > Key: MODCLUSTER-503 > URL: https://issues.jboss.org/browse/MODCLUSTER-503 > Project: mod_cluster > Issue Type: Feature Request > Components: Native (httpd modules) > Environment: Azure > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Major > > * the Azure Storage C++ lib depends on Casablanca, it's bloatware, too heavy > * we can do with simple libcurl + openssl for generating proper REST requests > * could be done in C without much overhead > Progress: http://modcloudstorage.net/ -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-608) failonstatus parameter ignored

by Michal Karm Babacek (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-608?page=com.atlassian.jira.pl... ] Michal Karm Babacek closed MODCLUSTER-608. ------------------------------------------ Resolution: Done Should work with httpd 2.4.29+. Reopen if you need it fixed for an older httpd, please. > failonstatus parameter ignored > ------------------------------ > > Key: MODCLUSTER-608 > URL: https://issues.jboss.org/browse/MODCLUSTER-608 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.5.Final > Reporter: Bogdan Sikora > Assignee: Michal Karm Babacek > Priority: Major > > Setting failonstatus to a specific code should result in the error state of the worker that returned the code. > *Example:* > Httpd mod_cluster balancer with 2 tomcat workers that have deployed clusterbench app > {noformat} > ProxyPass / balancer://balancerxxx stickysession=JSESSIONID|jsessionid nofailover=on failonstatus=201 > ProxyPassReverse / balancer://balancerxxx > ProxyPreserveHost on > {noformat} > {noformat} > Checking for http://192.168.122.206:2080/clusterbench/jvmroute response code: was 200, expected [200, 201, 202, 203] > {noformat} > Let's send special request that returns 201(failonstatus code) > {noformat} > Checking for http://192.168.122.206:2080/clusterbench/httpcode/?http_code=201 response code: was 201, expected 201 > {noformat} > This should result in worker in error state > {noformat} > <h1> Node tomcat-7-1 (ajp://192.168.122.206:8009): </h1> > ...Status: NOTOK,Elected: 13,Read: 245,Transferred: 0,Connected: 0,Load: 100... > ><h1> Node tomcat-7-2 (ajp://192.168.122.206:8110): </h1> > ...Status: OK,Elected: 1,Read: 10,Transferred: 0,Connected: 0,Load: 100... > {noformat} > as in example. This example is made with 2.4.6 httpd. > Debug log > {noformat} > [Wed Jul 26 09:13:12.646541 2017] [:error] [pid 22223] [client 192.168.122.206:41482] balancer://balancerxxx: Forcing worker (ajp://192.168.122.206:8009) into error state due to status code 201 matching 'failonstatus' balancer parameter > {noformat} > *Issue:* > 2.4.23+ Httpd ignores failonstatus parameter. > Return of 201 as in example trigger no error state. > There is no mention in the log and workers on the console are in OK state. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-526) SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup

by Michal Karm Babacek (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-526?page=com.atlassian.jira.pl... ] Michal Karm Babacek updated MODCLUSTER-526: ------------------------------------------- Fix Version/s: Awaiting Volunteers > SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup > ----------------------------------------------------------------------------------- > > Key: MODCLUSTER-526 > URL: https://issues.jboss.org/browse/MODCLUSTER-526 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.3.Final > Environment: Fedora 20, x86_64, httpd 2.4.20 mpm_event > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Blocker > Fix For: Awaiting Volunteers > > > h3. Setup > * 3 tomcats > * 2 load balancing groups > * 1 request every 3 seconds (no load at all) > * shutdown and kill of various nodes > * no later than third kill/start iteration causes SIGSEGV > h3. SIGSEGV > {code} > #if AP_MODULE_MAGIC_AT_LEAST(20101223,1) > /* Here that is tricky the worker needs shared memory but we don't and CONFIG will reset it */ > helper->index = 0; /* mark it removed */ > worker->s = helper->shared; > crash---> memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > #else > worker->id = 0; /* mark it removed */ > #endif > {code} > h3. Behavior > {code} > 957 helper = (proxy_cluster_helper *) worker->context; > 961 if (helper) { > 962 i = helper->count_active; > 963 } > 968 if (i == 0) { > 971 proxy_worker_shared *stat = worker->s; > 972 proxy_cluster_helper *helper = (proxy_cluster_helper *) worker->context; > {code} > At this point, {{helper->shared}} points to a {{proxy_worker_shared}} structure that appears to be properly filled. > {code} > 999 if (worker->cp->pool) { > 1000 apr_pool_destroy(worker->cp->pool); > 1001 worker->cp->pool = NULL; > 1002 } > {code} > Regardless of the aforementioned block being there or nor (stuffed after 1010), > {{helper->shared}} suddenly points to {{NULL}}. > {code} > 1008 helper->index = 0; > 1009 worker->s = helper->shared; > {code} > Above assignment makes {{worker->s}} pointing to NULL. > {code} > 1010 memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > {code} > And here we go :( > IMHO, _other thread_ already cleared that memory and nulled the pointer, because it absolutely doesn't happen if > I run 1 process and 1 thread. > The [workaround that prevents the core|https://github.com/modcluster/mod_cluster/pull/207] looks like this: > {code} > if (helper->shared) { > worker->s = helper->shared; > memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > } > {code} > h3. How do we fix it? > Any ideas? [~jfclere] -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-438) WebSocket support for mod_cluster

by Dasharath Masirkar (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-438?page=com.atlassian.jira.pl... ] Dasharath Masirkar updated MODCLUSTER-438: ------------------------------------------ > WebSocket support for mod_cluster > --------------------------------- > > Key: MODCLUSTER-438 > URL: https://issues.jboss.org/browse/MODCLUSTER-438 > Project: mod_cluster > Issue Type: Feature Request > Components: Native (httpd modules) > Affects Versions: 1.3.2.Final > Reporter: Michal Karm Babacek > Assignee: Jean-Frederic Clere > Priority: Major > Fix For: Awaiting Volunteers > > > * take a look at mod_proxy_wstunnel > * mod_cluster should be able to load balance WebSocket connections to worker nodes > * consider high-availability with respect to WebSockets > Additional details TBD... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-526) SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup

by Michal Karm Babacek (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-526?page=com.atlassian.jira.pl... ] Work on MODCLUSTER-526 stopped by Michal Karm Babacek. ------------------------------------------------------ > SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup > ----------------------------------------------------------------------------------- > > Key: MODCLUSTER-526 > URL: https://issues.jboss.org/browse/MODCLUSTER-526 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.3.Final > Environment: Fedora 20, x86_64, httpd 2.4.20 mpm_event > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Blocker > > h3. Setup > * 3 tomcats > * 2 load balancing groups > * 1 request every 3 seconds (no load at all) > * shutdown and kill of various nodes > * no later than third kill/start iteration causes SIGSEGV > h3. SIGSEGV > {code} > #if AP_MODULE_MAGIC_AT_LEAST(20101223,1) > /* Here that is tricky the worker needs shared memory but we don't and CONFIG will reset it */ > helper->index = 0; /* mark it removed */ > worker->s = helper->shared; > crash---> memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > #else > worker->id = 0; /* mark it removed */ > #endif > {code} > h3. Behavior > {code} > 957 helper = (proxy_cluster_helper *) worker->context; > 961 if (helper) { > 962 i = helper->count_active; > 963 } > 968 if (i == 0) { > 971 proxy_worker_shared *stat = worker->s; > 972 proxy_cluster_helper *helper = (proxy_cluster_helper *) worker->context; > {code} > At this point, {{helper->shared}} points to a {{proxy_worker_shared}} structure that appears to be properly filled. > {code} > 999 if (worker->cp->pool) { > 1000 apr_pool_destroy(worker->cp->pool); > 1001 worker->cp->pool = NULL; > 1002 } > {code} > Regardless of the aforementioned block being there or nor (stuffed after 1010), > {{helper->shared}} suddenly points to {{NULL}}. > {code} > 1008 helper->index = 0; > 1009 worker->s = helper->shared; > {code} > Above assignment makes {{worker->s}} pointing to NULL. > {code} > 1010 memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > {code} > And here we go :( > IMHO, _other thread_ already cleared that memory and nulled the pointer, because it absolutely doesn't happen if > I run 1 process and 1 thread. > The [workaround that prevents the core|https://github.com/modcluster/mod_cluster/pull/207] looks like this: > {code} > if (helper->shared) { > worker->s = helper->shared; > memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > } > {code} > h3. How do we fix it? > Any ideas? [~jfclere] -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 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 2019