Bug 4105: Move Configuration classes to config package Change-Id: I863600727f5171eb0db3591a541848aa877a68de Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Bug 4105: Add method to get all unique member names Added a method to Configuration to get all unique members names configured for all shards. Change-Id: I09993541ad7e5963e9eef9cb58b4376daa8f09e8 Signed-off-by: Tom Pantelis <tpanteli@brocade.com> (cherry picked from commit c3ba770fd6e9ba6e6227717bdba11ccc9f468f05)
BUG 1712 - Distributed DataStore does not work properly with Transaction Chains The fix is as follows, 1. When Creating a trasaction chain create a unique identifier for the transaction chain using the member name and the current timestamp 2. When a transaction is created using the transaction chain pass the transaction chain id along to the remote shard 3. If the remote shard receives a transaction with a valid transaction chain (one which is not empty) then it creates a new transaction chain if one does not exist. If one does exist then the Shard just creates a new transaction on the existing transaction chain. This way if a single transaction chai was used to create transactions on multiple different shards the a transaction chain would be created on each one of those shards. 4. When a transaction chain is closed a Close Transaction Chain message is broadcast to all the Shards in the system. If those shards had a transaction chain with the specified id then the transaction chain would be closed. The sender does not care about receiving a response 5. When a state change occurs on a Shard we check if the Shard is not a leader. If that is the case we automatically close all existing transaction chains on that shard and clear the map which tracks the transaction chains for that shard Change-Id: I6bcfb9de3d0ec666e4152afb69c702dda4f38171 Signed-off-by: Moiz Raja <moraja@cisco.com>
Add replication capability to Shard This commit integrates the distributed data store with our Raft implementation. Shard now extends RaftActor which provides it the replication capabilities required. Other notable changes are, - The FindPrimary algorithm has been changed to find the first replica for a shard. The shard then forwards requests to create a transaction or transaction chain to the leader - Changed the package name for Raft internal messages from "internal" to "base" to be more BND tool friendly - Fix some issues with Serialization of Raft messages - Create a NoOpTransaction when no Primary can be found. The commit for this transaction will always fail. The NoOpTransaction returns absent for reads in all cases. - Add PeerAddressResolution capability to Raft. What this basically does is given a static configuration where a shard has 'n' peers, you can pass the names of those peers to the shard and resolve their addresses at a later time. This allows the Shard to ensure consensus even in a situation where it is the first one to come up but it's peers are still not running Change-Id: I3087deb5eb4418cd629a707ba14f43858db1f463 Signed-off-by: Moiz Raja <moraja@cisco.com>
Modify the FindPrimary implementation so that it works correctly with a configuration Change-Id: Ie41b688adf54de06332bbe5add7aba8107eb4264 Signed-off-by: Moiz Raja <moraja@cisco.com>
Implementation of ModuleShardStrategy ModuleShardStrategy finds a shard based on a module name only. This will allow it partition a single large DOM tree into multiple shards based on configuration Change-Id: I6e287fc48a08da58d261e80b59419d4311164aa3 Signed-off-by: Moiz Raja <moraja@cisco.com>
Initial support for multiple-shards Change-Id: Ic58d2dc9198b88c689143a9d85a612016b6bfa22 Signed-off-by: Moiz Raja <moraja@cisco.com>