Re: Hot object cache

On Mon, 2002-10-21 at 11:21, Henrik Nordström wrote:

> > > How do we handle these two requests?
> >
> > This one *seems* trivial. storeGetPublic should not find an object that
> > is not cachable. So the second client will get a new storeEntry.
>
> Not today.. these objects start out as cacheable today, and only when it
> becomes known the size is too large the new object is marked uncacheable.
> This puts us into all kinds of problems if there is more than one client
> attached when we later find out we can not / do not want to cache the
> object..

Well, if we don't know that it's cacheable, we shouldn't mark it as
such, until we *know*.
 
> You also have another corner case if the store aborts storage of the
> object due to overload (or less likely I/O error).

Yep, I'll think on this one.
 
> I have another goal here that I think is important: Implementation of a
> store I/O layer should be simple.

Agreed.
 
> Having the assumtion that a FS layer must be able to swap in data while it
> the same is beeing swapped out is not a trivial assumtion and quite likely
> to be error prone.

Actually, it's quite simple if you layer it right. The only assumption
I'm making is that data that has been swapped out can be retrieved -
which seems reasonable to me :}.

> In this we also need to consider what happens when
> index management is moved down to the FS layer as an integral part of the
> on-disk storage.

Yes, and we can deal with that when those changes are ready. IMO this
will not impact the index issues. The storeSwapper will not be part of
the fs layer or the store itself.
 
> Maybe, but I would propose merging into a new StoreEntry for start..

Hmm. Will consider. Seems a lot more confusing to me.

> Saving the merged object as a new StoreEntry makes cache transactions much
> more well defined. If we later find that this generates a considerable
> amount of copying then lets try to address "in-place merges" then, but
> before we do index management should have been moved down to the FS layer.

Why? This is orthogonal.
 
> So no, I still do not see why range merging would need to allow more than
> one client per active retrieval.

Please define active retrieval.
 
> > Now, if we have a single client logic, then we cannot satisfy more than
> > one client from the cache, if data is missing. A multi client logic
> > allows us to do that.
>
> I think we may have some confusion on exacly what a "StoreEntry" is or
> should be.
>
> Please define your view of a "StoreEntry".
>
> My view of a "StoreEntry" is "a active object". The fact that we use
> "StoreEntry" for the in-core index I see as an artefact of the current
> index design, and not a long term goal. In fact I would even prefer if we
> got rid of "StoreEntry".

I don't have a specific view of StoreEntry. It is very over used in
squid, and that is one of the things I am refactoring, making it clearer
what is a StoreEntry, what is a store client, what is a mem object etc.

I think we need something that is returned when a client gets data about
a cached object. THAT thing may as well be called StoreEntry.

> Without request joining support each client would use the previously
> cached data and then request the missing pieces as needed to satisfy their
> request. If both requests are successful then both will generate a cache
> update, and if such updates is done into new objects then only one of them
> will stay in the cache.

This requires the following logic:
something in front of the two requests to iterate through both objects
(missing data and current data(
It should then save the result to a new storeEntry right?
It must also grab *all* the data from the current store entry and copy
it across.
It will also race when multiple clients do this to the same object.

I really don't like this design. It seems a kludge to use what we've
got, rather than putting something clean in place.

> With this I propose that the point where objects are made public to other
> clients is moved from "this reply seems to be cacheable" to "this reply
> has been stored in full", and that we need to redefine how "delayed
> aborts" is handled (these are kind of special in any event..)

Agreed. Well, rather than "stored in full" I would say "is definately
cacheable".
 
> > Ok. I'll enlarge on this this afternoon. Basic detail is:
> > Remove all current storeSwapout API calls.
> > Create a new API call i.e.: StoreSwapper *createSwapper(StoreEntry &,
> > HttpReply &, request_t &).
> > This call will create an object that will:
> > Check the swapout policy and do nothing if the object is not to be disk
> > cached. (which includes having range data for now).
> > Otherwise:
> > Start reading the object at offset 0, and will sequentially read through
> > and swap out until the object is:
> > * Aborted (remove disk object (for now)).
> > * EOF is reached.
>
> Ok, but I am not sure I agree on the desing principle of having swapout
> via a second store client. I Don't really like having swapout store
> clients just as any other client. Such "swapout" clients are different in
> that they should not cause any retreivals, and should get aborted if the
> "last" real client aborts.. (delayed aborts is another question.. no
> matter what is done these requires special attention if supported..)

Mm. This is a very simple thing to handle without needing another store
client type - simply allowing the store swap logic to query what is
available, and whether the object is still being appended to will allow
that. The API already does the rest,

> I think it is better to define another form of "store client" for this
> purpose, where data semantically is pushed to the client rather than
> retrieved by the client. Same mechanism should probably be used by both
> the on-disk and hot object caches.

I don't think we need such a 'push client'. We can always add one if a
pull client proves unable to do the job, but IMO we should try first.
Either way there will be less code than there is now.

Rob