[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564690#action_12564690
]
tpeuss edited comment on SOLR-127 at 2/1/08 1:09 AM:
-----------------------------------------------------------
{quote}
* the test classes still need some work, both in terms of the current
failure mentioned above, and to cover more permutations of options. When we're
all said and done, we'll probably want at least 3 separate sets of test/configs:
1. default, no <httpCaching> section in config at all ... should
generate Last-Mod and Etag headers and do validation, stoping/starting port
should make Last-Mod change but not ETag.
2. never304="false", lastModFrom="dirLastMod" ... should generate
Last-Mod and Etag headers and do validation, no headers should change if we
stop/start the port.
3. never304="true" ... no Last-Mod of ETag headers, no 304 even if we
send crazy old If-Modified-Since
* there's also probably some refactoring that can still be done in the
tests (i noticed some duplicate code that can be moved up into the Base class)
{quote}
I take care of the tests.
{quote}
* it occurred to me while adding the etagSeed that right now the etag
caching is a singleton, we'll need to make this core-specific (using a
WeakHashMap i guess? i'm not fond of that approach, but these are really tiny
pieces of info we are caching)
* calcLastModified and calcEtag currently assume they can get
requestDispatcher/httpCaching config options from SolrConfig ... but this need
to be reconciled with SOLR-350 where there is a plan to move all
requestDispatcher configs to multicore.xml (but i've pointed out in that issue
i'm not sure if that is necessary or makes sense.)
{quote}
When I remember right every core has its own classloader. Then every core has
its own set of static fields. This is why real singletons are not that easy to
do in Java.
was (Author: tpeuss):
{quote}
* the test classes still need some work, both in terms of the current
failure mentioned above, and to cover more permutations of options. When we're
all said and done, we'll probably want at least 3 separate sets of test/configs:
1. default, no <httpCaching> section in config at all ... should
generate Last-Mod and Etag headers and do validation, stoping/starting port
should make Last-Mod change but not ETag.
2. never304="false", lastModFrom="dirLastMod" ... should generate
Last-Mod and Etag headers and do validation, no headers should change if we
stop/start the port.
3. never304="true" ... no Last-Mod of ETag headers, no 304 even if we
send crazy old If-Modified-Since
* there's also probably some refactoring that can still be done in the
tests (i noticed some duplicate code that can be moved up into the Base class)
{quote}
I take care of the tests.
{quote}
* it occurred to me while adding the etagSeed that right now the etag
caching is a singleton, we'll need to make this core-specific (using a
WeakHashMap i guess? i'm not fond of that approach, but these are really tiny
pieces of info we are caching)
* calcLastModified and calcEtag currently assume they can get
requestDispatcher/httpCaching config options from SolrConfig ... but this need
to be reconciled with SOLR-350 where there is a plan to move all
requestDispatcher configs to multicore.xml (but i've pointed out in that issue
i'm not sure if that is necessary or makes sense.)
{quote}
When I remember right every core has its own classloader. Then every core has
its own set of static fields (and why real singletons are not that easy to do
in Java).
> 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, 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.
