[mod_cluster-issues] [JBoss JIRA] (MODCLUSTER-344) No pings when using HTTP connector in default configuration

[Michal Babacek (JIRA)]

    [ https://issues.jboss.org/browse/MODCLUSTER-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777219#comment-12777219 ] 

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/native/mod_proxy_cluster/mod_proxy_cluster.c#L95] flag.
Further, there is the aforementioned [EnableOptions|https://github.com/modcluster/mod_cluster/blob/1.2.x/native/mod_proxy_cluster/mod_proxy_cluster.c#L3903] directive.

What I find rather bewildering is the following code in [proxy_cluster_try_pingpong|https://github.com/modcluster/mod_cluster/blob/1.2.x/native/mod_proxy_cluster/mod_proxy_cluster.c#L1226]:

{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_proxy_cluster/mod_proxy_cluster.c#L1370]
{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