lucene-solr-dev mailing list archives

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

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

Shalin Shekhar Mangar commented on SOLR-127:
--------------------------------------------

It seems there is no way to disable caching on a per-handler basis. I've read through the
comments on this issue but I'm still not convinced as to why we need to enable HTTP Caching
by default. The way I see it is that using a HTTP Caching Proxy in front of SOLR is a very
rare use case and people using it in their deployments can always go and enable caching in
solrconfig. The downside of enabling this by default is that there is no way right now to
disable it on a per-handler basis and even if there was a way, everyone would have to explicitly
do it in their configuration and is something that we would have to educate users unnecessarily.

Our use case is the SOLR-469 DataImportHandler, which should not have responses cached at
any time. But there is no way for me to do it currently. I'm sure there will be other use
cases too e.g. SOLR-502 for which partial results are also cached right now.

I appreciate the work you all have put into this issue and all I'm trying to say is that a
feature used very rarely should not be enabled by default. I'd like to vote to go back to
Solr 1.2 compatibility by default.

> 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