https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-936 controller <p>In ShardManager's FindPrimary, it attemps to return a shard replica , which may or may not be the leader of the shard. </p> <p>The logic to return it from the local exists, but to find the actual leader of the shard is missing.</p> <p>For a 3 node cluster, this might not be introducing a significant dent in the performance, as each node has atleast one replica of each shard.</p> <p>But when we move to more fine-grained sharding, the number of hops will be 1 more.</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-936

Clustering:ShardManager does not return the leader of the Shard in FindPrimary

Bug Resolved Done Tom Pantelis Kamal Rameshan Wed, 15 Oct 2014 17:19:40 +0000 Thu, 26 Mar 2015 21:42:40 +0000 Thu, 26 Mar 2015 21:42:40 +0000 Post-Helium mdsal 0 3 <p>(Proposed Fix - Implemented &amp; Testing)</p> <p>The Shard’s Leader (aka “primary”) is reported to each Shard while adjusting its behavior (changing leadership) and to report in the ShardStats MBean for JMX access. The ShardManager needs some way to identify the Shard leader without coupling the Shard and ShardMananger or being part of the election process that the RaftActor is running. </p> <p>My proposed fix that I've implemented and am testing is to allow the Shard to register Leader changed listeners and report a Leader change event to those registered listeners. In this case the ShardManager will register a Leader change listener with its local shard upon that Shard’s creation (if it has one). When ShardManager#findPrimary is called it may know who the Leader is and can report that. </p> <p>There will still be cases where it doesn’t know who the Leader is, e.g. it doesn’t have a local shard for this shard configuration or the information has not been reported yet. In those cases #findPrimary will function as it does today where from the local shard configuration file it knows which nodes in the system have shard replicas and it reports one of those as primary to allow them complete the findPrimary request. (Note: A Shard will forward any requests to the Leader if contacted, we are just trying to optimize how often the the Leader can be identified correctly.)</p> <p>In the case where we do not have a local shard how about forwarding the findprimary to a shardmanager on a node which we do know has a local shard?</p> <p>The ShardManager now listens for RoleChangedNotificatons so it knows the raft state of each shard. I have also added a LeaderStateChange notification with <a href="https://git.opendaylight.org/gerrit/#/c/16328/1" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/16328/1</a> so the ShardManager knows the current leaderId.</p> <p>With these changes and <a href="https://git.opendaylight.org/gerrit/#/c/16164/14" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/16164/14</a>, the ShardManager now returns the actual shard leader actor path from FindPrimary. Also if there is no leader yet, it waits a period of time (shardInitializationTimeout) for a leader to be elected before returning a response. If there is no leader after the timeout, it returns a NoShardLeaderException failure response.</p> <p>With <a href="https://git.opendaylight.org/gerrit/#/c/16194/7" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/16194/7</a>, if there's no local shard it forwards the FindPrimary message to another remote ShardManager.</p> Development External issue ID 2194 External issue URL Issue Type ODL SR Target Milestone Rank 0|i02nh3: