This feature also has some problems with large documents in the cache. As far as I can tell it forwards what the writer has on read open then the rest when the writer closes the connection. This is fine for small documents on short lived connections, but is unacceptable for large documents on long lived connections. It also buffers the entire document in memory which could be a problem as well.
I have to do some work on this code to support random reads for efficient range operations as well, so if you have any cache API needs/ideasn related to this feature, I'd like to hear them. john Dima Ruban wrote: > On Mon, Dec 21, 2009 at 09:23:36PM -0700, Leif Hedstrom wrote: >> I believe this is being worked on right now, not sure quite what the >> status is. Dima Ruban, want to comment on this (since you "own" this >> part)? It is supposed to work, but I think those "connection_collapsing" >> configs are either not functioning properly, or not at all ;). There is >> a feature called "read-while-write" (rww) which should work, and I >> believe Dima is working on cleaning up this mess a bit. > > Read-while-write feature (proxy.config.cache.enable_read_while_writer) > should work w/ builtin cache. Keep in mind that this feature is nearly > identical to what other products/projects call a forward connection > collapsing. > The way it works is - as soon as writer starts writing object into a cache, > all the subsequent requests to that object will be able to serve it out from > cache even before writer completes writing the entire object. > Writer starts writing into cache once it receives headers from the origin > server, so if second request came before first request received headers, > read while write isn't gonna come into play. Current code tries to > deal w/ it with 'connection_collapsing' options but as far as I know it > doesn't work properly. > It's gonna be addressed in the newer version of read-while-write that I'm > working > on right now. > > Cheers! > >> Cheers! >> >> -- leif >> >> > > --dima
