lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-127) Make Solr more friendly to external HTTP caches
Date Tue, 18 Mar 2008 17:55:24 GMT

    [ https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579953#action_12579953
] 

Hoss Man commented on SOLR-127:
-------------------------------

For the record: most of this discussion should have happened on the solr-dev list, not in
the issue comments ... but i would like to address some points, so I'll do it here since this
is where the discussion is.

1) It's true, there is no way to configure caching on a per request handler basis -- if you
look at the history of the issue we looked into that but because of the necessary API changes
we scaled back the scope of the patch -- it can be done, it just needs more thought into how
to do it and people interested in working on it.

2) there is no doubt in my mind that having the cache awareness code on by default is the
right approach moving forward.  These options don't cause Solr do do any caching, or to force
any external caches to cache the pages -- they only result in Solr behaving correctly according
to the HTTP spec sections relating to cache headers:  
   * *if* a request is made to Solr via an HTTP cache that cache will receive headers it can
use to decide if/how-long to cache the response
   * *if* Solr receives a request with cache validation information then it responds with
a 304
if you don't want that behavior then either don't access Solr via a cache, or explicitly set
the <httpCaching never304="true"> option; but the default behavior for people who are
upgrading from 1.2 should be for Solr to emit Correct headers and to respect validation requests.
 Requiring Solr users to explicitly turn on an option to get Solr to emit correct Caching
headers would be like requiring them to explicitly set an option to get well formed XML instead
of invalid XML -- the default should be the one that behaves the most correctly.

I admit however: this is a notable enough change that it should be mentioned in the "Upgrading
from 1.2" section of CHANGES.txt -- I will add that.

3) if other pending patches attached to other issues have poor behavior as a result of the
caching code, the appropriate place to discuss that is in those issue -- the solution may
be to mark those issues dependent on a new issue to add the API hooks for request handlers
to suppress caching (that's a good idea in general) but it's also possible that there are
better/safer/more-logical solutions specific to those patches ... if the DataImportHandler
is having problems because the caching code, i'm guessing it's because people use it to trigger
updates using an HTTP GET -- that violates the semantics of GET and making work arounds in
the the HttpCaching code to allow for that is a bad idea.

4) saying only the "/select" handler should get it's responses cached is missleading -- under
Solr 1.3 there won't be anything special about /select ... any handler name can be used for
queries, and any handler name can be used for updates ... if you are issuing a request that
modifies the index, you should be sending a POST and no caching headers (or validation) will
be done by Solr regardless of configuration.

As I said, discussion about the general topic of HTTP Caching, Solr, and what the defaults
should be should really happen on the solr-dev list ... if there are any further comments
let's please conduct them there and then open/update whatever issues we need to once a consensus
has been reached.


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