Re: [PATCH] worker.c: make pconf the parent for ptrans
On 5/12/05, Joe Schaefer [EMAIL PROTECTED] wrote: Without this patch, the new apr_pool_join stuff in apr's trunk segfaults all over the place. Why? Is worker MPM doing something wrong (creating standalone pool in that manner), or does APR need some help? Index: server/mpm/worker/worker.c apr_allocator_create(allocator); apr_allocator_max_free_set(allocator, ap_max_mem_free); -apr_pool_create_ex(ptrans, NULL, NULL, allocator); +apr_pool_create_ex(ptrans, pconf, NULL, allocator); Isn't this on the listener thread? Do we need to be mucking with the pconf pool on non-main thread? Sounds dangerous (non-thread-safe).
Re: [PATCH] mod_cache, don't always run as a quick handler.
Brian Akins wrote:
Paul Querna wrote:
CacheEnable disk /
Maybe have it as an option to CacheEnable instead?
CacheEnable disk /special_stuff normal
CacheEnable disk / quick
with quick being the default. That way, you would not have to do it
globally, but could be more specific.
Also, have the both option where it will try in quick and normal
handlers.
Attached is a patch that adds 'normal', 'both' and 'quick' to the
CacheEnable command. It looks okay locally, but I haven't done
extensive testing.
FWIW, the last night's patch went live on update.mozilla.org, and
survived the morning release of Firefox 1.0.4.
Little propaganda on 2.1...
Basic Setup is two reverse proxy + cache machines in front of a single
PHP based Application Server.
Both cache/proxies were running Worker MPM and 2.1.3+patches. Peaked at
about concurrent 3800 connections each. (only 4 gigs of ram on those
machines) Once everything was configured correctly, the machines were
not even breaking a sweat. Previously they were using several Squids,
but the features in 2.1 are very compelling for their uses...
-Paul
Index: modules/cache/cache_util.c
===
--- modules/cache/cache_util.c (revision 169788)
+++ modules/cache/cache_util.c (working copy)
@@ -27,7 +27,8 @@
CACHE_DECLARE(cache_provider_list *)ap_cache_get_providers(request_rec *r,
cache_server_conf *conf,
- const char *url)
+ const char *url,
+ int htype)
{
cache_provider_list *providers = NULL;
int i;
@@ -40,7 +41,9 @@
for (i = 0; i conf-cacheenable-nelts; i++) {
struct cache_enable *ent =
(struct cache_enable *)conf-cacheenable-elts;
-if ((ent[i].url) !strncasecmp(url, ent[i].url, ent[i].urllen)) {
+if ((ent[i].url) !strncasecmp(url, ent[i].url, ent[i].urllen)
+(CACHE_HANDLER_BOTH == ent[i].handler_type ||
+ htype == ent[i].handler_type)) {
/* Fetch from global config and add to the list. */
cache_provider *provider;
provider = ap_lookup_provider(CACHE_PROVIDER_GROUP, ent[i].type,
Index: modules/cache/mod_cache.c
===
--- modules/cache/mod_cache.c (revision 169788)
+++ modules/cache/mod_cache.c (working copy)
@@ -45,7 +45,7 @@
* oh well.
*/
-static int cache_url_handler(request_rec *r, int lookup)
+static int cache_url_real_handler(request_rec *r, int lookup, int htype)
{
apr_status_t rv;
const char *auth;
@@ -74,7 +74,7 @@
/*
* Which cache module (if any) should handle this request?
*/
-if (!(providers = ap_cache_get_providers(r, conf, path))) {
+if (!(providers = ap_cache_get_providers(r, conf, path, htype))) {
return DECLINED;
}
@@ -156,9 +156,12 @@
/* We are in the quick handler hook, which means that no output
* filters have been set. So lets run the insert_filter hook.
*/
-ap_run_insert_filter(r);
+if (htype == CACHE_HANDLER_QUICK) {
+ap_run_insert_filter(r);
+}
+
ap_add_output_filter_handle(cache_out_filter_handle, NULL,
-r, r-connection);
+r, r-connection);
/* kick off the filter stack */
out = apr_brigade_create(r-pool, r-connection-bucket_alloc);
@@ -174,6 +177,17 @@
return OK;
}
+static int cache_url_quick_handler(request_rec *r, int lookup)
+{
+return cache_url_real_handler(r, lookup, CACHE_HANDLER_QUICK);
+}
+
+static int cache_url_late_handler(request_rec *r)
+{
+return cache_url_real_handler(r, 0, CACHE_HANDLER_NORMAL);
+}
+
+
/*
* CACHE_OUT filter
*
@@ -872,10 +886,12 @@
static const char *add_cache_enable(cmd_parms *parms, void *dummy,
const char *type,
-const char *url)
+const char *url,
+const char *handler)
{
cache_server_conf *conf;
struct cache_enable *new;
+int htype;
if (*type == '/') {
return apr_psprintf(parms-pool,
@@ -883,6 +899,24 @@
type);
}
+if (!handler) {
+htype = CACHE_HANDLER_QUICK;
+}
+else if (!strncasecmp(handler, quick, 5)) {
+htype = CACHE_HANDLER_QUICK;
+}
+else if (!strncasecmp(handler, both, 4)) {
+htype = CACHE_HANDLER_BOTH;
+}
+else if (!strncasecmp(handler, normal, 6)) {
+htype = CACHE_HANDLER_NORMAL;
+}
+else {
+return apr_psprintf(parms-pool,
+ CacheEnable: Invalid handler type: '%s',
+ handler);
+}
+
conf =
Re: [PATCH] worker.c: make pconf the parent for ptrans
Jeff Trawick [EMAIL PROTECTED] writes: On 5/12/05, Joe Schaefer [EMAIL PROTECTED] wrote: Without this patch, the new apr_pool_join stuff in apr's trunk segfaults all over the place. Why? Is worker MPM doing something wrong (creating standalone pool in that manner), or does APR need some help? I don't know what the core problem is, but I've compiled everything with --enable-pool-debug. There are lots of places in the code where tables created with the pconf pool are overlaid with a table created with the ptrans pool. -- Joe Schaefer
Re: [PATCH] mod_cache, don't always run as a quick handler.
At 04:55 AM 5/13/2005, Paul Querna wrote: Brian Akins wrote: Paul Querna wrote: CacheEnable disk / Maybe have it as an option to CacheEnable instead? CacheEnable disk /special_stuff normal CacheEnable disk / quick Unless I totally missed the point, any mistake in either mod_cache, or the content headers is masked by CacheEnable normal. What we do to 'hack around' broken content headers will hit other proxies and cause exactly the same problems, no? What we do to 'hack around' bugs in mod_cache prevents it from behaving as a proper proxy, no? So I guess, I'm -1 on this option, seeing as the real issue was that mod_rewrite hadn't set the no-cache bits properly to prevent mod_cache from stashing away vary-by-browser content. Bill
Re: [PATCH] mod_cache, don't always run as a quick handler.
William A. Rowe, Jr. wrote: At 04:55 AM 5/13/2005, Paul Querna wrote: Brian Akins wrote: Paul Querna wrote: CacheEnable disk / Maybe have it as an option to CacheEnable instead? CacheEnable disk /special_stuff normal CacheEnable disk / quick Unless I totally missed the point, any mistake in either mod_cache, or the content headers is masked by CacheEnable normal. What we do to 'hack around' broken content headers will hit other proxies and cause exactly the same problems, no? What we do to 'hack around' bugs in mod_cache prevents it from behaving as a proper proxy, no? So I guess, I'm -1 on this option, seeing as the real issue was that mod_rewrite hadn't set the no-cache bits properly to prevent mod_cache from stashing away vary-by-browser content. Uhm, in my specific case yes, I needed it to get around not setting 'Vary: User-Agent'. This is not the only use. Please don't -1 it based on my example of how I abused it in real life. -Paul
Re: [PATCH] mod_cache, don't always run as a quick handler.
At 11:35 AM 5/13/2005, Paul Querna wrote: Uhm, in my specific case yes, I needed it to get around not setting 'Vary: User-Agent'. This is not the only use. Please don't -1 it based on my example of how I abused it in real life. Please clarify how not setting that Vary header does not produce erroneous results in other proxies? Please also clarify a specific use case which would turn my vote towards a +1 (or at least +/-0). Bill [A former Perl 'TMTOWTDI' who's becoming more of a Python believer.]
Re: [VOTE] 2.2.0 Alpha on Friday
Andr Malo wrote: I'm seeing it like this: Once forked off, 2.1.x would be *stabilizing* branch, that finally leads to a 2.2.x branch, when we feel, it's stable (svn mv 2.1.x 2.2.x?). From the 2.1.x branch we tag alpha and beta releases; from *stable* 2.2.x rc and stable release. I think that's exactly the point of the odd/even system - 2.2.0 being a GA version. I see (now :-) that we should have already branched 2.1.x the first time we released a 2.1 version. +1. Sander
Re: [VOTE] 2.2.0 Alpha on Friday
Sander Striker wrote: Andr Malo wrote: I'm seeing it like this: Once forked off, 2.1.x would be *stabilizing* branch, that finally leads to a 2.2.x branch, when we feel, it's stable (svn mv 2.1.x 2.2.x?). From the 2.1.x branch we tag alpha and beta releases; from *stable* 2.2.x rc and stable release. I think that's exactly the point of the odd/even system - 2.2.0 being a GA version. I see (now :-) that we should have already branched 2.1.x the first time we released a 2.1 version. +1. +1
