{"push_id":2591955578,"size":1,"distinct_size":1,"ref":"refs/heads/watson","head":"9787a93683afeb89e7a602795c218113907b6be0","before":"6235a18e0523bbffd8ac01639f6e8ed2c4ad5a36","commits":[{"sha":"9787a93683afeb89e7a602795c218113907b6be0","author":{"name":"Aliaksey Artamonau","email":"3c875bcfb3adf2a65b2ae7686ca921e6c9433147@gmail.com"},"message":"MB-29819 Terminate all replications before disabling old master.\n\nMy original thinking was that there was no need to synchronously\nterminate replications to the vbuckets that are not in new vbucket\nchain since we won't be creating any new replications for the affected\nvbucket to or from these nodes. Hence we won't be affected by the\noriginal race (when we disable the old master vbucket, stream_end is\nsent to the replica vbuckets; ns_server sees the stream_end and\nassumes that replication is gone, but it can actually still exist in\nep-engine for a tiny bit of time). The problem though is that whenever\njanitor_agent makes any changes to the replications, it will try to\nrecreate all replications that are supposed to exist. So if\njanitor_agent on one of the old replica nodes receives an unrelated\nrequest before the vbucket move is completed (that's when we clean up\nthe old replications), it will recreate the replication in\nquestion. Then if it just so happens that the request is received\nafter ns_server processed the stream_end, but before ep-engine got a\nchance to do the same, then the request will fail with \"stream already\nexists\" error. And that will lead to the rebalance failure.\n\nChange-Id: I49bceb9bdbe0985fd885acdbffe05104ecf87944\nReviewed-on: http://review.couchbase.org/94686\nTested-by: Aliaksey Artamonau <aliaksey.artamonau@couchbase.com>\nWell-Formed: Build Bot <build@couchbase.com>\nReviewed-by: Artem Stemkovski <artem@couchbase.com>","distinct":true,"url":"https://api.github.com/repos/couchbase/ns_server/commits/9787a93683afeb89e7a602795c218113907b6be0"}]}
{"actor":{"display_login":"ns-codereview"}}