[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563896#action_12563896
]
Thomas Peuss commented on SOLR-127:
-----------------------------------
What about using the index opening time for last-modified and allow an
arbitrary string for the cacheHeaderSeed? The opening time is guaranteed to be
greater than both index-last-mod and config-last-mod. When you have a cluster
of slaves then their last-mods would differ - but does that really hurt? I
think no.
Think of following scenario:
* Slave 1 has opentime X
* Slave 2 has opentime X+2
* Slave 3 has opentime X+4
When you have round-robin load balancing all clients sometime in the future hit
Slave 3 and save _X+4_ as last-mod for the request. When they now issue a
request with a conditional header (If-Modified-Since X+4) Solr on Slave 2 and 3
would send a 304 (Not-Modified) as well. When the index changes you would get a
suboptimal behavior for some time - but the code would be much easier.
This would allow us to use an arbitrary string in cacheHeaderSeed for the
ETags. To put semantics in cacheHeaderSeed is error prone. I don't like that.
I am fine with the regex solution. It is both flexible and easy to code.
> 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.
