Philip M. Gollucci wrote:
Hi all, so it seems I dropped the ball on the releases. I'm about to
get back into it.
Does anyone know of any issues that are still oustanding from
mod_perl-2.0.3-RC1
Apache-Test 1.29-RC1
libapreq2 2.09-RC1
before I roll -RC2s. I'm pretty sure Apache-Test
Joe Orton wrote:
The existing 2.x store_body interface passed a brigade to the storage
provider's store_body() callback. It is impossible for the provider to
store all of such a brigade without consuming an arbitrary amount of
RAM, since the brigade may contain morphing buckets (a CGI/PIPE
On Oct 30, 2006, at 12:45 PM, Nick Kew wrote:
On Mon, 30 Oct 2006 11:36:43 -0700
Justin Erenkrantz [EMAIL PROTECTED] wrote:
3) change the interface: deal with the buckets entirely in
mod_cache and just pass (char *,size_t) pairs to store_body
#3 gets my vote. I hate bucket brigades anyway.
On Tue, October 31, 2006 10:16 am, Issac Goldstand wrote:
How about implementing the providers as a filter (same API as normal
output filters, but separate chain just for mod_cache)? The final
filter in the chain destroys the buckets and the first can do any
special handling for special
On Mon, October 30, 2006 8:23 pm, Joe Orton wrote:
2) keep the interface as-is, but read buckets in mod_cache and partition
the brigade manually; only pass a small brigade with known-length
buckets to the provider. (so no morphing and no arbitrary memory
consumption)
Thinking this through
Joe Orton wrote:
I keep seeing people talk about the mod_cache interface as an
externally-visible API for which we must maintain API/ABI compatibility.
But mod_cache.h is not installed, so this API is not actually exposed
externally, and never has been.
Uhm - it's our front for an
On Tue, 31 Oct 2006 00:43:12 -0800
Roy T. Fielding [EMAIL PROTECTED] wrote:
(dammit, I wasn't going to post again in this discussion,
for the forseeable, but this wants an answer)
If you are going to -1 something, you need to have a technical reason
for it IN THE MESSAGE. You can't assume
On Tue, October 31, 2006 11:59 am, Nick Kew wrote:
It was not intended as any such thing. Just a comment noting
that we have an extremely simple case in which this caching
strategy will degrade system performance not just a little,
but by a whole order of magnitude. The lusers will love it.
On Mon, Oct 30, 2006 at 10:13:09PM +0100, Ruediger Pluem wrote:
2) keep the interface as-is, but read buckets in mod_cache and partition
the brigade manually; only pass a small brigade with known-length
buckets to the provider. (so no morphing and no arbitrary memory
consumption)
As far
On Oct 31, 2006, at 1:59 AM, Nick Kew wrote:
It was not intended as any such thing. Just a comment noting
that we have an extremely simple case in which this caching
strategy will degrade system performance not just a little,
but by a whole order of magnitude. The lusers will love it.
Okay,
-Ursprüngliche Nachricht-
Von: Joe Orton
Gesendet: Dienstag, 31. Oktober 2006 11:27
An: dev@httpd.apache.org
Betreff: Re: cache: the store_body interface
On Mon, Oct 30, 2006 at 10:13:09PM +0100, Ruediger Pluem wrote:
2) keep the interface as-is, but read buckets in
On Mon, Oct 30, 2006 at 02:56:24PM -0700, Justin Erenkrantz wrote:
On 10/30/06, Nick Kew [EMAIL PROTECTED] wrote:
What does that [#1] break?
Seems an easy/low-level solution. Does the provider return a
status value to say I have/haven't passed this stuff down the
chain? It has the feel of
On Tue, October 31, 2006 12:59 pm, Joe Orton wrote:
I very much sympathise with this argument. But it does mean that the
storage provider cannot break any of the assumptions mentioned in the
other thread: it enforces the synchronous store-to-disk and
write-to-client model.
I think it's a
On Tue, Oct 31, 2006 at 01:49:10PM +0200, Graham Leggett wrote:
On Tue, October 31, 2006 12:59 pm, Joe Orton wrote:
I very much sympathise with this argument. But it does mean that the
storage provider cannot break any of the assumptions mentioned in the
other thread: it enforces the
On Tue, October 31, 2006 12:43 pm, Roy T. Fielding wrote:
You say that the strategy will degrade performance, but you
don't indicate why. If there is some great performance penalty
caused by changing the interface to send_body, I'd like to know
what it is.
Changing the interface to a pure
On Tue, October 31, 2006 2:02 pm, Joe Orton wrote:
Being able to determine writability from the output filter chain means
redesigning the output filtering interface, there is nothing simple
about it at all.
This seems to me an exaggeration - pulling apart ap_core_output_filter(),
all it would
On Tue, Oct 31, 2006 at 02:11:47PM +0200, Graham Leggett wrote:
On Tue, October 31, 2006 2:02 pm, Joe Orton wrote:
Being able to determine writability from the output filter chain means
redesigning the output filtering interface, there is nothing simple
about it at all.
This seems to
On Tue, Oct 31, 2006 at 10:59:49AM +, Joe Orton wrote:
On Mon, Oct 30, 2006 at 02:56:24PM -0700, Justin Erenkrantz wrote:
On 10/30/06, Nick Kew [EMAIL PROTECTED] wrote:
What does that [#1] break?
Seems an easy/low-level solution. Does the provider return a
status value to say I
Graham Dumpleton wrote:
In mod_python, the session ID consists of 32 characters coming from the ranges
0-9 and a-f. At the moment the code will if it detects invalid characters in
the SID or it is the wrong size, raise a HTTP_INTERNAL_SERVER_ERROR exception.
if self._sid:
#
-Ursprüngliche Nachricht-
Von: Joe Orton
Gesendet: Dienstag, 31. Oktober 2006 13:52
An: dev@httpd.apache.org
Betreff: Re: cache: the store_body interface
On Tue, Oct 31, 2006 at 10:59:49AM +, Joe Orton wrote:
On Mon, Oct 30, 2006 at 02:56:24PM -0700, Justin Erenkrantz
On Tue, October 31, 2006 3:29 pm, Plüm, Rüdiger, VF EITO wrote:
I meant to also mention (sorry for all the mail): it prevents
mod_mem_cache's fd caching trick too, which relies on being
passed FILE
buckets.
That seems to be an important point to me. Although I never used
the fd caching of
On Mon, 30 Oct 2006, Ruediger Pluem wrote:
BTW: Does anybody know if MMAP for writing files is possible / makes sense /
improves performance?
It reduces some data-copying, so it's a tad cheaper to mmap. But, on
Linux you can't do sendfile from a file that's being written to with
mmap, and
On Tue, October 31, 2006 2:31 pm, Joe Orton wrote:
To determine writability of the output filter chain is not as simple as
exposing writability of the socket. An output filter may block on
writes because it is blocked on a read from the (writable) socket, this
happens with SSL for example.
Jim Jagielski wrote:
Sounds good.
On a related note, our practice with mod_jk is to route only *.jsp,
/servlet/*, and a few other URL patterns to Tomcat and let Apache
handle
everything else. We also want to support load balancing with sticky
sessions, of course.
That combination is pretty
In reference to some mod_cache discussions:
It seems, that after some testing, that in 2.2.3, the core output filters will
block when given file buckets, therefore, stalling the entire brigade (ie,
slowing reads from proxy, cgi, etc.). This was a somewhat artificial test I
did, but can
On 10/31/06, Plüm, Rüdiger, VF EITO [EMAIL PROTECTED] wrote:
That seems to be an important point to me. Although I never used
the fd caching of mod_mem_cache this would mean we actually would
have to dump this feature. This looks bad to me. Isn't this a showstopper
for implementing #3 as new
On 10/31/06, Graham Leggett [EMAIL PROTECTED] wrote:
On Tue, October 31, 2006 2:31 pm, Joe Orton wrote:
To determine writability of the output filter chain is not as simple as
exposing writability of the socket. An output filter may block on
writes because it is blocked on a read from the
On Tue, October 31, 2006 5:36 pm, Brian Akins wrote:
Actually got of my rear and looked at it myself :) From the looks of it,
core_output_filter in 2.2.3 does not have any special handling of file
buckets
and is in many ways different from trunk. FWIW.
Apparently the non blocking changes
Sounds good.
On a related note, our practice with mod_jk is to route only *.jsp,
/servlet/*, and a few other URL patterns to Tomcat and let Apache
handle
everything else. We also want to support load balancing with sticky
sessions, of course.
That combination is pretty easy and
Von:
Justin Erenkrantz
Gesendet: Dienstag, 31. Oktober 2006 16:15
An: dev@httpd.apache.org
Betreff: Re: cache: the store_body interface
On 10/31/06, Plüm, Rüdiger, VF EITO
[EMAIL PROTECTED] wrote:
That seems to be an important point to me. Although I never used
the fd caching
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Gesendet: Dienstag, 31. Oktober 2006 15:18
An: dev@httpd.apache.org
Betreff: Re: [Fwd: Re: Apache 2.2.3 mod_proxy issue]
How about
RewriteEngine On
RewriteRule ^(.*\.jsp|/servlet/.*)$ balancer://mycluster$1 [P]
Proxy
On 10/31/06, Graham Leggett [EMAIL PROTECTED] wrote:
Hypothetically, if somebody else cared to redesign the output filters just
for the cache, and some effort was spent by that somebody else to make
sure any disruptive changes were either minimised or prevented where
possible, would development
On Tue, October 31, 2006 6:00 pm, Justin Erenkrantz wrote:
Any redesign should be discussed on-list first and let us come to a
consensus here around any new design first - so as not to waste effort
later on if the design isn't acceptable. -- justin
Right now I'd like to investigate some
On Tue, Oct 31, 2006 at 03:17:18PM +0200, Graham Leggett wrote:
On Tue, October 31, 2006 2:31 pm, Joe Orton wrote:
To determine writability of the output filter chain is not as simple as
exposing writability of the socket. An output filter may block on
writes because it is blocked on a
Brian Akins wrote:
This was a
somewhat artificial test I did, but can someone confirm if something
changed in trunk that allows file buckets to be handled differently...
Actually got of my rear and looked at it myself :) From the looks of it,
core_output_filter in 2.2.3 does not have any
On Tue, October 31, 2006 5:16 pm, Justin Erenkrantz wrote:
I'm with Joe on this: I don't care to redesign our output filters just
for the cache. It would mean breaking all of our other filter
implementations and I don't see the benefit. -- justin
Hypothetically, if somebody else cared to
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Gesendet: Dienstag, 31. Oktober 2006 17:05
An: dev@httpd.apache.org
Betreff: Re: AW: [Fwd: Re: Apache 2.2.3 mod_proxy issue]
I am a regexp fan and have mod_rewrite loaded in any of our
servers =
anyway
for some standard
I am a regexp fan and have mod_rewrite loaded in any of our servers =
anyway
for some standard tasks, so this actually does not bother me :-).
My concern is that the proxy-selection and operation should be
fast, as fast a possible, and mod_rewrite simply isn't the fastest
puppy in the world.
On 10/31/06, Graham Leggett [EMAIL PROTECTED] wrote:
On Tue, October 31, 2006 1:25 am, Eric Covener wrote:
Looks like the openldap 2.4 series (alpha) can support this by
requesting a new openssl CTX
(ldap_set_option(...,APR_LDAP_OPT_X_TLS_NEWCTX,...) but I had to
explicitly call openssl's
Justin Erenkrantz wrote:
On 10/31/06, Graham Leggett [EMAIL PROTECTED] wrote:
Hypothetically, if somebody else cared to redesign the output filters
just
for the cache, and some effort was spent by that somebody else to make
sure any disruptive changes were either minimised or prevented where
Justin Erenkrantz wrote:
On 10/31/06, Plüm, Rüdiger, VF EITO [EMAIL PROTECTED] wrote:
That seems to be an important point to me. Although I never used
the fd caching of mod_mem_cache this would mean we actually would
have to dump this feature. This looks bad to me. Isn't this a showstopper
for
Plüm wrote:
That seems to be an important point to me. Although I never used
the fd caching of mod_mem_cache this would mean we actually would
have to dump this feature. This looks bad to me. Isn't this
a showstopper
for implementing #3 as new interface?
Honestly,
ssl_expr.h:
typedef struct {
ssl_expr_node_op node_op;
void *node_arg1;
void *node_arg2;
apr_pool_t *p;
} ssl_expr_node;
typedef ssl_expr_node ssl_expr;
The pool in ssl_expr_node doesn't seem to be used? Either when the
struct is created(ssl_expr.c):
ssl_expr
Ruediger Pluem wrote:
Maybe I am just missing the important point, but I think total
req-per-sec and round trip time are coupled to some limit.
They are coupled, of course. The question is whether the additional
overhead of a full regex is noticable for a dynamic request,
and the answer is
On 10/31/2006 08:59 PM, Jim Jagielski wrote:
Ruediger Pluem wrote:
Maybe I am just missing the important point, but I think total
req-per-sec and round trip time are coupled to some limit.
They are coupled, of course. The question is whether the additional
overhead of a full regex is
On Tue, October 31, 2006 7:40 pm, Justin Erenkrantz wrote:
And the non-blocking changes in the core output filter, AFAIK, are
still busted. We need to either complete those changes or revert
them. -- justin
I'm all for giving a serious try at fixing them. Are there any details of
what's
46 matches
Mail list logo
