[CONTROLLER-1497] Improve DataTreeModification pruning on recovery Created: 09/Mar/16 Updated: 13/Apr/16 Resolved: 13/Apr/16 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | clustering |
| Affects Version/s: | Beryllium |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Tom Pantelis | Assignee: | Tom Pantelis |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 5485 |
| Priority: | Normal |
| Description |
|
The PruningDataTreeModification prunes nodes based on namespace. This works fine when an entire schema namespace is removed. But it fails if a schema element is removed but the namespace is still valid. Eg, given the following schema: module test { container container2 { If container1 is removed, on persistence recovery, the PruningDataTreeModification tries to merge the node but it fails with a SchemaValidationFailedException. It then checks if the namespace(s) in the path are valid. If it isn't, it discards it with an "Invalid node identifier ..." message. But in this case the namespace is still valid so it assumes a child node was invalid and tries to prune the node tree. However the NormalizedNodePruner also checks namespaces so nothing is pruned and tries to merge it again which fails again with SchemaValidationFailedException. This gets propagated to akka and recovery fails rendering the Shard unusable. What we need to do is check if the QNames in the path and nodes are valid, same as the data tree does. I prototyped a solution for this. Another issue I found is that merge validates the structure but write doesn't. The SchemaValidationFailedException occurs later on ready. So we need to also catch SchemaValidationFailedException on ready and re-apply the modification tree with pruning. I think it would be ideal and more efficient to do the pruning in the InMemoryDataTreeModification, i.e. a pruning version of it. But I think that would be part of a bigger effort for schema migration support. |
| Comments |
| Comment by Tom Pantelis [ 10/Mar/16 ] |