Hi, I don't *think* there is any DIH request queuing going on - each is triggered by the DIH request. You need to queue them yourself if your app/data is such that running multiple imports/deltas causes problems with either hardware or data.
Otis ---- Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch Lucene ecosystem search :: http://search-lucene.com/ ----- Original Message ---- > From: Allistair Crossley <a...@roxxor.co.uk> > To: solr-user@lucene.apache.org > Sent: Wed, October 6, 2010 10:49:49 AM > Subject: Strategy for re-indexing > > Hi, > > I was interested in gaining some insight into how you guys schedule updates >for your Solr index (I have a single index). > > Right now during development I have added deltaQuery specifications to data >import entities to control the number of rows being queries on re-indexes. > > However in terms of *when* to reindex we have a lot going on in the system - >there are 4 sub-systems: custom application data, a CMS, a forum and a blog. >It's all being indexed and at any given time there will be users and >administrators all updating various parts of the sub-systems. > > > For the time being during development I have been issuing reindexes to the >data import handler on each CRUD on any given sub-system. This has been >working >fine to be honest. It does need to be as immediate as possible - a scheduled >update won't work for us. Even every 10 minutes is probably not fast enough. > > > So I wonder what others do. Is anyone else in a similar situation? > > And what happens if 4 users generate 4 different requests to the data import >handler to update for different types of data? The DIH will be running >already >let's say for request 1, then request 2 comes in - is it rejected? Or is it >queued? > > I need it to be queued and serviced because the request 1 re-index may have >already run its queries but missed the data added by the user for request 2. >Same then goes for the requests 3 and 4. > > > Thanks for your consideration, > > Allistair
