Returning large objects from a user implemented hook
Hi, I'm trying to implement a hook in a module I'm developing that will allow languages such as PHP to access it. Part of the information I need to pass back will be in the form of 64 byte data blocks. As I see it, these are my options: 1. Return the block as the return value. Compiler complains, as it should. 2. Pass in a pointer to memory that will contain the data. This segfaults. 3. Allocate memory and return a pointer. Wouldn't this segfault as well? 4. ??? Suggestions? Not all of life fits in an integer :) TIA, Dave
[PATCH] Further refinements for SNI
While I was testing revocation checking for client certs in an SNI
configuration (Dirk, many thanks for make_sni.sh, btw!), I came across a
flaw in the current implementation when CRL information - i.e.
SSLCARevocationFile/SSLCARevocationPath - is set on a per-vhost basis
(don't know how much sense it makes to have non-global CRLs, but anyway...).
The attached patch addresses this issue, and it also improves the
logging behavior for an SNI enabled configuration (previously some of
the messages would always go to the first vhost, or wouldn't appear at
all, depending on the LogLevel of the first vhost).
Kaspar
Index: httpd-trunk/modules/ssl/ssl_engine_kernel.c
===
--- httpd-trunk/modules/ssl/ssl_engine_kernel.c (revision 627257)
+++ httpd-trunk/modules/ssl/ssl_engine_kernel.c (working copy)
@@ -2017,14 +2017,32 @@ static int ssl_find_vhost(void *serverna
* SSL connection is set up (num_renegotiations == 0).
* Otherwise, we would possibly reset a per-directory
* configuration which was put into effect by ssl_hook_Access.
*/
SSL_set_verify(ssl, SSL_CTX_get_verify_mode(ssl-ctx),
SSL_CTX_get_verify_callback(ssl-ctx));
}
+/*
+ * We also need to make sure that the correct mctx is
+ * assigned to the connection - the CRL callback e.g.
+ * makes use of it for retrieving its store (mctx-crl).
+ * Since logging in callbacks uses c-base_server in many
+ * cases, it also ensures that these messages are routed
+ * to the proper log. And finally, there is one special
+ * filter callback, which is set very early depending on the
+ * base_server's log level. If this is not the first vhost
+ * we're now selecting (and the first vhost doesn't use
+ * APLOG_DEBUG), then we need to set that callback here.
+ */
+c-base_server = s;
+if (c-base_server-loglevel = APLOG_DEBUG) {
+BIO_set_callback(SSL_get_rbio(ssl), ssl_io_data_cb);
+BIO_set_callback_arg(SSL_get_rbio(ssl), (void *)ssl);
+}
+
return 1;
}
return 0;
}
#endif
DisableReuse for mod_proxy
I added something similar to mod_jk quite awhile ago, and
I'm trying to get mod_jk and mod_proxy closer to parity,
esp for those using AJP. So with that in mind, comments
on the below??
Index: docs/manual/mod/mod_proxy.xml
===
--- docs/manual/mod/mod_proxy.xml (revision 627440)
+++ docs/manual/mod/mod_proxy.xml (working copy)
@@ -693,6 +693,16 @@
in the pool the Apache will return codeSERVER_BUSY/code
status to
the client.
/td/tr
+trtddisablereuse/td
+tdOff/td
+tdThis parameter should be used when you want to force
mod_proxy
+to immediately close a connection to the backend after being
used, and
+thus, disable its persistant connection and pool for that backend.
+This helps in various situations where a firewall between Apache
and
+the backend server (irregardless of protocol) tends to silently
+drop connections. To prevent mod_proxy from reusing the backend
connection,
+set this property value to codeOn/code.
+/td/tr
trtdflushpackets/td
tdoff/td
tdDetermines whether the proxy module will auto-flush the
output
Index: CHANGES
===
--- CHANGES (revision 627440)
+++ CHANGES (working copy)
@@ -2,6 +2,10 @@
Changes with Apache 2.3.0
[ When backported to 2.2.x, remove entry from this file ]
+ *) Added 'disablereuse' option for ProxyPass which, essentially,
+ disables connection pooling for the backend servers.
+ [Jim Jagielski]
+
*) Activate mod_cache, mod_file_cache and mod_disc_cache as part
of the
'most' set for '--enable-modules' and '--enable-shared-mods'.
Include
mod_mem_cache in 'all' as well. [Dirk-Willem van Gulik]
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c (revision 627440)
+++ modules/proxy/proxy_util.c (working copy)
@@ -1698,7 +1698,7 @@
}
/* determine if the connection need to be closed */
-if (conn-close || !worker-is_address_reusable) {
+if (conn-close || !worker-is_address_reusable || worker-
disablereuse) {
apr_pool_t *p = conn-pool;
apr_pool_clear(p);
conn = apr_pcalloc(p, sizeof(proxy_conn_rec));
@@ -1902,8 +1902,13 @@
if (!worker-retry_set) {
worker-retry = apr_time_from_sec(PROXY_WORKER_DEFAULT_RETRY);
}
-/* By default address is reusable */
-worker-is_address_reusable = 1;
+/* By default address is reusable unless DisableReuse is set */
+if (worker-disablereuse) {
+worker-is_address_reusable = 0;
+}
+else {
+worker-is_address_reusable = 1;
+}
#if APR_HAS_THREADS
ap_mpm_query(AP_MPMQ_MAX_THREADS, mpm_threads);
@@ -2114,7 +2119,8 @@
*
* TODO: Handle this much better...
*/
-if (!conn-hostname || !worker-is_address_reusable ||
+if (!conn-hostname || !worker-is_address_reusable ||
+ worker-disablereuse ||
(r-connection-keepalives
(r-proxyreq == PROXYREQ_PROXY || r-proxyreq ==
PROXYREQ_REVERSE)
(strcasecmp(conn-hostname, uri-hostname) != 0) ) ) {
Index: modules/proxy/mod_proxy.c
===
--- modules/proxy/mod_proxy.c (revision 627440)
+++ modules/proxy/mod_proxy.c (working copy)
@@ -176,6 +176,15 @@
return KeepAlive must be On|Off;
worker-keepalive_set = 1;
}
+else if (!strcasecmp(key, disablereuse)) {
+if (!strcasecmp(val, on))
+worker-disablereuse = 1;
+else if (!strcasecmp(val, off))
+worker-disablereuse = 0;
+else
+return DisableReuse must be On|Off;
+worker-disablereuse_set = 1;
+}
else if (!strcasecmp(key, route)) {
/* Worker route.
*/
Index: modules/proxy/mod_proxy.h
===
--- modules/proxy/mod_proxy.h (revision 627440)
+++ modules/proxy/mod_proxy.h (working copy)
@@ -352,6 +352,8 @@
char ping_timeout_set;
int lbset; /* load balancer cluster set */
charretry_set;
+chardisablereuse;
+chardisablereuse_set;
};
/*
Re: DisableReuse for mod_proxy
On 13.02.2008, at 16:27, Jim Jagielski wrote: I added something similar to mod_jk quite awhile ago, and I'm trying to get mod_jk and mod_proxy closer to parity, esp for those using AJP. So with that in mind, comments on the below?? Index: docs/manual/mod/mod_proxy.xml === --- docs/manual/mod/mod_proxy.xml (revision 627440) +++ docs/manual/mod/mod_proxy.xml (working copy) @@ -693,6 +693,16 @@ in the pool the Apache will return codeSERVER_BUSY/code status to the client. /td/tr +trtddisablereuse/td +tdOff/td +tdThis parameter should be used when you want to force mod_proxy +to immediately close a connection to the backend after being used, and +thus, disable its persistant connection and pool for that backend. persistent instead of persistant? +1 to the rest. Cheers, Erik
Re: DisableReuse for mod_proxy
On Feb 13, 2008, at 10:45 AM, Erik Abele wrote: On 13.02.2008, at 16:27, Jim Jagielski wrote: I added something similar to mod_jk quite awhile ago, and I'm trying to get mod_jk and mod_proxy closer to parity, esp for those using AJP. So with that in mind, comments on the below?? Index: docs/manual/mod/mod_proxy.xml === --- docs/manual/mod/mod_proxy.xml (revision 627440) +++ docs/manual/mod/mod_proxy.xml (working copy) @@ -693,6 +693,16 @@ in the pool the Apache will return codeSERVER_BUSY/code status to the client. /td/tr +trtddisablereuse/td +tdOff/td +tdThis parameter should be used when you want to force mod_proxy +to immediately close a connection to the backend after being used, and +thus, disable its persistant connection and pool for that backend. persistent instead of persistant? +1 to the rest. me no spelll too guud :)
ping for http in mod_proxy
I've started looking at adding ping support for mod_proxy_http to complement whats in mod_proxy_ajp... The idea is to send a simple OPTIONS * to the backend and hope for a reply. The rub is that I've been working on 2 separate implementations: one talks direct to the socket and the other basically tries to do what ap_proxy_http_request() and ap_proxy_http_process_response() does, as far as using brigades, etc... The former is much further along, btw. In any case, both implementations can have what I can envision as some weird effects as far as how they should actually work in the real world. For example, should it honor force-proxy-request-1.0 and/or proxy-nokeepalive, and, if so, how does that affect the subsequent real request... In other words, it's not as clean as AJP which has a real ping. And all this is wondering whether or not it's really useful in the 1st place... So before I go any further, any comments or ideas on whether is is even a Good Idea or not... I'm starting to have 2nd thoughts :)
Re: ping for http in mod_proxy
-Ursprüngliche Nachricht- Von: Akins, Brian Gesendet: Mittwoch, 13. Februar 2008 18:23 An: dev@httpd.apache.org Betreff: Re: ping for http in mod_proxy On 2/13/08 11:07 AM, Jim Jagielski [EMAIL PROTECTED] wrote: I've started looking at adding ping support for mod_proxy_http to complement whats in mod_proxy_ajp... The idea is to send a simple OPTIONS * to the backend and hope for a reply. Would it be more useful to have active healthchecking to backend servers? This does not help with race conditions on HTTP keepalive connections. Nevertheless active healthchecking could be useful. But on a busy site I guess a real request will notice before the healthcheck that one backend is down or the frequence of health checks needs to be insane. Regards Rüdiger
re: ping for http in mod_proxy
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 13. Februar 2008 17:07 An: dev@httpd.apache.org Betreff: ping for http in mod_proxy I've started looking at adding ping support for mod_proxy_http to complement whats in mod_proxy_ajp... The idea is to send a simple OPTIONS * to the backend and hope for a reply. The rub is that I've been working on 2 separate implementations: one talks direct to the socket and the other basically tries to do what ap_proxy_http_request() and ap_proxy_http_process_response() does, as far as using brigades, etc... The former is much further along, btw. We cannot use the socket approach since we need to be able to handle SSL backend connections and this requires the brigades - filters approach. In any case, both implementations can have what I can envision as some weird effects as far as how they should actually work in the real world. For example, should it honor force-proxy-request-1.0 and/or proxy-nokeepalive, and, if so, how does that affect I think the ping is of limited use for HTTP/1.0 / non keepalive requests. I see it mainly as a measure to avoid race conditions with keepalive connections that get closed just in the moment as the request is being sent. The only benefit I would see for HTTP/1.0 / non keepalive requests would be that a successful connect call (we always create a new connections in this case) does not guarantee us that you get *any* response (in a timely manner). This could be because the connect is queued up on the backend in the connection backlog or in an application specific request queue and will be never processed. the subsequent real request... In other words, it's not as clean as AJP which has a real ping. And all this is wondering whether or not it's really useful in the 1st place... So before I go any further, any comments or ideas on whether is is even a Good Idea or not... I'm starting to have 2nd thoughts :) It is a good idea for certain purposes and I really appreciate that you work on this. This issue is still on my when-I-got-time-TODO list. If not done until then, maybe something for the hackathon to work on. Regards Rüdiger
Re: mod_proxy timeouts in the 2.0
Sorry again for the lack of attachment. :(
There definitely is confusion here and it's definitely my
fault. First, the lack of attachment. Second, I have
made this both a fix *and* a feature both of which only
apply to the 2.0 line.
I'm including the patch again and can modify it to include
just the fix part if that will help get it included in the
2.0 line.
Ron
On Thu, 2008-02-07 at 09:06 +0100, jean-frederic clere wrote:
Chris H. wrote:
Quoting Jim Jagielski [EMAIL PROTECTED]:
On Feb 5, 2008, at 2:52 PM, Ronald Park wrote:
Attached is my patch to 2.0.63 to the proxy_http.c file in
modules/proxy.
I didn't see any attached patch... :/
Without the patch the whole discussion is useless ;-(
In any case, the normal process is patch applied to
trunk with then backport proposals to 2.2 and 2.0. A feature
added to 2.0.x, without it being in 2.2 and trunk is likely
not gonna happen.
If I understood the original posting correctly. This is a /fix/
not a /feature/. Isn't there any interest in correcting issues
in the 2.0.x branch? Or am I to understand that the term feature
also means fix(es). :)
What we normally do is to fix trunk and port back to 2.2.x and/or 2.0.x.
Cheers
Jean-Frederic
--- modules/proxy/proxy_http.c.orig 2007-09-04 15:33:45.0 -0400
+++ modules/proxy/proxy_http.c 2008-02-04 14:57:21.0 -0500
@@ -379,6 +379,36 @@
proxy: HTTP: pre_connection setup failed (%d),
rc);
return rc;
+} else {
+// that pre_connection code sets the socket timeout as
+// the value of Timeout which is the timeout of the
+// original request; by the time that is hit, our client
+// has already been given a timeout
+//
+// instead, we'll look to see if an env var, proxy-timeout,
+// has been set: if so, we use it; otherwise, we use
+// the setting for ProxyTimeout (if set); (otherwise, we
+// will stick with the value of Timeout.)
+const char* tbl_timeout;
+apr_interval_time_t timeout = (conf-timeout_set) ?
+ conf-timeout : 0;
+
+tbl_timeout = apr_table_get(r-subprocess_env, proxy-timeout);
+if (tbl_timeout == NULL) {
+tbl_timeout = apr_table_get(r-notes, proxy-timeout);
+}
+if (tbl_timeout != NULL) {
+int int_timeout = atoi(tbl_timeout);
+if (int_timeout 0) {
+ timeout = apr_time_from_sec(int_timeout);
+}
+}
+if (timeout 0) {
+apr_socket_timeout_set(p_conn-sock, timeout);
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
+ proxy: setting request timeout (%d), timeout);
+}
+
}
}
return OK;
Re: ping for http in mod_proxy
On 2/13/08 11:07 AM, Jim Jagielski [EMAIL PROTECTED] wrote: I've started looking at adding ping support for mod_proxy_http to complement whats in mod_proxy_ajp... The idea is to send a simple OPTIONS * to the backend and hope for a reply. Would it be more useful to have active healthchecking to backend servers? Ie, periodically hit a url on each origin and mark them up/down based on response. Only send traffic to up servers. I think mod_backhand does something similar but much more complex (?). I had started looking to add this to balancer, but I have no time. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: ping for http in mod_proxy
-Ursprüngliche Nachricht- Von: Akins, Brian Gesendet: Mittwoch, 13. Februar 2008 18:34 An: dev@httpd.apache.org Betreff: Re: ping for http in mod_proxy On 2/13/08 12:27 PM, Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote: This does not help with race conditions on HTTP keepalive connections. Nevertheless active healthchecking could be useful. But on a busy site I guess a real request will notice before the healthcheck that one backend is down or the frequence of health checks needs to be insane. On a busy site you want to know if a server is down before you send a few thousand requests to it and want to know that it's up as soon as it's available so you can send a few thousand requests to it. Agreed, but I doubt that it is possible with a reasonable amout of health check frequency to find out before the first real request falls through, provided that your health checks are designed to only fail if the backend is down. If your health checks are smarter and notice that the backend will fail soon (e.g. because it reached 98% or 99% percent of its capacity) then this is a different story and can be very useful. Regarding the reactivation of a failed backend I fully agree: Active health checks would be an asset here instead of just retrying failed backends periodically with real requests. Regards Rüdiger
Re: ping for http in mod_proxy
On 2/13/08 12:41 PM, Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote: If your health checks are smarter and notice that the backend will fail soon (e.g. because it reached 98% or 99% percent of its capacity) then this is a different story and can be very useful. Correct. Perhaps a weighted round-robin that is based on response time would be fairly easy to code... (Says the guy with no time.) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: ping for http in mod_proxy
On Feb 13, 2008, at 12:22 PM, Akins, Brian wrote: On 2/13/08 11:07 AM, Jim Jagielski [EMAIL PROTECTED] wrote: I've started looking at adding ping support for mod_proxy_http to complement whats in mod_proxy_ajp... The idea is to send a simple OPTIONS * to the backend and hope for a reply. Would it be more useful to have active healthchecking to backend servers? Ie, periodically hit a url on each origin and mark them up/down based on response. Only send traffic to up servers. I think mod_backhand does something similar but much more complex (?). I had started looking to add this to balancer, but I have no time. That was the other option as well... some sort of hearbeat loop which updates worker status. Still, we get into the issue with how much of how proxy connects to and communicates with the backend to honor or work around.
Re: ping for http in mod_proxy
On Feb 13, 2008, at 12:27 PM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Akins, Brian Gesendet: Mittwoch, 13. Februar 2008 18:23 An: dev@httpd.apache.org Betreff: Re: ping for http in mod_proxy On 2/13/08 11:07 AM, Jim Jagielski [EMAIL PROTECTED] wrote: I've started looking at adding ping support for mod_proxy_http to complement whats in mod_proxy_ajp... The idea is to send a simple OPTIONS * to the backend and hope for a reply. Would it be more useful to have active healthchecking to backend servers? This does not help with race conditions on HTTP keepalive connections. We will never be able to completely avoid race conditions... whether keepalives are in place or not.
Re: ping for http in mod_proxy
On 2/13/08 12:27 PM, Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote: This does not help with race conditions on HTTP keepalive connections. Nevertheless active healthchecking could be useful. But on a busy site I guess a real request will notice before the healthcheck that one backend is down or the frequence of health checks needs to be insane. On a busy site you want to know if a server is down before you send a few thousand requests to it and want to know that it's up as soon as it's available so you can send a few thousand requests to it. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: ping for http in mod_proxy
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 13. Februar 2008 18:52 An: dev@httpd.apache.org Betreff: Re: ping for http in mod_proxy On Feb 13, 2008, at 12:27 PM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Akins, Brian Gesendet: Mittwoch, 13. Februar 2008 18:23 An: dev@httpd.apache.org Betreff: Re: ping for http in mod_proxy On 2/13/08 11:07 AM, Jim Jagielski [EMAIL PROTECTED] wrote: I've started looking at adding ping support for mod_proxy_http to complement whats in mod_proxy_ajp... The idea is to send a simple OPTIONS * to the backend and hope for a reply. Would it be more useful to have active healthchecking to backend servers? This does not help with race conditions on HTTP keepalive connections. We will never be able to completely avoid race conditions... whether keepalives are in place or not. But at least the one that comes from the keepalive timer expiring on the backend at the same time I sent the request to it. If the backend answered to OPTIONS * on a keepalive connection it is reasonable to assume that the keepalive timeout will not expire until the real request hit the backend. Regarding other races I agree, but I think the above one is the one that is hit most frequently. Regards Rüdiger
Re: ping for http in mod_proxy
On Feb 13, 2008, at 12:41 PM, Plüm, Rüdiger, VF-Group wrote: Agreed, but I doubt that it is possible with a reasonable amout of health check frequency to find out before the first real request falls through, provided that your health checks are designed to only fail if the backend is down. If your health checks are smarter and notice that the backend will fail soon (e.g. because it reached 98% or 99% percent of its capacity) then this is a different story and can be very useful. Regarding the reactivation of a failed backend I fully agree: Active health checks would be an asset here instead of just retrying failed backends periodically with real requests. Ideally, it would be nice if we had better insight on the actual health of the backends than a simple do they respond to OPTIONS * and how long does it take, but that's pretty much all we can do unless go full-on multicasting of info ala mod_backhand... At least the balancer is setup to allow for load balancing based on that, if the submodule/provider actually existed :)
Re: ping for http in mod_proxy
On Feb 13, 2008, at 12:23 PM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 13. Februar 2008 17:07 An: dev@httpd.apache.org Betreff: ping for http in mod_proxy I've started looking at adding ping support for mod_proxy_http to complement whats in mod_proxy_ajp... The idea is to send a simple OPTIONS * to the backend and hope for a reply. The rub is that I've been working on 2 separate implementations: one talks direct to the socket and the other basically tries to do what ap_proxy_http_request() and ap_proxy_http_process_response() does, as far as using brigades, etc... The former is much further along, btw. We cannot use the socket approach since we need to be able to handle SSL backend connections and this requires the brigades - filters approach. The initial approach was to not honor SSL connections and just ignore that... The idea that we really want a fast and dirty Are you there flag, so to avoid as much overhead as possible...
Re: mod_proxy timeouts in the 2.0
Ack, I'm so sorry for not including the attachment. Further
complicating the issue, for some reason, emails from this
list are getting eaten or delayed by my company's server and
so I didn't even see the responses to my original mail until
now, a week later. :(
(I've always felt that email clients should scan any outgoing
emails that contain the word 'attached' yet don't actually
have an attachment and pester the user with a popup saying
Hey idiot, did you mean to attach something to this email?)
Yes, this patch is purely for 2.0.63; I have not had a chance
to try mod_proxy's new timeout features in the 2.2 line yet,
let alone determine how to apply my fix to it if needed. I
did look over the new code and it's changed quite a bit.
I did though receive one direct response to my email for someone
else who's has a similar concern for the 2.0 line and so I'm
correctly attaching and sending this patch now and hope that
some others find it useful.
Ron
On Wed, 2008-02-06 at 10:34 -0500, Jim Jagielski wrote:
On Feb 5, 2008, at 2:52 PM, Ronald Park wrote:
Attached is my patch to 2.0.63 to the proxy_http.c file in
modules/proxy.
I didn't see any attached patch... :/
In any case, the normal process is patch applied to
trunk with then backport proposals to 2.2 and 2.0. A feature
added to 2.0.x, without it being in 2.2 and trunk is likely
not gonna happen.
--- modules/proxy/proxy_http.c.orig 2007-09-04 15:33:45.0 -0400
+++ modules/proxy/proxy_http.c 2008-02-04 14:57:21.0 -0500
@@ -379,6 +379,36 @@
proxy: HTTP: pre_connection setup failed (%d),
rc);
return rc;
+} else {
+// that pre_connection code sets the socket timeout as
+// the value of Timeout which is the timeout of the
+// original request; by the time that is hit, our client
+// has already been given a timeout
+//
+// instead, we'll look to see if an env var, proxy-timeout,
+// has been set: if so, we use it; otherwise, we use
+// the setting for ProxyTimeout (if set); (otherwise, we
+// will stick with the value of Timeout.)
+const char* tbl_timeout;
+apr_interval_time_t timeout = (conf-timeout_set) ?
+ conf-timeout : 0;
+
+tbl_timeout = apr_table_get(r-subprocess_env, proxy-timeout);
+if (tbl_timeout == NULL) {
+tbl_timeout = apr_table_get(r-notes, proxy-timeout);
+}
+if (tbl_timeout != NULL) {
+int int_timeout = atoi(tbl_timeout);
+if (int_timeout 0) {
+ timeout = apr_time_from_sec(int_timeout);
+}
+}
+if (timeout 0) {
+apr_socket_timeout_set(p_conn-sock, timeout);
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
+ proxy: setting request timeout (%d), timeout);
+}
+
}
}
return OK;
Re: ping for http in mod_proxy
On Feb 13, 2008, at 12:59 PM, Plüm, Rüdiger, VF-Group wrote: We will never be able to completely avoid race conditions... whether keepalives are in place or not. But at least the one that comes from the keepalive timer expiring on the backend at the same time I sent the request to it. If the backend answered to OPTIONS * on a keepalive connection it is reasonable to assume that the keepalive timeout will not expire until the real request hit the backend. Regarding other races I agree, but I think the above one is the one that is hit most frequently. Ahh... but that goes back to one of my original questions: do we honor force-proxy-request-1.0 and/or proxy-nokeepalive for example or not... I can see reasons for both :) And again, we're basically doubling traffic and adding overheard (more overhead than AJP's cping/cpong) at which point I go back into wondering whether this sort of implementation makes sense at all...
Re: DisableReuse for mod_proxy
On Wed, 13 Feb 2008 13:18:04 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: I consider it a Good Sign when the comments are mostly about the docs and how to better wordsmith them :) :-) Not quite sure what problem you're solving, but I accept you have a reason. But putting the docs first in your post means they catch the eye. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: ping for http in mod_proxy
On Wed, Feb 13, 2008 at 12:22:43PM -0500, Akins, Brian wrote: Would it be more useful to have active healthchecking to backend servers? Ie, periodically hit a url on each origin and mark them up/down based on response. Only send traffic to up servers. I think mod_backhand does something similar but much more complex (?). Yes. Being able to check a URL seems more useful than plain ping. Even more useful would be recording the time a backend takes to answer a request and using that to distribute requests. vh Mads Toftum -- http://soulfood.dk
Re: DisableReuse for mod_proxy
On Feb 13, 2008, at 1:22 PM, Nick Kew wrote: On Wed, 13 Feb 2008 13:18:04 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: I consider it a Good Sign when the comments are mostly about the docs and how to better wordsmith them :) :-) Not quite sure what problem you're solving, but I accept you have a reason. But putting the docs first in your post means they catch the eye. It's in whatever order svn diff creates 'em ;)
Re: DisableReuse for mod_proxy
On Feb 13, 2008, at 1:13 PM, Nick Kew wrote: On Wed, 13 Feb 2008 10:27:26 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: +This helps in various situations where a firewall between Apache and +the backend server (irregardless of protocol) tends to silently irregardless??? Regardless? +drop connections. To prevent mod_proxy from reusing the backend the split infinitive grates a bit, too. tends to drop connections silently would fix that grammatically. But perhaps just drop the tends to, and substitute something like may. I consider it a Good Sign when the comments are mostly about the docs and how to better wordsmith them :)
Re: DisableReuse for mod_proxy
On Wed, 13 Feb 2008 10:27:26 -0500 Jim Jagielski [EMAIL PROTECTED] wrote: +This helps in various situations where a firewall between Apache and +the backend server (irregardless of protocol) tends to silently irregardless??? Regardless? +drop connections. To prevent mod_proxy from reusing the backend the split infinitive grates a bit, too. tends to drop connections silently would fix that grammatically. But perhaps just drop the tends to, and substitute something like may. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: ping for http in mod_proxy
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 13. Februar 2008 19:00 An: dev@httpd.apache.org Betreff: Re: ping for http in mod_proxy On Feb 13, 2008, at 12:41 PM, Plüm, Rüdiger, VF-Group wrote: Agreed, but I doubt that it is possible with a reasonable amout of health check frequency to find out before the first real request falls through, provided that your health checks are designed to only fail if the backend is down. If your health checks are smarter and notice that the backend will fail soon (e.g. because it reached 98% or 99% percent of its capacity) then this is a different story and can be very useful. Regarding the reactivation of a failed backend I fully agree: Active health checks would be an asset here instead of just retrying failed backends periodically with real requests. Ideally, it would be nice if we had better insight on the actual health of the backends than a simple do they respond to OPTIONS * and how long does it take, but that's pretty much all we can do unless go full-on multicasting of info ala mod_backhand... At least the balancer is setup to allow for load balancing based on that, if the submodule/provider actually existed :) Right. Furthermore I guess we could create a generic module that needs a URL configured for a HEAD request that only replies 200 if the backend can still handle more requests. If it does not respond or with a different code this backend would be dead. I guess this module needs to fork a separate process / thread to do this checking periodically and modify the worker status accordingly. So much interesting work and so few time :-(. Regards Rüdiger
Re: ping for http in mod_proxy
-Ursprüngliche Nachricht- Von: Jim Jagielski [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 13. Februar 2008 18:55 An: dev@httpd.apache.org Betreff: Re: ping for http in mod_proxy On Feb 13, 2008, at 12:23 PM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 13. Februar 2008 17:07 An: dev@httpd.apache.org Betreff: ping for http in mod_proxy I've started looking at adding ping support for mod_proxy_http to complement whats in mod_proxy_ajp... The idea is to send a simple OPTIONS * to the backend and hope for a reply. The rub is that I've been working on 2 separate implementations: one talks direct to the socket and the other basically tries to do what ap_proxy_http_request() and ap_proxy_http_process_response() does, as far as using brigades, etc... The former is much further along, btw. We cannot use the socket approach since we need to be able to handle SSL backend connections and this requires the brigades - filters approach. The initial approach was to not honor SSL connections and just ignore that... The idea that we really want a fast and dirty Are you there flag, so to avoid as much overhead as possible... Sorry for my I-want-it-all-at-once approach :-). But this leaves the problems (most notably PR 37770) open for SSL backend connection (which would be a pity). So IMHO the socket approach would be only a first step. Regards Rüdiger
Re: ping for http in mod_proxy
On Feb 13, 2008, at 1:04 PM, Plüm, Rüdiger, VF-Group wrote: Sorry for my I-want-it-all-at-once approach :-). But this leaves the problems (most notably PR 37770) open for SSL backend connection (which would be a pity). So IMHO the socket approach would be only a first step. No, I want it all too... The problem is that you then start going beyond a simply yes/no implementation to something more robust and information-filled, but also with more overhead...
Re: ping for http in mod_proxy
On Feb 13, 2008, at 1:49 PM, Mads Toftum wrote: On Wed, Feb 13, 2008 at 12:22:43PM -0500, Akins, Brian wrote: Would it be more useful to have active healthchecking to backend servers? Ie, periodically hit a url on each origin and mark them up/down based on response. Only send traffic to up servers. I think mod_backhand does something similar but much more complex (?). Yes. Being able to check a URL seems more useful than plain ping. Even more useful would be recording the time a backend takes to answer a request and using that to distribute requests. The latter is relatively easy to do with the current impl... Maybe I'll drop the ping idea and work on this ;)
Re: ping for http in mod_proxy
Jim Jagielski wrote: Ideally, it would be nice if we had better insight on the actual health of the backends than a simple do they respond to OPTIONS * and how long does it take, but that's pretty much all we can do unless go full-on multicasting of info ala mod_backhand... At least the balancer is setup to allow for load balancing based on that, if the submodule/provider actually existed :) Is there anything stopping us going the multicasting route, say by adding a hook or hooks of some kind to proxy that keeps track of known server states? A dedicated module could then have it's job as handling the multicasting and letting the rest of the server know if a server is on or off the air, in realtime. The proxy can then just say which of these servers should I connect to?, and the hook will return the suggested ones in the given order. As a dedicated module, people who don't need it can turn it off or not build it. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
