Hmmm, this would surprise me unless the add and delete were going to
separate machines. how are you sending them? SolrJ? and in a single
server.add(doclist) format or with individual adds?

Individual commands being sent can come 'round out of sequence, that's what
the whole optimistic locking bit is about.

I guess my other question is what's your evidence that this isn't working?
Are you just querying your index and looking at the results? If so, are you
sure you're waiting until after any autocommit intervals?

Best
Erick


On Tue, Feb 19, 2013 at 2:23 PM, Vinay Pothnis <vinay.poth...@gmail.com>wrote:

> Hello,
>
> I have the following set up:
>
> * solr cloud 4.1.0
> * 2 shards with embedded zookeeper
> * plain http to communicate with solr
>
> I am testing a scenario where i am batching multiple commands and sending
> to solr. Since this is the solr cloud setup, I am always sending the
> updates to one of the nodes in the cloud.
>
> e.g.: http://localhost:8983/solr/sample/update
>
> *example set of commands:*
> {"add": {"doc":
> {"field-1":"1359591340025","field-2":1361301249330,"doc_id":"e.1.78"}
> },"add": {"doc":
> {"field-1":"1360089709282","field-2":1361301249377,"doc_id":"e.1.78"}
> },"delete": { "id": "e.1.78" }}
>
> When I include deletes and updates in the batch, sometimes, the order of
> the commands is not maintained.
>
> Specifically, if the document does not belong to the shard that I am
> communicating with (lets say shard-1), then shard-1 sends the commands to
> "shard-2". In this case, the "deletes" are sent first and then the updates.
> This changes the order that I originally sent.
>
> Any inputs on why the order is not maintained?
>
> Thanks!
> Vinay
>

Reply via email to