[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565081#action_12565081
]
Thomas Peuss commented on SOLR-127:
-----------------------------------
bq.Thomas: each core has it's own classloader for plugins defined in the lib
directory of the solr home - but the "main" Solr code (in the solr.war) is
loaded by the webapp context classloader - so static variables in "core" solr
code really are singletons.
OK. Then we need a "per-core" cache. A weak-hashmap would be sufficient to
achieve this. You can use the core-name as key for example.
bq. Would that explain the problems you are seeing in the test? does it relate
to the etagCache?
I am pretty sure that it does not relate to the etagCache. I think it is some
static variable stuff in the SolrConfig parts. I try to track that down tonight
when I have put my daughter to bed.
bq. I thought the problem was that even in the "NoCache" test it as expecting
to see a Cache-Control header even though solrconfig-nocache.xml doesn't have
one configured?
This tests are wrong. You are completely right. The current code should fail in
the "nocache" scenario. Currently it does not because of the problem I have
described.
bq. (We have several tests that load cores with different configs that
currently work, and we've never really noticed any problems like this before
... so i'm hesitant to assume it's unrelated to the patch)
But only one of them (the SolrJ tests) loads the Solr code through Jetty (so it
might be a Jetty related problem as well).... All other tests use the Solr code
directly.
> 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.
