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 >
