On Tue, 26 Sep 2006, Graham Leggett wrote:
On Tue, September 26, 2006 1:00 pm, Joe Orton wrote:
This was discussed a while back. I think this is an API problem which
needs to be fixed at API level, not something which should be worked
around by adding bucket-type-specific hacks.
API changes won't be backportable to v2.2.x though, although you're right.
Won't that method mean that caching the file will happen at the speed
the client reads the file?
So, with only one session caching a file and read-while-caching (ie.
the features you want in the end) you can get the following scenario:
- Sloooow client starts downloading a large file. First access, the
file is getting cached sloooowly.
- Fast clients starts downloading the same file, but slowly caused by
the pacing of the slow client.
I suspect that this also means that if the "caching" client hangs up
before the caching is finished we'll have to toss what's been cached
so far, or do we get that error before the brigade is destroyed?
In any case, it sounds like a better way to do it than the current
always-eat-your-memory-and-die solution, but I think that we'll be
needing that kludge to get good behaviour in our
caching-frontend-for-ftpserver-case ...
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---------------------------------------------------------------------------
"But I was going into Toshi Station to pick up some power converters..."
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
