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.
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.