> that is odd... > > can you let us know exactly what verison of Solr/Lucne you are using (if > it's not an official release, can you let us know exactly what the version > details on the admin info page say, i'm curious about the svn revision)
Of course, that's the stable 1.4.1. > > can you also please let us know what types of queries you are generating? > ... that's the toString output of a query and it's not entirely clear what > the original looked like. If you can recognize what the original query > was, it would also be helpful to know if you can consistently reproduce > this error on autowarming after executing that query (or queries like it > with a slightly differnet date value) It's extremely difficult to reproduce. It happened on a multinode system that's being prepared for production. It has been under heavy load for a long time already, updates and queries. It is continuously being updated with real user input and receives real user queries from a source that's being updated from logs. Solr is about to replace an existing search solution. It is impossible to reproduce because of these uncontrollable variables, i tried but failed. The error, however, did occur at least a couple of times after i started this thread. It hasn't reappeared after i reduced precision from milliseconds to an hour, see my other thread for more information: http://web.archiveorange.com/archive/v/AAfXfFuqjPhU4tdq53Tv > > One of the things that particularly boggles me is this... > > : org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java > : :545) > : > : at > : > : org.apache.solr.search.SolrIndexSearcher.cacheDocSet(SolrIndexSearcher.ja > : va:520) > > [...] > > : Well, i use Dismax' bf parameter to boost very recent documents. I'm not > : using the queryResultCache or documentCache, only filterCache and Lucene > : fieldCache. > > ... that cache warming stack trace seems to be coming from filterCache, > but that contradicts your statement that you don't use the filterCache. > independent of your comments, that's an odd looking query to be cached in > the filter cache anyway, since it includes a mandatory matchalldocs > clause, and seems to only exist for boosting on that function. But i am using filterCache and fieldCache (forgot to mention the obvious fieldValueCache as well). If you have any methods that may help to reproduce i'm of course willing to take the time and see if i can. It may prove really hard because several weird errors were not reproduceable in a more controlled but similar environment (load and config) and i can't mess with the soon-to-be production cluster. Thanks! > > > -Hoss
