[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562274#action_12562274
]
Hoss Man commented on SOLR-127:
-------------------------------
bq. Good point. You can get around that problem by using the openTime for the
ETags as well.
yeah ... ugh ... i'm actually starting to question whether or not openTime is
even the right choice for Last-Mod ... you made a really good point before
about it causing Last-Mod times to differnet between multiple (identical)
slaves, but at least the ETags would be in sync ... if we add openTime to the
ETag we lose even that.
my initial concern about using IndexReader.lastModified for Last-Mod was the
case where someone rolls back an index, but that's really the exceptional case
... most people will probably never encounter it (and if they do, they can work
around it by "touching" the segments file ... or we could have another option
for it ... lastModFrom="open|disk" ... what do you think?)
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.
bq. What do you expect from me now? Should I have a look at the testcase?
"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 :)
seriously though: you've clearly thought about this task more then anyone else
at this point, i'm just throwing out ideas and concerns, if you think i'm
making stupid suggestions, or over thinking something, or not thinking hard
enough about something else let me know.
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?
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.
> 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
>
>
> 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.
