It's because of how we currently handle batched requests - we buffer a different number of deletes thqn we do adds and flush them separately - mainly because the size of each is likely to be so different, at one point we would buffer a lot more deletes.
So currently, you want to break these up to multiple requests if order is critical. Might make a JIRA issue to look at this again - I think at this point we are buffering the same number of each any way - we should probably just treat them the same, and put them in the same buffer in the right order. Even then though, I don't think SolrJ update requests order deletes and adds in the same request either, so that would also need to be addressed. Pretty sure solrj will do the adds then the deletes. - Mark On 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
