On Friday 12 of April 2013, Arkadiusz Miśkiewicz wrote:
> 6) possible solution - detect that sending dummy_connection data weren't
> processed by children by trying to read reply
>
> diff -ur httpd-2.4.4.org/server/mpm_unix.c httpd-2.4.4/server/mpm_unix.c
> --- httpd-2.4.4.org/server/mpm_unix.c 2012-07-03 21:38:58.000000000 +0200
> +++ httpd-2.4.4/server/mpm_unix.c 2013-04-12 09:14:58.282929959 +0200
> @@ -604,7 +604,17 @@
> len = strlen(data);
> }
>
> - apr_socket_send(sock, data, &len);
> + rv = apr_socket_send(sock, data, &len);
> + if (rv == APR_SUCCESS) {
> + char *buffer[10]; // dummy buffer to see if child is alive
> +
> + len = sizeof(buffer);
> + rv = apr_socket_recv(sock, buffer, &len);
> + if (rv != APR_SUCCESS) {
> + ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, ap_server_conf,
> APLOGNO(00057) + "receiving response to dummy data
> to listener on %pI", lp->bind_addr); + }
> + }
> apr_socket_close(sock);
> apr_pool_destroy(p);
Not sure how to deal with SSL dummy connection though. With SSL children sends
no reply in response to tls10_close_notify.
apr_socket_recv method works only for non-SSL connections.
Maybe there is another way to check which children are alive at
dummy_connection level (and avoiding sending anything if there are no
children) ?
--
Arkadiusz Miśkiewicz, arekm / maven.pl
