Siegfried's comment is spot-on. Your filter query will not be re-used unless you submit two within the same millisecond! Here's more than you want to know about why.
http://searchhub.org/2012/02/23/date-math-now-and-filter-queries/ Best, Erick On Sun, May 25, 2014 at 10:56 AM, Siegfried Goeschl <sgoes...@gmx.at> wrote: > Hi folks, > > I think that the timestamp should be rounded down to a minute (or whatever) > to avoid trashing the filter query cache > > Cheers, > > Siegfried Goeschl > > On 25 May 2014, at 18:19, Steve McKay <st...@b.abbies.us> wrote: > >> Solr can add the filter for you: >> >> <requestHandler ...> >> <lst name="appends"> >> <str name="fq">timestamp:[* TO NOW-30SECOND]</str> >> </lst> >> </requestHandler> >> >> Increasing soft commit frequency isn't a bad idea, though. I'd probably do >> both. :) >> >> On May 23, 2014, at 6:51 PM, Michael Tracey <mtra...@biblio.com> wrote: >> >>> Hey all, >>> >>> I've got a number of nodes (Solr 4.4 Cloud) that I'm balancing with HaProxy >>> for queries. I'm indexing pretty much constantly, and have autoCommit and >>> autoSoftCommit on for Near Realtime Searching. All works nicely, except >>> that occasionally the auto-commit cycles are far enough off that one node >>> will return a document that another node doesn't. I don't want to have to >>> add something like this: timestamp:[* TO NOW-30MINUTE] to every query to >>> make sure that all the nodes have the record. Ideas? autoSoftCommit more >>> often? >>> >>> <autoCommit> >>> <maxDocs>100000</maxDocs> >>> <maxTime>7200000</maxTime> >>> <openSearcher>false</openSearcher> >>> </autoCommit> >>> >>> <autoSoftCommit> >>> <maxTime>30000</maxTime> >>> <maxDocs>5000</maxDocs> >>> </autoSoftCommit> >>> >>> Thanks, >>> >>> M. >> >
