[JBoss JIRA] (MODCLUSTER-344) No pings when using HTTP connector in default configuration
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-344?page=com.atlassian.jira.pl... ]
Michal Babacek commented on MODCLUSTER-344:
-------------------------------------------
I will elaborate on it further:
There is this [enable_options|https://github.com/modcluster/mod_cluster/blob/1.2.x/nativ...] flag.
Further, there is the aforementioned [EnableOptions|https://github.com/modcluster/mod_cluster/blob/1.2.x/native...] directive.
What I find rather bewildering is the following code in [proxy_cluster_try_pingpong|https://github.com/modcluster/mod_cluster/blob...]:
{code}
if ((strcasecmp(scheme, "HTTPS") == 0 ||
strcasecmp(scheme, "HTTP") == 0) &&
!enable_options) {
/* we cant' do CPING/CPONG so we just return OK */
return APR_SUCCESS;
}
{code}
followed by [this|https://github.com/modcluster/mod_cluster/blob/1.2.x/native/mod_prox...]
{code}
if (strcasecmp(scheme, "AJP") == 0) {
status = ajp_handle_cping_cpong(backend->sock, r, timeout);
if (status != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
"proxy_cluster_try_pingpong: cping_cpong failed");
backend->close++;
}
} else {
if (!backend->connection) {
if ((status = ap_proxy_connection_create(scheme, backend,
(conn_rec *) NULL, r->server)) == OK) {
if (is_ssl) {
apr_table_set(backend->connection->notes, "proxy-request-hostname",
uri->hostname);
}
} else {
ap_proxy_release_connection(scheme, backend, r->server);
return status;
}
}
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
"proxy_cluster_try_pingpong: %d" , backend->connection);
status = http_handle_cping_cpong(backend, r, timeout);
if (status != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
"proxy_cluster_try_pingpong: cping_cpong failed");
backend->close++;
}
}
{code}
h3. AJP
Cool, we just do ajp_handle_cping_cpong.
h3. HTTP
In this case, if you kill the worker node, it will actually remain in *Status: OK* forever, because {{return APR_SUCCESS;}} is called due to {{EnableOptions}} being set to false by default.
Question: Why don't we skip the whole {{!enable_options}} thing in the first aforementioned snippet and just proceed to {{status = http_handle_cping_cpong(backend, r, timeout);}}, as in the second snippet?
The {{OPTIONS}} approach that solved [JBPAPP-10029] (CLOSE_WAIT with SSL connection...) and the whole {{http_handle_cping_cpong}} function is cool, yet, I feel like we did not go the whole way through. Would it be a performance drawback of any kind if we just use {{http_handle_cping_cpong}} the same way we use {{ajp_handle_cping_cpong}}?
h3. HTTPS
Uh, I have just tried to set {{EnableOptions}} for *HTTPS* test in order to get rid of the persistent *Status: OK*. What I have on my screen now is *Status* flickering with *OK* / *NOK* every several reloads of mod_cluster_manager console :D [^access_log], [^error_log], [^mod_cluster.conf]
I guess Rado might have stumbled upon something rather smelly. Anyhow, why and when should one use {{EnableOptions}} with regard to HTTPS connector?
> No pings when using HTTP connector in default configuration
> ------------------------------------------------------------
>
> Key: MODCLUSTER-344
> URL: https://issues.jboss.org/browse/MODCLUSTER-344
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.4.Final
> Reporter: Radoslav Husar
> Assignee: Jean-Frederic Clere
>
> When integrating Undertow, I realized the servers are never removed from m_c when I am using HTTP connector to workaroung broken cping/cpong in Undertow's AJP.
> One needs to configure EnableOptions to enable liveness checking, otherwise the node is never marked as NOTOK (in the larger than ping interval) until next request is received on that node and a client gets an unnecessary error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (MODCLUSTER-344) No pings when using HTTP connector in default configuration
by Radoslav Husar (JIRA)
Radoslav Husar created MODCLUSTER-344:
-----------------------------------------
Summary: No pings when using HTTP connector in default configuration
Key: MODCLUSTER-344
URL: https://issues.jboss.org/browse/MODCLUSTER-344
Project: mod_cluster
Issue Type: Bug
Affects Versions: 1.2.4.Final
Reporter: Radoslav Husar
Assignee: Jean-Frederic Clere
When integrating Undertow, I realized the servers are never removed from m_c when I am using HTTP connector to workaroung broken cping/cpong in Undertow's AJP.
One needs to configure EnableOptions to enable liveness checking, otherwise the node is never marked as NOTOK (in the larger than ping interval) until next request is received on that node and a client gets an unnecessary error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (MODCLUSTER-342) Cannot start apache
by Jose Giner (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-342?page=com.atlassian.jira.pl... ]
Jose Giner commented on MODCLUSTER-342:
---------------------------------------
Hi,
We start apache with debug level.
"
[Mon May 27 15:41:32 2013] [info] mod_unique_id: using ip addr 192.168.34.19
[Mon May 27 15:41:33 2013] [info] Init: Seeding PRNG with 136 bytes of entropy
[Mon May 27 15:41:33 2013] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Mon May 27 15:41:33 2013] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Mon May 27 15:41:33 2013] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
[Mon May 27 15:41:33 2013] [info] Init: Initializing (virtual) servers for SSL
[Mon May 27 15:41:33 2013] [info] mod_ssl/2.2.14 compiled against Server: Apache/2.2.14, Library: OpenSSL/0.9.8m
[Mon May 27 15:41:33 2013] [debug] util_ldap.c(1986): LDAP merging Shared Cache conf: shm=0x3005b478 rmm=0x3005b4a8 for VHOST: afrodita1
[Mon May 27 15:41:33 2013] [info] APR LDAP: Built with OpenLDAP LDAP SDK
[Mon May 27 15:41:33 2013] [info] LDAP: SSL support available
[Mon May 27 15:41:33 2013] [notice] Digest: generating secret for digest authentication ...
[Mon May 27 15:41:33 2013] [notice] Digest: done
[Mon May 27 15:41:33 2013] [info] mod_unique_id: using ip addr 192.168.34.19
[Mon May 27 15:41:34 2013] [info] Init: Seeding PRNG with 136 bytes of entropy
[Mon May 27 15:41:34 2013] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Mon May 27 15:41:34 2013] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Mon May 27 15:41:34 2013] [info] Init: Initializing (virtual) servers for SSL
[Mon May 27 15:41:34 2013] [info] mod_ssl/2.2.14 compiled against Server: Apache/2.2.14, Library: OpenSSL/0.9.8m
[Mon May 27 15:41:34 2013] [emerg] create_mem_host failed
Configuration Failed
"
> Cannot start apache
> -------------------
>
> Key: MODCLUSTER-342
> URL: https://issues.jboss.org/browse/MODCLUSTER-342
> Project: mod_cluster
> Issue Type: Feature Request
> Affects Versions: 1.1.3.Final
> Environment: LPAR on AIX 7 (httpd 2.2.14)
> Reporter: Jose Giner
> Assignee: Jean-Frederic Clere
>
> Hi,
> We cannot start apache.
> The error_log show:
> [Fri May 24 12:30:23 2013] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
> [Fri May 24 12:30:23 2013] [notice] Digest: generating secret for digest authentication ...
> [Fri May 24 12:30:23 2013] [notice] Digest: done
> [Fri May 24 12:30:24 2013] [emerg] create_mem_host failed
> Configuration Failed
> Regards,
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (MODCLUSTER-339) "proxy: DNS lookup failure" with IPv6 on Solaris
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-339?page=com.atlassian.jira.pl... ]
Michal Babacek commented on MODCLUSTER-339:
-------------------------------------------
Regarding the idea of removing the zone id, how about this: [https://github.com/modcluster/mod_cluster/pull/20/] ?
> "proxy: DNS lookup failure" with IPv6 on Solaris
> ------------------------------------------------
>
> Key: MODCLUSTER-339
> URL: https://issues.jboss.org/browse/MODCLUSTER-339
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.3.Final, 1.2.4.Final
> Environment: Solaris 10 x86, Solaris 11 x86, Solaris 11 SPARC
> Reporter: Michal Babacek
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Labels: ipv6
> Fix For: 1.2.5.Final
>
> Attachments: access_log-mod_cluster, error_log-mod_cluster, error_log-mod_cluster-RHEL, error_log-proxypass, http.conf
>
>
> h2. Failure with mod_cluster
> Having the following setting:
> {code:title=mod_cluster.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1}
> LoadModule slotmem_module modules/mod_slotmem.so
> LoadModule manager_module modules/mod_manager.so
> LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
> LoadModule advertise_module modules/mod_advertise.so
> MemManagerFile "/tmp/mod_cluster-eap6/jboss-ews-2.0/var/cache/mod_cluster"
> ServerName [2620:52:0:105f::ffff:50]:2080
> <IfModule manager_module>
> Listen [2620:52:0:105f::ffff:50]:6666
> LogLevel debug
> <VirtualHost [2620:52:0:105f::ffff:50]:6666>
> ServerName [2620:52:0:105f::ffff:50]:6666
> <Directory />
> Order deny,allow
> Deny from all
> Allow from all
> </Directory>
> KeepAliveTimeout 60
> MaxKeepAliveRequests 0
> ServerAdvertise on
> AdvertiseFrequency 5
> ManagerBalancerName qacluster
> AdvertiseGroup [ff01::7]:23964
> EnableMCPMReceive
> <Location /mcm>
> SetHandler mod_cluster-manager
> Order deny,allow
> Deny from all
> Allow from all
> </Location>
> </VirtualHost>
> </IfModule>
> {code}
> I get a weird {{proxy: DNS lookup failure}} as soon as worker sends {{CONFIGURE}}}:
> {code:title=access_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1}
> 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "INFO / HTTP/1.1" 200 - "-" "ClusterListener/1.0"
> 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "CONFIG / HTTP/1.1" 200 - "-" "ClusterListener/1.0"
> 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "STATUS / HTTP/1.1" 200 64 "-" "ClusterListener/1.0"
> ...
> {code}
> {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1}
> ...
> [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans INFO (/)
> [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler INFO (/) processing: ""
> [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler INFO OK
> [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans CONFIG (/)
> [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler CONFIG (/) processing: "JVMRoute=jboss-eap-6.1&Host=%5B2620%3A52%3A0%3A105f%3A0%3A0%3Affff%3A50%252%5D&Maxattempts=1&Port=8009&StickySessionForce=No&Type=ajp&ping=10"
> [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler CONFIG OK
> [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans STATUS (/)
> [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler STATUS (/) processing: "JVMRoute=jboss-eap-6.1&Load=100"
> [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1638): Processing STATUS
> [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(655): add_balancer_node: Create balancer balancer://qacluster
> [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(426): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009
> [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(532): proxy: initialized worker 1 in child 16847 for (2620:52:0:105f:0:0:ffff:50%2) min=0 max=25 smax=25
> [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(601): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009 1 (status): 1
> [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (2620:52:0:105f:0:0:ffff:50%2)
> [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009/ to 2620:52:0:105f:0:0:ffff:50%2:8009
> [Thu May 16 08:37:24 2013] [error] [client 2620:52:0:105f::ffff:50] proxy: DNS lookup failure for: 2620:52:0:105f:0:0:ffff:50%2 returned by /
> [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (2620:52:0:105f:0:0:ffff:50%2)
> ...
> {code}
> An attempt to access the mod_cluster manager console yields an unpleasant {{NOTOK}} (obviously, we have All workers are in error state...):
> {code}
> curl -g [2620:52:0:105f::ffff:50]:6666/mcm
> ...
> <h1> Node jboss-eap-6.1 (ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009): </h1>
> <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=ENABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Enable Contexts</a> <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=DISABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Disable Contexts</a><br/>
> Balancer: qacluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 26,Ttl: 60000000,Status: NOTOK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: -1
> {code}
> You might take a look at the logs: [^error_log-mod_cluster], [^access_log-mod_cluster].
> h2. ProxyPass itself works just fine
> On the other hand, when I had tried this:
> {code:title=proxypass.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1}
> LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
> ServerName [2620:52:0:105f::ffff:50]:2080
> Listen [2620:52:0:105f::ffff:50]:6666
> LogLevel debug
> <VirtualHost [2620:52:0:105f::ffff:50]:6666>
> ServerName [2620:52:0:105f::ffff:50]:6666
> ProxyPass / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/
> ProxyPassReverse / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/
> <Directory />
> Order deny,allow
> Deny from all
> Allow from all
> </Directory>
> </VirtualHost>
> {code}
> I received:
> {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1}
> ...
> [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(45): proxy: AJP: canonicalising URL //[2620:52:0:105f:0:0:ffff:50]:8009/
> [Thu May 16 08:29:00 2013] [debug] proxy_util.c(1506): [client 2620:52:0:105f::ffff:50] proxy: ajp: found worker ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ for ajp://[2620:52:0:105f:0:0:ffff:50]:8009/
> [Thu May 16 08:29:00 2013] [debug] mod_proxy.c(1020): Running scheme ajp handler (attempt 0)
> [Thu May 16 08:29:00 2013] [debug] mod_proxy_http.c(1963): proxy: HTTP: declining URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/
> [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(681): proxy: AJP: serving URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/
> [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2011): proxy: AJP: has acquired connection for (2620:52:0:105f:0:0:ffff:50)
> [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ to 2620:52:0:105f:0:0:ffff:50:8009
> [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2193): proxy: connected / to 2620:52:0:105f:0:0:ffff:50:8009
> [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2444): proxy: AJP: fam 26 socket created to connect to 2620:52:0:105f:0:0:ffff:50
> ...
> {code}
> And from the client's side, it worked:
> {{curl -g [2620:52:0:105f::ffff:50]:6666/}} brought me the worker's home page (EAP's welcome in this case).
> Take a look at the whole log [^error_log-proxypass].
> *Note:* The [^http.conf] was the same both for mod_cluster and for proxypass test.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (MODCLUSTER-342) Cannot start apache
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-342?page=com.atlassian.jira.pl... ]
Jean-Frederic Clere commented on MODCLUSTER-342:
------------------------------------------------
shared memory issues? try to change the loglevel to debug and check the error_log file.
> Cannot start apache
> -------------------
>
> Key: MODCLUSTER-342
> URL: https://issues.jboss.org/browse/MODCLUSTER-342
> Project: mod_cluster
> Issue Type: Feature Request
> Affects Versions: 1.1.3.Final
> Environment: LPAR on AIX 7 (httpd 2.2.14)
> Reporter: Jose Giner
> Assignee: Jean-Frederic Clere
>
> Hi,
> We cannot start apache.
> The error_log show:
> [Fri May 24 12:30:23 2013] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
> [Fri May 24 12:30:23 2013] [notice] Digest: generating secret for digest authentication ...
> [Fri May 24 12:30:23 2013] [notice] Digest: done
> [Fri May 24 12:30:24 2013] [emerg] create_mem_host failed
> Configuration Failed
> Regards,
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (MODCLUSTER-342) Cannot start apache
by Jose Giner (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-342?page=com.atlassian.jira.pl... ]
Jose Giner commented on MODCLUSTER-342:
---------------------------------------
MemManagerFile /var/cache/httpd does it exist? Yes. it is.
Is it writable by the httpd user? Yes, the user is root.
Any SELinux/or UAC security like on the box? I don't know, but I think that anything.
> Cannot start apache
> -------------------
>
> Key: MODCLUSTER-342
> URL: https://issues.jboss.org/browse/MODCLUSTER-342
> Project: mod_cluster
> Issue Type: Feature Request
> Affects Versions: 1.1.3.Final
> Environment: LPAR on AIX 7 (httpd 2.2.14)
> Reporter: Jose Giner
> Assignee: Jean-Frederic Clere
>
> Hi,
> We cannot start apache.
> The error_log show:
> [Fri May 24 12:30:23 2013] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
> [Fri May 24 12:30:23 2013] [notice] Digest: generating secret for digest authentication ...
> [Fri May 24 12:30:23 2013] [notice] Digest: done
> [Fri May 24 12:30:24 2013] [emerg] create_mem_host failed
> Configuration Failed
> Regards,
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (MODCLUSTER-342) Cannot start apache
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-342?page=com.atlassian.jira.pl... ]
Jean-Frederic Clere commented on MODCLUSTER-342:
------------------------------------------------
MemManagerFile /var/cache/httpd
does it exist? Is it writable by the httpd user? Any SELinux/or UAC security like on the box?
> Cannot start apache
> -------------------
>
> Key: MODCLUSTER-342
> URL: https://issues.jboss.org/browse/MODCLUSTER-342
> Project: mod_cluster
> Issue Type: Feature Request
> Affects Versions: 1.1.3.Final
> Environment: LPAR on AIX 7 (httpd 2.2.14)
> Reporter: Jose Giner
> Assignee: Jean-Frederic Clere
>
> Hi,
> We cannot start apache.
> The error_log show:
> [Fri May 24 12:30:23 2013] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
> [Fri May 24 12:30:23 2013] [notice] Digest: generating secret for digest authentication ...
> [Fri May 24 12:30:23 2013] [notice] Digest: done
> [Fri May 24 12:30:24 2013] [emerg] create_mem_host failed
> Configuration Failed
> Regards,
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months