Currently ringpop can be configured to compare the hashring when a request is forwarded and drop the request if the hashrings are inconsistent. This causes a lot of requests that are actually forwarded to the correct node to fail, resulting in a lot of timeout and errors on rolling restarts.
The PR will add the possibility to loosen the requirement from ring consistency to key consistency eg. if the key from the forwarded request is believed to be owned by the receiving node based on a hashring lookup it will execute the request. When this happen both the forwarder and the receiver of the forwarded request agree on the key ownership for the key to the receiving end.
This showed a huge improvement in performance of a ringpop application during a rolling restart.
Currently ringpop can be configured to compare the hashring when a request is forwarded and drop the request if the hashrings are inconsistent. This causes a lot of requests that are actually forwarded to the correct node to fail, resulting in a lot of timeout and errors on rolling restarts.
The PR will add the possibility to loosen the requirement from ring consistency to key consistency eg. if the key from the forwarded request is believed to be owned by the receiving node based on a hashring lookup it will execute the request. When this happen both the forwarder and the receiver of the forwarded request agree on the key ownership for the key to the receiving end.
This showed a huge improvement in performance of a ringpop application during a rolling restart.