lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Peuss (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SOLR-127) Make Solr more friendly to external HTTP caches
Date Mon, 17 Sep 2007 09:12:32 GMT

     [ https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Thomas Peuss updated SOLR-127:
------------------------------

    Attachment: HTTPCaching.patch

1.) I now use the time the reader was opened. But we should be aware of the fact that when
we have two servers (for HA reasons for example) this times differ for sure. For clients with
ETag support this is no problem because the ETag will be still the same.
2.) You are right it is ETag. Clients/servers handle the headers case-insensitive. This is
why I have not seen that...
3.) Some clients support only ETag, some support only Last-Modified, many support both. That's
why we should support both. And you are right: the ETags can more than we use.

You spoke about taking the result of a search into account. Maybe we are talking about two
different things here. This patch is about getting load off the server. When we want a 100%
confident client then we need to take the server response into account. But currently I don't
see a big benefit of this and it makes the code much more complex.

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


Mime
View raw message