Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/mod_mem_cache.c

Justin Erenkrantz wrote: I will also note that the mod_cache provider system has explicit versioning, so any modifications to the providers should be represented with a new version number. (i.e. providers for version "0" should work while offering new features in version "1"-class providers.)

Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/mod_mem_cache.c

On 10/30/06, Issac Goldstand <[EMAIL PROTECTED]> wrote: Can you clarify the above a bit? I don't understand what you're referring to. Looking at the 2.2.3 tag, what versioning is currently in place? Look at disk_cache_register_hook. /* cache initializer */ ap_register_provider(p, CAC

Re: [Fwd: Re: Apache 2.2.3 mod_proxy issue]

Ruediger Pluem wrote: Then you can easily just use ProxySet ... It will define a 'known' worker. There is no need for an additional directive. Yes, this idea came also up to me after sending the mail. It seems to be an acceptable solution for this problem, but we should really add ProxyS

Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/mod_mem_cache.c

Justin Erenkrantz wrote: On 10/30/06, Issac Goldstand <[EMAIL PROTECTED]> wrote: Can you clarify the above a bit? I don't understand what you're referring to. Looking at the 2.2.3 tag, what versioning is currently in place? Look at disk_cache_register_hook. /* cache initializer */ a

Re: [RELEASE CANDIDATES] Status ?

Philip M. Gollucci wrote: this one time in band camp Issac Goldstand said on 10/29/06 01:41: If you're planning on rolling libapreq-2.09 soon, maybe we should include the intial work done in /branches/enhanced-cgi/ It seems

Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/

On Mon, October 30, 2006 7:58 am, Justin Erenkrantz wrote: >> We have a real world case where the cache is expected to process a many >> MB or many GB file completely, before sending that same response to the >> network. This is too slow, and takes up too much RAM, resulting in a >> broken respons

Re: [Fwd: Re: svn commit: r467655 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/mod_cache.c modules/cache/mod_cache.h]

On Mon, October 30, 2006 4:54 am, William A. Rowe, Jr. wrote: > You mean sandboxes (at least that's what we normally refer to them as, > trunk/ IS the dev branch :) ... > > I strongly disagree because MOST of the flaws in the HTTP/1.1 > implementation, > mod_proxy and even mod_cache exist because

Re: mod_cache and its ilk

Thanks Roy. So, the goals for mod_disk_cache as I see it: A simple general-purpose disk cache which makes no assumptions about speed of backend, speed of storage or speed of clients; is single-threaded and does not involve any multi-process synchronisation beyond open/O_EXCL. Specifically: 1

Re: mod_cache and its ilk

On Mon, October 30, 2006 12:07 pm, Joe Orton wrote: > Thanks Roy. So, the goals for mod_disk_cache as I see it: > > A simple general-purpose disk cache which makes no assumptions about > speed of backend, speed of storage or speed of clients; is > single-threaded and does not involve any multi-pr

Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/mod_mem_cache.c

On Mon, 30 Oct 2006 01:53:18 +0200 Graham Leggett <[EMAIL PROTECTED]> wrote: > The current expectation that it be possible to separate completely > the storing of the cached response and the delivery of the content is > broken. Why is that? (references to previous discussion will do, if applicabl

Re: mod_cache and its ilk

On Mon, Oct 30, 2006 at 12:18:30PM +0200, Graham Leggett wrote: > On Mon, October 30, 2006 12:07 pm, Joe Orton wrote: > > 1) cannot write entire response to disk for any content type before > > sending anything to the client; filter acts by writing to cache and > > client synchronously > > Justin

Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/

On Mon, October 30, 2006 12:57 pm, Nick Kew wrote: >> The current expectation that it be possible to separate completely >> the storing of the cached response and the delivery of the content is >> broken. > > Why is that? Because: - the cache_body() hook is expected to swallow an entire brigade

Re: mod_cache and its ilk

On Mon, October 30, 2006 1:03 pm, Joe Orton wrote: >> On Mon, October 30, 2006 12:07 pm, Joe Orton wrote: >> > 1) cannot write entire response to disk for any content type before >> > sending anything to the client; filter acts by writing to cache and >> > client synchronously >> >> Justin vetoed

Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/

On Mon, 30 Oct 2006 14:03:03 +0200 (SAST) "Graham Leggett" <[EMAIL PROTECTED]> wrote: > On Mon, October 30, 2006 12:57 pm, Nick Kew wrote: > > >> The current expectation that it be possible to separate completely > >> the storing of the cached response and the delivery of the content > >> is brok

Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h

On Mon, October 30, 2006 2:44 pm, Nick Kew wrote: > Hang on! Where's the file coming from? If it's local and static, > what is mod_cache supposed to gain you? And if not, what put it > in a (single) file bucket before it reached mod_cache? In the case of the person who reported this issue, the

Re: mod_cache summary and plan

Davi Arnaut wrote: The solution consists of using the cache file as a output buffer by splitting the buckets into smaller chunks and writing then to disk. Once written (apr_file_write_full) a new file bucket is created with offset and size of the just written buffer. The old bucket is deleted.

Re: mod_cache summary and plan

On Mon, October 30, 2006 4:44 pm, Brian Akins wrote: > Without having looked very much at the code, this approach sounds > feasible. > > I'm still confused as to why we need the temporary brigade??? Why not > "swap" > the buckets? The current cache (as in what is in trunk right now) does exactly

Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/mod_mem_cache.c

On 10/30/06, Issac Goldstand <[EMAIL PROTECTED]> wrote: Looking at provider.c, a couple of questions spring to mind: 1) Why isn't this part of apr-util? (it seems similar to apr_optional.h - just intended for vtables rather than functions, and with this version info) apr_optional is an ugly hac

cache API visibility (was Re: svn commit: r468373...)

On Mon, Oct 30, 2006 at 09:51:30AM -0700, Justin Erenkrantz wrote: > >It would make > >custom 3rd party modules easier to write too; we could define, say 1 > >as PROVIDER_ID_CUSTOM, making it easier to write add-ons to modules > >which use the provider interface to just write new providers with

Re: mod_cache and its ilk

On 10/30/06, Joe Orton <[EMAIL PROTECTED]> wrote: A simple general-purpose disk cache which makes no assumptions about speed of backend, speed of storage or speed of clients; is single-threaded and does not involve any multi-process synchronisation beyond open/O_EXCL. Specifically: +1. I woul

Re: cache API visibility (was Re: svn commit: r468373...)

On 10/30/06, Joe Orton <[EMAIL PROTECTED]> wrote: So here's another assumption to consider with this work... 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

Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h modules/cache/mod_mem_cache.c

Justin Erenkrantz wrote: > On 10/30/06, Issac Goldstand <[EMAIL PROTECTED]> wrote: >> Looking at provider.c, a couple of questions spring to mind: >> 1) Why isn't this part of apr-util? (it seems similar to apr_optional.h >> - just intended for vtables rather than functions, and with this version >

Re: mod_cache and its ilk

On Mon, Oct 30, 2006 at 10:26:18AM -0700, Justin Erenkrantz wrote: > On 10/30/06, Joe Orton <[EMAIL PROTECTED]> wrote: > >1) cannot write entire response to disk for any content type before > >sending anything to the client; filter acts by writing to cache and > >client synchronously > > My concer

cache: the store_body interface

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 bucket is the pathol

Re: mod_cache and its ilk

On 10/30/06, Joe Orton <[EMAIL PROTECTED]> wrote: On Mon, Oct 30, 2006 at 10:26:18AM -0700, Justin Erenkrantz wrote: > My concern with this is we should be careful not to teach the > providers about the fact that it is sitting in an output filter chain. This is solvable if desired, but I'd like

Re: cache: the store_body interface

On 10/30/06, Joe Orton <[EMAIL PROTECTED]> wrote: 1) change the store_body interface to allow the storage provider direct access to f->next, so it can flush buckets up the output filter chain when they have been stored. As seen on trunk. 2) keep the interface as-is, but read buckets in mod_cach

Re: mod_cache and its ilk

Justin Erenkrantz wrote: +1. I would prefer that all bells and whistles be kept out of mod_disk_cache and we provide another alternative that has more complex behaviors that scales a little better for those who care. (That was the whole reason behind a versioned provider interface to begin with

Re: cache: the store_body interface

Justin Erenkrantz wrote: 1) change the store_body interface to allow the storage provider direct access to f->next, so it can flush buckets up the output filter chain when they have been stored. As seen on trunk. 2) keep the interface as-is, but read buckets in mod_cache and partition the brig

Re: How to increase the size of the apache array manually?

Am Montag, den 30.10.2006, 18:42 +0530 schrieb Manish Chakravarty: > Hi all, > > I am developing a module on Apache 1.3. Can someone please tell me how > to increase the size of an Apache array manually? > > Do i manually increment the nelts field? If this works as on 2 you simply have to call a

Re: LDAPTrustedClientCert?

On 10/24/06, Graham Leggett <[EMAIL PROTECTED]> wrote: For example, if you are using OpenLDAP, you need to set you CA certificates using LDAPTrustedGlobalCert, and set your client certificates on a per connection basis inside a directory and/or virtual host container using LDAPTrustedClientCert.

Re: cache: the store_body interface

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. ;-) -1 to doing that with local,

Re: cache: the store_body interface

On 10/30/2006 07:53 PM, Graham Leggett wrote: > Justin Erenkrantz wrote: > >>> 1) change the store_body interface to allow the storage provider direct >>> access to f->next, so it can flush buckets up the output filter chain >>> when they have been stored. As seen on trunk. I am with Justin he

Re: LDAPTrustedClientCert?

Eric Covener wrote: Some research shows only alpha releases of openldap even pretend to allow the CERTFILE/KEYFILE on a per-connection (i.e. LDAP*) basis -- the latest "stable" and "released" levels (2.3.28, 2.3.27) ldap_pvt_tls_set_option will explicitly bail out of the CERTFILE/KEYFILE option

Re: cache: the store_body interface

On 10/30/06, Nick Kew <[EMAIL PROTECTED]> wrote: -1 to doing that with local, static files. And once you start making exceptions to a rule, that becomes BAD complexity. What exceptions are you talking about? Everything would be treated as a char *, size_t pair. It's quite simple, actually...

Re: [Fwd: Re: Apache 2.2.3 mod_proxy issue]

On 10/29/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote: > 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. > >

Re: LDAPTrustedClientCert?

On 10/30/06, Graham Leggett <[EMAIL PROTECTED]> wrote: Eric Covener wrote: > Some research shows only alpha releases of openldap even pretend to > allow the CERTFILE/KEYFILE on a per-connection (i.e. LDAP*) basis -- > the latest "stable" and "released" levels (2.3.28, 2.3.27) > ldap_pvt_tls_set_

Re: LDAPTrustedClientCert?

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 SSL_library_init(); before ldap_set_option > or it di