I've cleaned it up and bit and put the mutex where it really
belongs, making the function itself thread-safe. I also
leveraged a mutex field we hadn't used up to now, saving
any API changes...
fix_mod_proxy_thread_unsafety-2.patch
Description: Binary data
However, looking at your patch, having to lock the mutex for
ap_proxy_get_worker() looks wrong. I think it should be passed r-pool
instead of conf-pool.
I checked how ap_proxy_get_worker() is used in other places and also what
is done with the pool inside and you are right. It really shouldn't
+1.
PS: The ap_proxy_define_balancer() stuff is there for future enhancements
(creating balancers on the fly, instead of just workers).
On May 7, 2013, at 4:07 AM, Thomas Eckert thomas.r.w.eck...@gmail.com wrote:
However, looking at your patch, having to lock the mutex for
eaiser in the
future. It's really only 2 lines that have to be edited.
On Sat, May 4, 2013 at 8:20 PM, Micha Lenk mi...@lenk.info wrote:
Hi Stefan,
Am 03.05.2013 14:09, schrieb Stefan Fritsch:
On Thursday 02 May 2013, Thomas Eckert wrote:
Lately, I've been seeing httpd/mod_proxy seg faulting
On Sat, 4 May 2013, Micha Lenk wrote:
I am pretty sure that this is a thread-unsafe pool usage.
create_proxy_config() puts the global config pool into
(proxy_server_conf)-pool. It is later (during request processing)
used all over the place without further locking. This must be a sub-
On Mon, 6 May 2013, Thomas Eckert wrote:
Based on Stefan's reply I replaced mod_proxy's config pool with a sub-pool
and wrapped a mutex around the pool usage. Basic testing went well but I
have to do some more thorough parallel testing.
Nice.
One thing which had me confused was the
Hi Stefan,
Am 03.05.2013 14:09, schrieb Stefan Fritsch:
On Thursday 02 May 2013, Thomas Eckert wrote:
Lately, I've been seeing httpd/mod_proxy seg faulting in reverse
proxy setups, frequency increasing.
I am pretty sure that this is a thread-unsafe pool usage.
create_proxy_config() puts
On Thursday 02 May 2013, Thomas Eckert wrote:
Lately, I've been seeing httpd/mod_proxy seg faulting in reverse
proxy setups, frequency increasing.
I am pretty sure that this is a thread-unsafe pool usage.
create_proxy_config() puts the global config pool into
(proxy_server_conf)-pool
Lately, I've been seeing httpd/mod_proxy seg faulting in reverse proxy
setups, frequency increasing.
#0 apr_palloc (pool=0x8b52518, in_size=16) at memory/unix/apr_pools.c:684
#1 0xf756fc10 in apr_pool_cleanup_register (p=0x8b52518, data=0x8b52528,
plain_cleanup_fn=0xf756edb0 thread_cond_cleanup