I tried your suggestion, Hoss, but committing to the new coordinator core doesn't change the indexVersion and therefore the ETag value isn't changed.
I opened a new JIRA issue for this http://issues.apache.org/jira/browse/SOLR-1765 Thanks, Charlie -----Original Message----- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Thursday, February 04, 2010 2:16 PM To: solr-user@lucene.apache.org Subject: Re: HTTP caching and distributed search : > http://localhost:8080/solr/core1/select/?q=google&start=0&rows=10&shards : > =localhost:8080/solr/core1,localhost:8080/solr/core2 : You are right, etag is calculated using the searcher on core1 only and it : does not take other shards into account. Can you open a Jira issue? ...as a possible work arround i would suggest creating a seperate "coordinator" core that is neither core1 nor core2 ... it doesn't have to have any docs in it, it just has to have consistent schemas with the other two cores. That way you can use a distinct <httpCaching /> settings on the coordinator core (perhaps never304="true" but with an explicit <cacheControl/> setting? ... or lastModifiedFrom="openTime" and then you could send an explicit "commit" to the (empty) coordinator core anytime you modify one of the shards. -Hoss
