Depending on your application, it might be useful to take control of
the queueing yourself: it was for me!
I needed quick turnarounds for submitting a document to be indexed,
which Solr can't guarantee right now. To address it, I wrote a
persistent queueing server, accessed by XML-RPC, which has the benefit
of adding a low-cost layer of indirection between client-side and
server-side stuff, and properly serialises the order in which events
arrive.
James
On 27 Apr 2008, at 05:33, Phillip Farber wrote:
A while back Hoss described Solr queuing behavior:
> searches can go on happily while commits/adds are happening, and
> multiple adds can happen in parallel, ... but all adds block while a
> commit is taking place. i just give all of clients that update the
> index a really large timeout value (ie: 60 seconds or so) and don't
> worry about queing up indexing requests.
I am worried about those adds queuing up behind an ongoing commit
before being processed in parallel. What if a document is added
multiple times and each time it is added it has different field
values? You'd want the newest, last queued version of that document
to win, i.e. to be the version that represents the document in the
index. But processing in parallel suggests that the time order of
the adds of that document could be lost. Does Solr time stamp the
documents in the indexing queue to prevent an earlier queued version
of the document from being the last version indexed?
Thanks,
Phil
