On Aug 23, 2007, at 1:55 AM, [EMAIL PROTECTED] wrote:
ap_available_mutexes_string and ap_add_available_mutexes_string
cannot be data symbols when mod_ssl is built as a loadable module;
using an external string constant in a loadable module is not
portable.
Wow... that's v. interesting...
Jim Jagielski wrote:
>
> On Aug 23, 2007, at 1:55 AM, [EMAIL PROTECTED] wrote:
>
>> ap_available_mutexes_string and ap_add_available_mutexes_string
>> cannot be data symbols when mod_ssl is built as a loadable module;
>> using an external string constant in a loadable module is not portable.
>
>
Sorry for the delay, but we are still held up with the APR
release and some piped logging regressions... Hopefully
once APR is released, it will be stable enough to allow
us to do some quicker turn-arounds for T&Rs...
Hello,
I have made a tiny patch for Apache 2.2 mod_proxy. It consists on enabling a
new option to status parameter in ProxyPass directive.
My idea is that I don't want to disable a destination server whenever a
single failure occur though it could be just for 1second (retry=1).
I have done this t
On 08/23/2007 02:10 AM, [EMAIL PROTECTED] wrote:
> Author: wrowe
> Date: Wed Aug 22 17:10:35 2007
> New Revision: 568779
>
> URL: http://svn.apache.org/viewvc?rev=568779&view=rev
> Log:
> main core: Emit errors during the initial apr_app_initialize()
> or apr_pool_create() (when apr-based error
On Aug 23, 2007, at 2:42 PM, Francisco Gimeno wrote:
Hello,
I have made a tiny patch for Apache 2.2 mod_proxy. It consists on
enabling a new option to status parameter in ProxyPass directive.
My idea is that I don't want to disable a destination server
whenever a single failure occur tho
the URL, http://issues.apache.org/bugzilla/attachment.cgi?id=20681
anyway, it's tiny:
diff -ur apache2-2.2.4.orig/modules/proxy/mod_proxy.c
apache2-2.2.4.kikov1/modules/proxy/mod_proxy.c
--- apache2-2.2.4.orig/modules/proxy/mod_proxy.c2006-11-27
16:00:56.0 +0100
+++ a
On 08/22/2007 01:28 AM, [EMAIL PROTECTED] wrote:
> Author: wrowe
> Date: Tue Aug 21 16:28:32 2007
> New Revision: 568326
>
> URL: http://svn.apache.org/viewvc?rev=568326&view=rev
> Log:
> Refactor r452431, because this should not be fatal to starting
> the server if it's horribly broken. The al
Ruediger Pluem wrote:
>
> On 08/23/2007 02:10 AM, [EMAIL PROTECTED] wrote:
>> Author: wrowe
>> Date: Wed Aug 22 17:10:35 2007
>> New Revision: 568779
>>
>> URL: http://svn.apache.org/viewvc?rev=568779&view=rev
>> Log:
>> main core: Emit errors during the initial apr_app_initialize()
>> or apr_pool
Ruediger Pluem wrote:
>
> On 08/22/2007 01:28 AM, [EMAIL PROTECTED] wrote:
>> Author: wrowe
>> Date: Tue Aug 21 16:28:32 2007
>> New Revision: 568326
>>
>> URL: http://svn.apache.org/viewvc?rev=568326&view=rev
>> Log:
>> Refactor r452431, because this should not be fatal to starting
>> the server
On 08/23/2007 09:29 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>> On 08/23/2007 02:10 AM, [EMAIL PROTECTED] wrote:
>>> Author: wrowe
>>> Date: Wed Aug 22 17:10:35 2007
>>> New Revision: 568779
>>>
>>> URL: http://svn.apache.org/viewvc?rev=568779&view=rev
>>> Log:
>>> main core: Emit
Ruediger Pluem wrote:
>
> But I admit that this is harder to audit and is more likely to change at some
> point of time to the usage of a pool.
More to the point, implementation of apr_ctime. The alternative of no error
at all or no timestamp seemed worse, to me. Maybe an XXX comment on trunk
t
On Aug 23, 2007, at 4:01 PM, Ruediger Pluem wrote:
On 08/23/2007 09:29 PM, William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
On 08/23/2007 02:10 AM, [EMAIL PROTECTED] wrote:
Author: wrowe
Date: Wed Aug 22 17:10:35 2007
New Revision: 568779
URL: http://svn.apache.org/viewvc?rev=568779&view
On 08/23/2007 09:36 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>> On 08/22/2007 01:28 AM, [EMAIL PROTECTED] wrote:
>>> Author: wrowe
>>> Date: Tue Aug 21 16:28:32 2007
>>> New Revision: 568326
>>>
>>> URL: http://svn.apache.org/viewvc?rev=568326&view=rev
>>> Log:
>>> Refactor r452431
On Aug 23, 2007, at 4:05 PM, William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
But I admit that this is harder to audit and is more likely to
change at some
point of time to the usage of a pool.
More to the point, implementation of apr_ctime. The alternative of
no error
at all or no t
On 08/23/2007 10:13 PM, Jim Jagielski wrote:
>
> On Aug 23, 2007, at 4:05 PM, William A. Rowe, Jr. wrote:
>
>> Ruediger Pluem wrote:
>>>
>>> But I admit that this is harder to audit and is more likely to change
>>> at some
>>> point of time to the usage of a pool.
>>
>> More to the point, imple
Ruediger Pluem wrote:
>
>> The original patch was dying on win32 as-a-service, because
>> apr_file_open_stdout
>> fails without a stdout handle.
>
> Ok, just for a non windows guy to understand: If httpd runs as a service we
> usually
> have no stdout handle and thus apr_file_open_stdout fails,
Ruediger Pluem wrote:
>
> On 08/23/2007 10:13 PM, Jim Jagielski wrote:
>> Yeah, the conditions and assumptions on which this
>> is based warrant some comments in the code :)
>
> +1
Ready to commit to the trunk/ flavor, once we have svn pre-commit hook
resolved. Joe is looking at this.
On 08/23/2007 10:32 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>>> As I got to thinking about this, when the situation is this fatal, why kill
>>> an otherwise perfectly healthy server? Worst case, we have some piped
>>> loggers
>>> which hang around longer than desired. It's a s
...hit trunk/ while it's still performing a redundant stat() call,
if APR_FINFO_USER/GROUP is already in the request_rec stat.valid bits?
And why wouldn't it flush out the existing stat structure for this
r->filename, instead of keeping a private copy?
Bill
* William A. Rowe, Jr. wrote:
> ...hit trunk/ while it's still performing a redundant stat() call,
> if APR_FINFO_USER/GROUP is already in the request_rec stat.valid bits?
> And why wouldn't it flush out the existing stat structure for this
> r->filename, instead of keeping a private copy?
Man, y
Hi.
This one is frustrating me to no end, and was wondering if some BSD/OSX
guru can help me out a bit.
I'm using the trunk, and trying to start apache, but I keep getting a
lock/sem problem
[Fri Aug 24 10:51:53 2007] [emerg] (28)No space left on device: Couldn't
create accept lock
this
On 24/08/07, Ian Holsman <[EMAIL PROTECTED]> wrote:
> Hi.
>
> This one is frustrating me to no end, and was wondering if some BSD/OSX
> guru can help me out a bit.
>
> I'm using the trunk, and trying to start apache, but I keep getting a
> lock/sem problem
>
> [Fri Aug 24 10:51:53 2007] [emerg] (2
Graham Dumpleton wrote:
On 24/08/07, Ian Holsman <[EMAIL PROTECTED]> wrote:
Hi.
This one is frustrating me to no end, and was wondering if some BSD/OSX
guru can help me out a bit.
I'm using the trunk, and trying to start apache, but I keep getting a
lock/sem problem
[Fri Aug 24 10:51:53 2
On 24/08/07, Ian Holsman <[EMAIL PROTECTED]> wrote:
> Graham Dumpleton wrote:
> > On 24/08/07, Ian Holsman <[EMAIL PROTECTED]> wrote:
> >
> >> Hi.
> >>
> >> This one is frustrating me to no end, and was wondering if some BSD/OSX
> >> guru can help me out a bit.
> >>
> >> I'm using the trunk, and t
[EMAIL PROTECTED] wrote:
> Author: wrowe
> Date: Thu Aug 23 17:54:15 2007
> New Revision: 569204
>
> URL: http://svn.apache.org/viewvc?rev=569204&view=rev
> Log:
> SEDFILTER has several anomolies; first, it's not SED syntax,
> but more mod-rewrite like (and using the rewrite pcre parser).
> Second
André Malo wrote:
> I'm curious what you're doing now with that information >:->
Zilch - except to suggest to move it to experimental ;-) Moved on
already, have way to many other things to really address.
Bill
On 8/23/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> I'm happy with a number of alternative names, mod_pcre_filter,
> mod_text_filter,
> mod_subst_filter, whatever, a number come to mind. The fact is, mod_sed_filter
> was nothing close to a sed implementation.
I hate "mod_rewrite_filter
Joshua Slive wrote:
> On 8/23/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
>
>> I'm happy with a number of alternative names, mod_pcre_filter,
>> mod_text_filter,
>> mod_subst_filter, whatever, a number come to mind. The fact is,
>> mod_sed_filter
>> was nothing close to a sed implementat
On Aug 23, 2007, at 7:21 PM, William A. Rowe, Jr. wrote:
Joshua Slive wrote:
On 8/23/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
I'm happy with a number of alternative names, mod_pcre_filter,
mod_text_filter,
mod_subst_filter, whatever, a number come to mind. The fact is,
mod_sed_fi
Roy T. Fielding wrote:
> On Aug 23, 2007, at 7:21 PM, William A. Rowe, Jr. wrote:
>> Joshua Slive wrote:
>>> On 8/23/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
>>>
I'm happy with a number of alternative names, mod_pcre_filter,
mod_text_filter,
mod_subst_filter, whatever, a n
31 matches
Mail list logo
