April 2019 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-630) Upgrade junit to 4.12

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-630?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-630: -------------------------------------- Fix Version/s: 2.0.0.Alpha1 > Upgrade junit to 4.12 > --------------------- > > Key: MODCLUSTER-630 > URL: https://issues.jboss.org/browse/MODCLUSTER-630 > Project: mod_cluster > Issue Type: Component Upgrade > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 2.0.0.Alpha1 > > > Unfortunately we cannot go to junit5 yet as it requires at least JDK8. > Changelog: > https://github.com/junit-team/junit4/blob/master/doc/ReleaseNotes4.12.md > https://github.com/junit-team/junit4/blob/master/doc/ReleaseNotes4.11.md -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-621) maxbufsize doesn't include JVMROUTESZ

by Jean-Frederic Clere (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-621?page=com.atlassian.jira.pl... ] Jean-Frederic Clere resolved MODCLUSTER-621. -------------------------------------------- Fix Version/s: 2.0.0.Alpha2 Resolution: Done fixed by https://github.com/modcluster/mod_proxy_cluster/commit/1414bd8ae519650dc2... > maxbufsize doesn't include JVMROUTESZ > ------------------------------------- > > Key: MODCLUSTER-621 > URL: https://issues.jboss.org/browse/MODCLUSTER-621 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Robert Bost > Assignee: Jean-Frederic Clere > Priority: Major > Fix For: 2.0.0.Alpha2 > > > https://github.com/modcluster/mod_proxy_cluster/blob/master/native/mod_ma... > {code} > if (mconf->maxmesssize) > maxbufsiz = mconf->maxmesssize; > else { > /* we calculate it */ > maxbufsiz = 9 + JVMROUTESZ; > maxbufsiz = bufsiz + (mconf->maxhost * HOSTALIASZ) + 7; > maxbufsiz = bufsiz + (mconf->maxcontext * CONTEXTSZ) + 8; > } > if (maxbufsiz< MAXMESSSIZE) > maxbufsiz = MAXMESSSIZE; > buff = apr_pcalloc(r->pool, maxbufsiz); > {code} > It looks like {{maxbufsize}} will never include the {{9+JVMROUTESZ}} since it overwritten with new value in following line. Is this a problem? -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-625) Automatically allocated function local variable address overwrites function parameter

by Jean-Frederic Clere (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-625?page=com.atlassian.jira.pl... ] Jean-Frederic Clere closed MODCLUSTER-625. ------------------------------------------ Resolution: Won't Fix That is on purpose. > Automatically allocated function local variable address overwrites function parameter > ------------------------------------------------------------------------------------- > > Key: MODCLUSTER-625 > URL: https://issues.jboss.org/browse/MODCLUSTER-625 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.7.Final, 2.0.0.Alpha1 > Environment: C99 (apparently both GNU and MSVC) > Reporter: Michal Karm > Assignee: George Zaronikas > Priority: Major > Fix For: 2.0.0.Alpha1 > > > I went through the cppcheck static analysis report on the current mod_proxy_cluster code base, see [cppcheck.log|https://ci.modcluster.io/job/mod_proxy_cluster-2.x-windows/DISTRO=apache-lounge,label=w2k12r2/93/artifact/cppcheck.log/*view*/], and among *many* warnings and style check failures, there was a one outstanding error reported, which set me wondering. > The error occurs on two places and I'm scratching my head as to whether is is a false positive or not, WDYT? > * [native/mod_manager/domain.c:198|https://github.com/modcluster/mod_proxy_c...]: (error) Address of local auto-variable assigned to a function parameter. > * [native/mod_manager/node.c:227|https://github.com/modcluster/mod_proxy_clu...]: (error) Address of local auto-variable assigned to a function parameter. > Is it O.K. to handle local, function scope, automatically allocated variable this way? To use it's address later in ap_slotmem_do? Couldn't it trigger undefined behaviour and cause some of our rare, hard to reproduce crashes? > Feel free to pick up any other pertinent messages from the log. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-630) Upgrade junit to 4.12

by Jean-Frederic Clere (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-630?page=com.atlassian.jira.pl... ] Jean-Frederic Clere updated MODCLUSTER-630: ------------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade junit to 4.12 > --------------------- > > Key: MODCLUSTER-630 > URL: https://issues.jboss.org/browse/MODCLUSTER-630 > Project: mod_cluster > Issue Type: Component Upgrade > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Unfortunately we cannot go to junit5 yet as it requires at least JDK8. > Changelog: > https://github.com/junit-team/junit4/blob/master/doc/ReleaseNotes4.12.md > https://github.com/junit-team/junit4/blob/master/doc/ReleaseNotes4.11.md -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-660) mod_proxy_cluster master broken

by Jean-Frederic Clere (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-660?page=com.atlassian.jira.pl... ] Jean-Frederic Clere resolved MODCLUSTER-660. -------------------------------------------- Fix Version/s: 2.0.0.Alpha2 Resolution: Done Fixed by https://github.com/modcluster/mod_proxy_cluster/commit/00443f704bfb9df920... > mod_proxy_cluster master broken > ------------------------------- > > Key: MODCLUSTER-660 > URL: https://issues.jboss.org/browse/MODCLUSTER-660 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Priority: Major > Fix For: 2.0.0.Alpha2 > > > Looks like the upstream module is broken, 1.3.x works fine (Server version: Apache/2.4.34 (Unix)), requests fail with: > {noformat} > [Tue Aug 07 17:10:09.581297 2018] [authz_core:debug] [pid 52857] mod_authz_core.c(817): [client 127.0.0.1:52007] AH01626: authorization result of Require all granted: granted, referer: http://127.0.0.1:8989/ > [Tue Aug 07 17:10:09.581505 2018] [authz_core:debug] [pid 52857] mod_authz_core.c(817): [client 127.0.0.1:52007] AH01626: authorization result of <RequireAny>: granted, referer: http://127.0.0.1:8989/ > [Tue Aug 07 17:10:09.581541 2018] [:debug] [pid 52857] mod_proxy_cluster.c(1725): proxy: byrequests balancer skipping BAD worker > [Tue Aug 07 17:10:09.581554 2018] [:debug] [pid 52857] mod_proxy_cluster.c(1725): proxy: byrequests balancer skipping BAD worker > [Tue Aug 07 17:10:09.581564 2018] [:debug] [pid 52857] mod_proxy_cluster.c(1820): proxy: byrequests balancer FAILED > [Tue Aug 07 17:10:09.581578 2018] [:error] [pid 52857] proxy: CLUSTER: (balancer://mycluster). All workers are in error state > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-679) CI: drop support for JDK6

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-679?page=com.atlassian.jira.pl... ] Radoslav Husar closed MODCLUSTER-679. ------------------------------------- Resolution: Rejected Actually, I found a workaround, so we can keep this a little longer, see https://github.com/modcluster/mod_cluster/commit/84bf1300aa925ef397a36720... > CI: drop support for JDK6 > ------------------------- > > Key: MODCLUSTER-679 > URL: https://issues.jboss.org/browse/MODCLUSTER-679 > Project: mod_cluster > Issue Type: Bug > Components: CI & Packaging > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-679) CI: drop support for JDK6

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-679?page=com.atlassian.jira.pl... ] Radoslav Husar reassigned MODCLUSTER-679: ----------------------------------------- Assignee: Radoslav Husar (was: Michal Karm) > CI: drop support for JDK6 > ------------------------- > > Key: MODCLUSTER-679 > URL: https://issues.jboss.org/browse/MODCLUSTER-679 > Project: mod_cluster > Issue Type: Bug > Components: CI & Packaging > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-675) Failover scenario is not performed with httpd balancer - balancer fails to respond

by Jean-Frederic Clere (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-675?page=com.atlassian.jira.pl... ] Jean-Frederic Clere closed MODCLUSTER-675. ------------------------------------------ Resolution: Cannot Reproduce > Failover scenario is not performed with httpd balancer - balancer fails to respond > ---------------------------------------------------------------------------------- > > Key: MODCLUSTER-675 > URL: https://issues.jboss.org/browse/MODCLUSTER-675 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.8.Final > Environment: RHEL 7, CentOS 7 on x86_64 platform > Reporter: Jan Kasik > Assignee: Jean-Frederic Clere > Priority: Blocker > Attachments: error_log, httpd.zip, wildfly-16.0.0.Beta1-SNAPSHOT.zip > > > When second request in failover scenario is made to check whether the failover was done, server fails to respond. With Undertow as a balancer, this behavior cannot be reproduced. When I replace the jvmroute part by worker which is still alive, I got expected response. > {noformat}# curl -v --cookie "JSESSIONID=54yxdncGr5im0fBLqIIUMon0klbS66X16aYC_cVW.jboss-eap-7.2-3" http://172.17.0.2:2080/clusterbench/jvmroute > * About to connect() to 172.17.0.2 port 2080 (#0) > * Trying 172.17.0.2... > * Connected to 172.17.0.2 (172.17.0.2) port 2080 (#0) > > GET /clusterbench/jvmroute HTTP/1.1 > > User-Agent: curl/7.29.0 > > Host: 172.17.0.2:2080 > > Accept: */* > > Cookie: JSESSIONID=54yxdncGr5im0fBLqIIUMon0klbS66X16aYC_cVW.jboss-eap-7.2-3 > > > * Empty reply from server > * Connection #0 to host 172.17.0.2 left intact > curl: (52) Empty reply from server > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

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

by Jean-Frederic Clere (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-526?page=com.atlassian.jira.pl... ] Jean-Frederic Clere closed MODCLUSTER-526. ------------------------------------------ Fix Version/s: (was: Awaiting Volunteers) Resolution: Rejected It is a side effect of JBCS-729. > 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 > Assignee: Michal Karm > 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, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-681) CI: update to a newer Ubuntu version by specifying dist: xenial

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/MODCLUSTER-681?page=com.atlassian.jira.pl... ] Work on MODCLUSTER-681 started by Radoslav Husar. ------------------------------------------------- > CI: update to a newer Ubuntu version by specifying dist: xenial > --------------------------------------------------------------- > > Key: MODCLUSTER-681 > URL: https://issues.jboss.org/browse/MODCLUSTER-681 > Project: mod_cluster > Issue Type: Task > Components: CI & Packaging > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > This job ran on our Precise environment, which is in the process of being decommissioned. Please update to a newer Ubuntu version by specifying dist: xenial in your .travis.yml. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues April 2019