Re: svn commit: r682369 - /httpd/httpd/trunk/modules/proxy/proxy_util.c
William A. Rowe, Jr. wrote: Mladen Turk wrote: If the under the hood apr_reslist behavior is of such concern we can create apr_reslist_create_ex with some param that will allow to specify the pool cleanup ordering keeping everyone happy concerning backporting and still allowing all the goodies. In APR version 1.4.0 of course. That could be a nice combination. Sure. Seems we cannot backport even the existing change to 1.3.x since it can cause user code to break in some cases, like shown in this example. For 1.3.x, Bojan can register the pre_cleanup for apr_dbd after creating the reslist, so actually mimicking the trunk behavior, but thats for APR list discussion. Regards -- ^(TM)
Re: svn commit: r682369 - /httpd/httpd/trunk/modules/proxy/proxy_util.c
Mladen Turk wrote: If the under the hood apr_reslist behavior is of such concern we can create apr_reslist_create_ex with some param that will allow to specify the pool cleanup ordering keeping everyone happy concerning backporting and still allowing all the goodies. In APR version 1.4.0 of course. That could be a nice combination.
Re: svn commit: r682369 - /httpd/httpd/trunk/modules/proxy/proxy_util.c
Jim Jagielski wrote:
On Aug 4, 2008, at 9:54 AM, Ruediger Pluem wrote:
On 08/04/2008 03:50 PM, Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
--- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/trunk/modules/proxy/proxy_util.c Mon Aug 4 05:53:50
2008
@@ -1380,7 +1380,6 @@
proxy_worker *worker = (proxy_worker *)theworker;
if (worker->cp->res) {
worker->cp->pool = NULL;
-apr_reslist_destroy(worker->cp->res);
}
return APR_SUCCESS;
}
Well, you've beat me :)
The complete conn_pool_cleanup function can be omitted, and
there is no need for checking if (conn->worker->cp->pool)
in the connection_destructor.
Might be. At the current state it makes it possible to keep
trunk and 2.2.x very similar until all in apr land is sorted
out. We can cleanup the remaining parts then.
+1. Let's wait until APR gets sorted out before we start
mucking around with "fixing" 2.2 and trunk to handle an
in-flux APR
If the under the hood apr_reslist behavior is of such
concern we can create apr_reslist_create_ex with some
param that will allow to specify the pool cleanup ordering
keeping everyone happy concerning backporting and still
allowing all the goodies.
Regards
--
^(TM)
Re: svn commit: r682369 - /httpd/httpd/trunk/modules/proxy/proxy_util.c
Ruediger Pluem wrote:
On 08/04/2008 03:50 PM, Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
--- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/trunk/modules/proxy/proxy_util.c Mon Aug 4 05:53:50
2008
@@ -1380,7 +1380,6 @@
proxy_worker *worker = (proxy_worker *)theworker;
if (worker->cp->res) {
worker->cp->pool = NULL;
-apr_reslist_destroy(worker->cp->res);
}
return APR_SUCCESS;
}
Well, you've beat me :)
The complete conn_pool_cleanup function can be omitted, and
there is no need for checking if (conn->worker->cp->pool)
in the connection_destructor.
Might be. At the current state it makes it possible to keep
trunk and 2.2.x very similar until all in apr land is sorted
out. We can cleanup the remaining parts then.
Well I was hopping to add an extra apr_reslist_maintain function
that would allow to close the expired resources out of the
require/release bounds. Right now in proxy the connection will
be release only if the particular mpm child process gets
request for a particular worker. It can take minutes or hours
on slow hit ratio for that to happen. So the ttl is more a 'guess'
rather then a firm fact.
Regards
--
^(TM)
Re: svn commit: r682369 - /httpd/httpd/trunk/modules/proxy/proxy_util.c
On Aug 4, 2008, at 9:54 AM, Ruediger Pluem wrote:
On 08/04/2008 03:50 PM, Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
--- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/trunk/modules/proxy/proxy_util.c Mon Aug 4
05:53:50 2008
@@ -1380,7 +1380,6 @@
proxy_worker *worker = (proxy_worker *)theworker;
if (worker->cp->res) {
worker->cp->pool = NULL;
-apr_reslist_destroy(worker->cp->res);
}
return APR_SUCCESS;
}
Well, you've beat me :)
The complete conn_pool_cleanup function can be omitted, and
there is no need for checking if (conn->worker->cp->pool)
in the connection_destructor.
Might be. At the current state it makes it possible to keep
trunk and 2.2.x very similar until all in apr land is sorted
out. We can cleanup the remaining parts then.
+1. Let's wait until APR gets sorted out before we start
mucking around with "fixing" 2.2 and trunk to handle an
in-flux APR
Re: svn commit: r682369 - /httpd/httpd/trunk/modules/proxy/proxy_util.c
On 08/04/2008 03:50 PM, Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
--- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/trunk/modules/proxy/proxy_util.c Mon Aug 4 05:53:50 2008
@@ -1380,7 +1380,6 @@
proxy_worker *worker = (proxy_worker *)theworker;
if (worker->cp->res) {
worker->cp->pool = NULL;
-apr_reslist_destroy(worker->cp->res);
}
return APR_SUCCESS;
}
Well, you've beat me :)
The complete conn_pool_cleanup function can be omitted, and
there is no need for checking if (conn->worker->cp->pool)
in the connection_destructor.
Might be. At the current state it makes it possible to keep
trunk and 2.2.x very similar until all in apr land is sorted
out. We can cleanup the remaining parts then.
Regards
Rüdiger
Re: svn commit: r682369 - /httpd/httpd/trunk/modules/proxy/proxy_util.c
[EMAIL PROTECTED] wrote:
--- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/trunk/modules/proxy/proxy_util.c Mon Aug 4 05:53:50 2008
@@ -1380,7 +1380,6 @@
proxy_worker *worker = (proxy_worker *)theworker;
if (worker->cp->res) {
worker->cp->pool = NULL;
-apr_reslist_destroy(worker->cp->res);
}
return APR_SUCCESS;
}
Well, you've beat me :)
The complete conn_pool_cleanup function can be omitted, and
there is no need for checking if (conn->worker->cp->pool)
in the connection_destructor.
Regards
--
^(TM)
