Hi Hoss! > 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.
I agree with you here. As all request handlers point to the same index we only need to address the "cache worthyness" of the index. I see no use case for having one request handler cache for 5 hours and another request handler for 10 hours. For update request handlers we might follow another strategy and emit "no-cache" headers like the SOLR-505 patch is suggesting. > 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: Full ACK. We simply behave spec. compliant here. > 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. True. But we should be aware of that many people don't know the semantic difference between GET and POST. IMHO making Solr a bit more fool proof is always a good thing to have. Some might switch from GET to POST because Tomcat's default config only allows request headers of 4KB (including GET parameters) but POSTs of 2MB. But we should not break the W3C specs for that. > 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. The patch for SOLR-505 lets the handler decide if the response is worth caching or not. It depends not on the URL-path of the handler. CU Thomas
