vary implementation questions

Hello,

During the implementation of the Vary support we have encountered a few
seriuos problems.

0. We create a StoreEntry to store information about the variants.
We call it "our StoreEntry", but we believe that it behaves just like
the one currently represents "vary base object" in squid 3, the only difference is that we'd like to modify it.

It is swapped out after the creation (in storeSetPublicKey).
When new information about variants come we have to change it and swap it
out again.

Is it possible?
We have tried and tried and finally gave up.
How could we do this?

1. We have noticed that after we change our StoreEntry (and not swap out it
(see 0)) it remains in the memory until the squid is running.
Could this StoreEntry be freed and thrown out of the memory somehow?
Is it somehow marked not to be freed?

2. Suppose we kill squid and start it again.
We storeGet our StoreEntry. We get it, however it has NOT_IN_MEMORY
mem_status while before the killing it was IN_MEMORY.

Even though it seems that our StoreEntry is back in the memory,
we'd like to understand the difference between the two mem_statuses.

3. We wonder what is the intended semantics of the statuses/flags:
IN_MEMORY, NOT_IN_MEMORY, SWAPOUT_XXX, STORE_DISK_CLIENT, STORE_MEM_CLIENT?

4. Now the question concerning swapping the mem_object in.
Is registering a store_client and then calling storeClientCopy() with
proper callback enough to make the StoreEntry swap its mem_object in?
Is there any other (better) way?

Any help will be welcomed :]

As for Co-Advisor, we are trying to get us a public IP.
When we get it we'll let know.

Regards
Michal Matusiak
Received on Mon May 24 2004 - 03:10:29 MDT