Graham Leggett wrote:
> 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.
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 b
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 re
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 i
On 10/31/2006 05:56 PM, Jim Jagielski wrote:
>
>
> Well, it's mine and it should be anyone's really. After all,
> we are not talking about the "extra" time taken in the request/
> response phase but rather the switch-time taken for Apache
> to determine when/if to proxy and where. Total req-pe
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 *ssl_expr_comp(apr_pool
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, mod_mem_
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VF_EITO?= wrote:
> > Von: Jim Jagielski=20
> > Gesendet: Dienstag, 31. Oktober 2006 17:05
> > An: dev@httpd.apache.org
> > Betreff: Re: AW: [Fwd: Re: Apache 2.2.3 mod_proxy issue]
> >=20
> >=20
> > >=20
> > > I am a regexp fan and have mod_rewrite loaded in any
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
On 10/31/06, Graham Leggett <[EMAIL PROTECTED]> wrote:
Apparently the non blocking changes are only specified in trunk.
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
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
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 openss
> -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 s
>
> 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 w
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
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 sp
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 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 id
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
> -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
> 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
> > t
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 t
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 straightforw
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 in
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 som
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
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
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 si
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 c
> -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 Eren
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:
# V
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 v
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 s
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 wou
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 pur
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
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'
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 h
> -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 bucke
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, b
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
> >>> consu
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
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 a
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 e
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 throu
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 specia
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 anywa
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 buc
49 matches
Mail list logo
