[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564228#action_12564228
]
Hoss Man commented on SOLR-127:
-------------------------------
bq. When you have a cluster of slaves then their last-mods would differ - but
does that really hurt? I think no.
The funny thing is: that's what i originally thought, and then you got me
worried about it : )
I think you are right: but let's at least give people who want to have Last-Mod
headers which are in sync across all slaves an option for basing it on the
dir.lastModified. We'll be giving them rope to hang themselves with if they
change the cacheHeaderSeed because that will change the ETag without changing
the Last-Modified, but it will be soft velvety rope that probably won't hurt
since most caches are either going to use the ETag or the Last-Modified -- not
both. (besides: as long as it's documented well, they can always force a new
snapshot when they change the cacheHeaderSeed (Hmmm... "etagSeed" is better
now) so that both headers change consistently.
So to sum up...
* three http caching related options...
*# lastModFrom="openTime|dirLastMod" ... default is openTime
*# etagSeed="arbitrary string" ... default is some constant (ie: "Solr")
*# cacheControlHeader="arbitrary string" ... default is NULL
* headers are commuted as...
** Last-Modified = $lastModFrom
** ETag is a hashcode of the indexVersion and $etagSeed
** Cache-Control is $cacheControlHeader if set (otherwise no Cache-Control
header)
** Expires is $now+$maxAge if $maxAge can be found in $cacheControlHeader
(otherwise no Expires header)
* resulting behavior...
** Default behavior (lastModFrom=openTime)...
*** Slaves with identical snapshots will have identical Etags and Last-Mod
headers that may not be exact but should tend to be close, so only a little
extra load around the time of a new snapshot.
*** If you rollback an index to a previous version, you will get a new Last-Mod
and ETag headers.
*** Changing configs and restarting core won't cause Etag to change, but
Last-Mod will because of newly opened Searcher -- If you've got an index that
changes semi regularly then the ETag will get updated as soon as a new version
gets opened, or you can add the etagSeed option to force new ETag on startup.
** for people who really want Last-Mod to always be in sync across all slaves
(lastModFrom=dirLastMod)...
*** Last-Mod will only ever change when index changes.
*** You probably won't care about ETags, but it will stay consistent until
index changes.
*** If you change configs, and you do care about ETag, you could update the
etagSeed -- but there's not much point since you'll also need to generate a new
snapshot on your master to force a new Last-Mod header to be updated.
does that sound good?
(fingers crossed i can bang this out on 2007-01-31 between 13:00-18:00
America/Los_Angeles ... unless you want to beat me to it Thomas : ) )
> Make Solr more friendly to external HTTP caches
> -----------------------------------------------
>
> Key: SOLR-127
> URL: https://issues.apache.org/jira/browse/SOLR-127
> Project: Solr
> Issue Type: Wish
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: 1.3
>
> Attachments: CacheUnitTest.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch
>
>
> an offhand comment I saw recently reminded me of something that really bugged
> me about the serach solution i used *before* Solr -- it didn't play nicely
> with HTTP caches that might be sitting in front of it.
> at the moment, Solr doesn't put in particularly usefull info in the HTTP
> Response headers to aid in caching (ie: Last-Modified), responds to all HEAD
> requests with a 400, and doesn't do anything special with If-Modified-Since.
> t the very least, we can set a Last-Modified based on when the current
> IndexReder was open (if not the Date on the IndexReader) and use the same
> info to determing how to respond to If-Modified-Since requests.
> (for the record, i think the reason this hasn't occured to me in the 2+ years
> i've been using Solr, is because with the internal caching, i've yet to need
> to put a proxy cache in front of Solr)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
