[STATUS] (httpd-2.1) Wed Mar 15 23:51:19 2006

2006-03-15 Thread Rodent of Unusual Size
APACHE 2.3 STATUS: -*-text-*- Last modified at [$Date: 2006-02-02 16:28:52 -0500 (Thu, 02 Feb 2006) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS Documentation status is maintained se

[STATUS] (httpd-2.0) Wed Mar 15 23:50:08 2006

2006-03-15 Thread Rodent of Unusual Size
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2006-03-10 04:02:48 -0500 (Fri, 10 Mar 2006) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is main

engine(3) support for flood

2006-03-15 Thread Yusuf Goolamabbas
I have tried to create a patch to provide engine(3) support to Flood. Currently the patch hardcodes the engine to "pkcs11" which is the engine available in the Sun Niagara. The patch also assumes that the following line is added to config.h #define HAVE_OPENSSL_ENGINE_H 1 since the code is #ifdef

Re: caching limit files in mod_file_cache?

2006-03-15 Thread Xuekun Hu
> gives you first 10 lines of backtrace for each thread. Find which one > got kill()'ed. then: > > (gdb) thread > (gdb) bt > > Thanks for telling me how to find which thread is killed. #0 0x002a9664e6f9 in kill () from /lib64/tls/libc.so.6 #1 #2 0x00768a98 in ?? () #3 0x000

Re: pool use/mutex initialization in util_ldap not thread safe?

2006-03-15 Thread Jeff Trawick
On 3/15/06, Brad Nicholes <[EMAIL PROTECTED]> wrote: > I think you are right. I am going to take a closer look at that code > and see about fixing both the mutex problem and the use of the config > pool. This could actually explain some funny things that I have been > seeing on the NetWare build

Re: pool use/mutex initialization in util_ldap not thread safe?

2006-03-15 Thread Brad Nicholes
>>> On 3/15/2006 at 2:34 pm, in message <[EMAIL PROTECTED]>, "Jeff Trawick" <[EMAIL PROTECTED]> wrote: > Plz forgive any misunderstanding, as well as my use of 2.0 function > names ;) Also, for being slow at learning what ldap stands for. I > know this code has been hashed over many many times ov

pool use/mutex initialization in util_ldap not thread safe?

2006-03-15 Thread Jeff Trawick
Plz forgive any misunderstanding, as well as my use of 2.0 function names ;) Also, for being slow at learning what ldap stands for. I know this code has been hashed over many many times over the last few years. util_ldap_create_config() creates the per-server config for util_ldap. That saves a

Re: caching limit files in mod_file_cache?

2006-03-15 Thread Brian Akins
Xuekun Hu wrote: (gdb) bt full see which thread actually killed it: (gdb) thread apply all bt 10 gives you first 10 lines of backtrace for each thread. Find which one got kill()'ed. then: (gdb) thread (gdb) bt -- Brian Akins Lead Systems Engineer CNN Internet Technologies

Re: caching limit files in mod_file_cache?

2006-03-15 Thread Xuekun Hu
Updates. Sometimes thread segmentation fault would be happened. So I have chance to print the backtrace. (Apache2.2.0, worker mpm with thousands threads) (gdb) bt full #0 0x002a96412f1f in __read_nocancel () from /lib64/tls/libpthread.so.0 No symbol table info available. #1 0x0047c

Re: Planning to cut a 2.0.x tarball, Sunday night

2006-03-15 Thread Colm MacCarthaigh
On Wed, Mar 15, 2006 at 02:26:23AM -0600, William A. Rowe, Jr. wrote: > AFAIK - the only real showstopper against 2.0 is the next release of > APR, which I have plans to roll this week. Giving that group 3 days > to consider and vote a candidate up or down, I'm looking at rolling > the next 2.0 ca

Planning to cut a 2.0.x tarball, Sunday night

2006-03-15 Thread William A. Rowe, Jr.
AFAIK - the only real showstopper against 2.0 is the next release of APR, which I have plans to roll this week. Giving that group 3 days to consider and vote a candidate up or down, I'm looking at rolling the next 2.0 candidate late Sunday if all goes well. Bill

Re: Bug in Apache ap_internal_fast_redirect() function????

2006-03-15 Thread William A. Rowe, Jr.
André Malo wrote: * Paul Querna wrote: I agree, and believe, that this is a bug in the core, not in mod_python. I believe changing the all of they apr_table_overlay calls mentioned above to apr_table_overlap would fix the problem. Thoughts? I believe that we should just drop the fast intern