[JBoss JIRA] (MODCLUSTER-463) UpperCase Alias never matches any context
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-463?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on MODCLUSTER-463:
----------------------------------------------------
Jean-frederic Clere <jclere(a)redhat.com> changed the Status of [bug 1340958|https://bugzilla.redhat.com/show_bug.cgi?id=1340958] from MODIFIED to ON_QA
> UpperCase Alias never matches any context
> -----------------------------------------
>
> Key: MODCLUSTER-463
> URL: https://issues.jboss.org/browse/MODCLUSTER-463
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.2.11.Final, 1.3.1.Final
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Fix For: 1.3.3.Final, 1.2.13.Final
>
> Attachments: simplecontext-examples.zip
>
>
> h3. Problem
> h4. JBossWeb
> Regardless the upper/lower case of an Alias one configured in _JBossWeb (EAP 6.4.3, mod_cluster subsystem 1.2.11.Final)_, it has always been reported to Apache HTTP Server in lower case. For example, the following configuration:{code:xml}
> <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" instance-id="workerXXX" native="false">
> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> <virtual-server name="web1" default-web-module="simplecontext-web1">
> <alias name="web1.rhel7GAx86-64"/>
> </virtual-server>
> <virtual-server name="web2" default-web-module="simplecontext-web2">
> <alias name="web2.rhel7GAx86-64"/>
> </virtual-server>
> </subsystem>
> {code}sends this message with aliases actually being reported in lower case: {{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7gax86-64&Context=%2F}}. Having {{aliases}} stored in lower case on the Apache HTTP Server side enables both these URLs to work perfectly:{noformat}curl http://web2.rhel7GAx86-64:6666/
> curl http://web2.rhel7gax86-64:6666/{noformat}. The balancer configuration is just a simple [UseAlias 1|http://fpaste.org/251417/86985831/].
> h4. Undertow
> _Undertow (JBossWeb's successor in EAP 7.0.0.DR7, mod_cluster subsystem 1.3.1.Final)_ behaves differently; it reports verbatim what one sets as an alias, so with the following configuration:{code:xml}<subsystem xmlns="urn:jboss:domain:undertow:3.0" instance-id="workerXXX">
> <buffer-cache name="default"/>
> <server name="default-server">
> <ajp-listener name="ajp" socket-binding="ajp"/>
> <http-listener name="default" redirect-socket="https" socket-binding="http"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> <host name="web1" alias="web1.rhel7GAx86-64">
> <location name="/" handler="web1-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> <host name="web2" alias="web2.rhel7GAx86-64">
> <location name="/" handler="web2-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> <websockets/>
> </servlet-container>
> <handlers>
> <file name="web1-content" path="${jboss.home.dir}/simplecontext-web1"/>
> <file name="web2-content" path="${jboss.home.dir}/simplecontext-web2"/>
> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
> </handlers>
> <filters>
> <response-header name="server-header" header-value="WildFly/10" header-name="Server"/>
> <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
> </filters>
> </subsystem>{code}, the message reported to Apache HTTP Server actually is:{{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7GAx86-64&Context=%2F}}. Due to the fact that aliases are being compared byte-by-byte for equality (because pumping of slash characters takes place) and the accessed domain is always in lower case and alias is stored as it was received, there is never match between these.
> The result is that while these work:{{http://web2:6666/}}, {{http://web1:6666/}}, one of the upper case containing ones work at all: {{http://web1.rhel7GAx86-64:6666}} and {{http://web2.rhel7gax86-64:6666/}} neither. By not working I actually mean they return the root of Apache HTTP Server Welcome page instead of correctly forwarding to one of the Application server's virtual host contexts.
> Last but not least, while EAP 6.4.3 with JBossWeb itself treats aliases as case-insensitive, EAP 7.0.0.DR7 with Undertow does not; i.e. {{web1.rhel7GAx86-64:8080/}} returns correctly web application content whereas {{web1.rhel7gax86-64:8080/}} returns EAP7 Welcome page.
> While the aforementioned is clearly a bug (or a weird feature :)) in Undertow, we must make the Apache HTTP Server code resilient to such behaviour.
> h3. Solution
> I suggest converting aliases to lower case in mod_manager on ENABLE-APP arrival. According to my preliminary tests, this approach works for both JBossWeb and Undertow equipped workers. I think it's cool to do that: [RFC 1035|https://tools.ietf.org/html/rfc1035#section-2.3.3].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (MODCLUSTER-466) mod_cluster undersizes the connection pool on httpd 2.2
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-466?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on MODCLUSTER-466:
----------------------------------------------------
Jean-frederic Clere <jclere(a)redhat.com> changed the Status of [bug 1338642|https://bugzilla.redhat.com/show_bug.cgi?id=1338642] from MODIFIED to ON_QA
> mod_cluster undersizes the connection pool on httpd 2.2
> -------------------------------------------------------
>
> Key: MODCLUSTER-466
> URL: https://issues.jboss.org/browse/MODCLUSTER-466
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Reporter: Aaron Ogburn
> Assignee: Jean-Frederic Clere
> Fix For: 1.3.2.Final, 1.2.13.Final
>
>
> If all threads in a httpd child worker process are saturated with long requests, then all connections in the pool are exhausted, likely leaving none available for additional pings, which then fail with errors like:
> [error] (70007)The timeout specified has expired: proxy: ajp: failed to acquire connection for ...
> Documentation suggests the connection pool will be sized to ThreadsPerChild+1 to avoid that, but it looks like it is really just ThreadsPerChild on httpd 2.2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[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:
-------------------------------------------
Environment: Fedora 20, x86_64, httpd 2.4.20 mpm_event (was: Fedora 20, x86_64, httpd 2.4.20)
> 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: 1.3.4.Final
>
>
> 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
(v6.4.11#64026)
7 years, 9 months
[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 commented on MODCLUSTER-526:
------------------------------------------------
[~aogburn], could you share your opinion on the issue?
> 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
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Priority: Blocker
> Fix For: 1.3.4.Final
>
>
> 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
(v6.4.11#64026)
7 years, 9 months
[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:
-------------------------------------------
Description:
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]
was:
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}
> 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
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Priority: Blocker
> Fix For: 1.3.4.Final
>
>
> 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
(v6.4.11#64026)
7 years, 9 months
[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:
-------------------------------------------
Description:
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}
was:
* 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
{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}
> 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
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Priority: Blocker
> Fix For: 1.3.4.Final
>
>
> 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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (MODCLUSTER-509) Excluded contexts which are not specific to a host should be excluded on all hosts
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-509?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-509:
--------------------------------------
Summary: Excluded contexts which are not specific to a host should be excluded on all hosts (was: Excluded contexts not specific to a host should be excluded on all hosts)
> Excluded contexts which are not specific to a host should be excluded on all hosts
> ----------------------------------------------------------------------------------
>
> Key: MODCLUSTER-509
> URL: https://issues.jboss.org/browse/MODCLUSTER-509
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.3.2.Final, 1.2.12.Final, 2.0.0.Alpha1
> Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 1.3.3.Final, 2.0.0.Alpha1, 1.2.13.Final
>
>
> With the following configuration:
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener"
> loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric"
> loadMetricCapacity="1"
> loadHistory="9"
> loadDecayFactor="2"
> stickySession="true"
> stickySessionForce="false"
> stickySessionRemove="true"
> advertise="true"
> advertiseGroupAddress="224.0.1.105"
> advertisePort="23364"
> advertiseInterface="10.40.4.50"
> excludedContexts="ROOT,docs,manager,host-manager,examples"
> />
> {code}
> And these contexts in webapps:
> {code}
> clusterbench docs examples host-manager manager ROOT
> {code}
> One expects this output on Mod_cluster manger console:
> {code}
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> It works, unless you configure additional VirtualHosts:
> {code}
> <Host name="LOCALHOST" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>LOCALHOST</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>KARM.BRQ.REDHAT.COM</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> {code}
> result:
> {code}
> Node worker1 (ajp://10.40.4.50:8009):
> Enable Contexts Disable Contexts Stop Contexts
> Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100
> Virtual Host 2:
> Contexts:
> /docs, Status: ENABLED Request: 0 Disable Stop
> /manager, Status: ENABLED Request: 0 Disable Stop
> /host-manager, Status: ENABLED Request: 0 Disable Stop
> /examples, Status: ENABLED Request: 0 Disable Stop
> /, Status: ENABLED Request: 0 Disable Stop
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> karm.brq.redhat.com
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't.
> WDYT? Is it possible to tweak with the Listener's configuration somehow?
> THX.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[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 started 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
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Priority: Blocker
> Fix For: 1.3.4.Final
>
>
> * 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
> {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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months