[CONTROLLER-1245] Clustering : Make blocking datastore startup on the basis of valid SchemaContext smarter Created: 09/Apr/15 Updated: 13/Jun/15 Resolved: 13/Jun/15 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | mdsal |
| Affects Version/s: | Post-Helium |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Moiz Raja | Assignee: | Moiz Raja |
| 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: | 2970 |
| Priority: | Highest |
| Description |
|
If you try to add some data into InMemoryDataStore it must match the schema of that the InMemoryDataStore is aware of. If it does not then an exception may be thrown by IMDS. To ensure that we do not get into this situation on startup ShardManager waits to receive a schemaContext that is a superset of it's last known schemaContext and only when it receives such a schemaContext does it proceed with the creation of Shards. This poses a couple of problems, a. What if we never get a schema context which is a superset of the last known data. In this situation we will not load the Shards and we will have failures down the road. There are two potential fixes for this problem, a. IMDS allows us to store data without checking the schemaContext. If a method was provided on IMDS to turn of this checking that would do the trick. While (b) seems like the right thing to do there are a couple of problems with doing it, a. SchemaContext is not Serializable/Externalizable and it seems like it will take significant effort to make it so. |
| Comments |
| Comment by Moiz Raja [ 19/May/15 ] |
|
Making SchemaContext serializable is not a major issue. The Module(s) in a SchemaContext have the original source string. This source string could be serialized easily. On deserialization we could easily construct the schema context from the original source. Shard should do the serialization of SchemaContext to it's journal as stated in option (b) before. The serialization of the SchemaContext to the journal should only be done when the first transaction following a schema context change is received. This will reduce the total amount of schema context serialization that will need to be done. This will kind of ensure that on recovery we do not fail when data is applied to the datatree as the schema context will always match the data that will be subsequently written. The problem I see is with reading data. When data is added we ensure that it matches the current schema context. If later the schema context was to change the data needs to be cleaned up otherwise a read will fail because of data being returned for which there is no matching schema context. |
| Comment by Tom Pantelis [ 19/May/15 ] |
|
I don't think we need the complication and overhead of storing the SchemaContext in the journal. For data where the schema is gone on startup, we don't want it in the IMDS b/c no one can query it. I think we should be able to fairly easily prune data nodes whose schema is no longer available. In the future we'll want to handle migrating the data to a new schema. That seems easier to me than trying to deal with SchemaContext serialization and the many updates on startup. We also get many updates on shutdown as each schema is unloaded - we would actually lose most if not all the schemas in the last update before shutting down. We'd also have to deal with snapshots as they delete the journal prior to the snapshot which would also delete the persisted SchemaContext. I think trying to persist SchemaContext would be complicated and problematic. |
| Comment by Tom Pantelis [ 21/May/15 ] |
|
Submitted https://git.opendaylight.org/gerrit/#/c/20895/ to fix the RESOLVED bundle tracking. |
| Comment by Tom Pantelis [ 21/May/15 ] |
|
Submitted https://git.opendaylight.org/gerrit/#/c/20901/ to remove persisting of schema context modules in the ShardManager. |
| Comment by Moiz Raja [ 21/May/15 ] |
|
The second commit appears to be a draft |
| Comment by Tom Pantelis [ 21/May/15 ] |
|
It is - I was waiting for the first one to be merged first. I will publish soon... (In reply to Moiz Raja from comment #5) |
| Comment by Moiz Raja [ 27/May/15 ] |
|
https://git.opendaylight.org/gerrit/#/c/21018/ |
| Comment by Tom Pantelis [ 31/May/15 ] |
|
Also https://git.opendaylight.org/gerrit/#/c/20901/. The final price is to utilize the exception added in yangtools. |
| Comment by Moiz Raja [ 04/Jun/15 ] |
| Comment by Moiz Raja [ 12/Jun/15 ] |
|
This bug is not fully fixed. |
| Comment by Moiz Raja [ 12/Jun/15 ] |
|
https://git.opendaylight.org/gerrit/#/c/22429/ The above patch addresses to fix the problem with recovery but also uncovers a problem with the data tree. |