[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562405#action_12562405
]
Thomas Peuss commented on SOLR-127:
-----------------------------------
bq. Getting back to the question of the ETag though, i think it would be better
to use a hashCode on the config itself ... if the index hasn't changed, and the
config hasn't changed restarting Solr shouldn't make the ETag change.
It is a good idea to use a hash of the config as well. But we need to write
that down somewhere that identical slaves need identical indexes *and* config
files as well to have the same ETag.
bq. "expect" ? ... uh, i have no expectations from you ... Solr is an volunteer
project, no one is expected to do anything other then contribute
when/where/however they can
I know. "Expect" might have been the wrong word for that. :-) I only want to
make sure that we do not work on the same stuff. I love the peer review you get
with OSS projects.
bq. First and foremost: do you think being able to customize the "cache
awareness" of Solr on a per request handler basis is important enough that we
shouldn't move forward until we figure out a way to make it work, or do you
think it's useful to have a single SolrCore wide configuration for this sort of
thing?
A SolrCore wide config for this is enough IMHO.
{quote}
Assuming we're on the right track, my game plan moving forward is:
1) i'm going to startplay around with the config options and the control flow
logic to make sure we don't do 304 style validation work when we shouldn't
2) i suggest we think/discuss the openTime/lastModified and config modified /
ETag issues a little more before making any changes there
3) the tests will need refactored so we have at least 2 variants ("doing
caching right", not doing caching because we said not to") ... if you want to
take a look at doing that now, that would be great - particularly since i'm not
very familiar with the framework Ryan setup for doing JUnit tests that actually
spin up Jetty to do the HTTP layer.
{quote}
Ad 2.: Whatever we choose: Two things must be linked: changed index and/or
changed config must change the Etag *and* the Last-Modified time (this must be
changed on config change as well!). Last-Modified must be the maximum of config
file change time and index change time...
Ad 3.: Most of the time I have spent with the unit test was to fiddle out how
this Jetty stuff works... ;-) I have a look at this.
> 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: 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.
