Thanks Yonik, glad that it is not an issue on Trunk. I'll see if our group is interested in updating now to take advantage of this. In the mean time we just issue a commit after we do deletes and that seems to be a sufficient workaround.
On Thu, Jul 5, 2012 at 6:05 PM, Yonik Seeley <yo...@lucidimagination.com> wrote: > On Thu, Jul 5, 2012 at 5:12 PM, Jamie Johnson <jej2...@gmail.com> wrote: >> Ok, so some more context, hopefully this is useful. >> >> I didn't think this was a SolrCloud issue but it appears to be. I >> have a simple 2 shard set up, I add 1 document which goes to shard 1. >> I then issue a delete to shard 2. The delete gets there and I see the >> commit eventually being run in the log, but it doesn't appear to be >> being distributed to shard 1. If I manually call a server.commit() >> the item is removed. > > OK, I just verified this for trunk / 4x. It appears to work fine now, > but I'm not exactly sure why it may not with the snapshot you have > (much has changed since). > > I followed the solr cloud wiki except that the path now needs to have > collection1 in it, and I set the number of shards to 1 (with 2 > replicas). I indexed the example docs, then queried both shards to > verify the doc existed on both. Then I deleted the doc through the > non-leader via: > curl "http://localhost:7574/solr/update?commitWithin=60000"; -H > 'Content-type:application/json' -d '{"delete": { "id":"SOLR1000"}}' > > This was to test both the forwarding to the leader and the fowarding > from the leader to the replica. > After 60 seconds, the document was gone on both replicas. > > aside: If you use deleteByQuery, be aware that full distributed > indexing support was just finished yesterday by SOLR-3559 > > -Yonik > http://lucidimagination.com
