Print

---

CacheDirective part is good ... now I have some comments :)

This implements no-cache and no-store in the same way. From MDN docs:

1. no-cache - re-check file/object on origin; and
2. no-store - do not write to disk what was read in this request.

In this PR both 1. and 2. prevent the XrdPfcFile (for potentially other attached IOs, especially in forwarding mode proxies) from either using the cached data or writing any data -- each request is forwarded to the remote and then not written into the cache (see also note [1] below). The requests are also still broken into cache blocks which is rather unnecessary.

I do not think this should be propagated to XrdPfcFile -- instead, it should be resolved at the level of the IO object by simply forwarding the requests to the remote (through the original IO).

Now, if this is a direct mode proxy, several input connections will get piled over on the same IO and cache commands will only get parsed for the first one. To solve this, we would need to parse the directives beforehand and connect each client to appropriate cache IO object. In this case (to satisfy functionality introduced in this PR) we would have two: a) standard one; and b) no-cache-or-store one.

Alternatively, if this is possible, case b) could use the memory-cache implementation.

This would satisfy ?no-cache and ?no-cache&no-store (as we can not re-check file state at the origin). For ?no-store we could forward the no-store state along with the ReadRequest.

As I've been writing this ... it seems increasingly that this extensions make more sense for forwarding mode caches. How were you actually envisioning these to be used? You see my point, http proxy caches urls (server+object-name) ... xcache only caches object-names that were, up to now, assumed to be immutable (as HEP data usually is, if you have a new version of the file it is either in another directory or has a different name).

@abh3 if there are URL arguments in the open request -- does this affect selection of IO object in direct mode proxies? I.e., would open("/foo.root?a") and open("/foo.root?b") use the same IO object?

Notes

1. It is unclear how to properly implement no-cache in XCache case: even if we were to do stat on some remote replica the most we could check would be file-size -- unless we required a checksum support and also stored it in the pfc info file. I assume this is why you implemented it as always requesting data from the remote. Still, with no-cache it could still be allowed to be stored (but could conflict with the existing data in the cache and that's why you decided to drop it).

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <xrootd/xrootd/pull/1953/c1467103012@github.com>

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1