NealSun96 opened a new issue #841: Fix TrieRoutingData initialization and usage 
in MetadataStoreDirectory
URL: https://github.com/apache/helix/issues/841
 
 
   Previously in `ZkMetadataStoreDirectory`, instances of `TrieRoutingData` are 
always created after fetching the raw routing data using `ZkRoutingDataReader`. 
However, this has caused uncaught exceptions and other unspecified behaviors: 
`TrieRoutingData` will throw exceptions when given an empty map, however it is 
valid to get an empty map as the "raw routing data". Similarly as an example, 
we have allowed users to create zkRealms without creating associated sharding 
keys, which will cause exceptions when `ZkMetadataStoreDirectory` attempts to 
construct `TrieRoutingData` during data callback. Across the API 
specifications, we allowed a lot of operations that will fail `TrieRoutingData` 
constructions. 
   In light of this issue, we reconsidered the definition of "routing data 
validity" and we concluded that the raw routing data is allowed to be "invalid" 
(or incomplete), such as having a zkRealm without sharding keys, but 
`TrieRoutingData` is not allowed to be invalid - if it exists it's valid. As a 
result, we no longer always create `TrieRoutingData` after fetching raw routing 
data from ZooKeeper; they are decoupled. We allow namespaces to not have 
`TrieRoutingData` in `ZkMetadataStoreDirectory`. When calls are made that 
depend on `TrieRoutingData` but `TrieRoutingData` doesn't exist, we fail the 
call and notify the users that the current routing data is invalid. 
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to