On 16/05/17 20:40, Anil Vishnoi wrote: > Tom, > > I think it depends on the use case for which user is using cohort. For > example If user have a use case where it sends very few rest request to > the controller from northbound side but want to make sure it runs all > the possible checks against that data to make sure that it can avoid any > wrong configuration (according to the use case and not really as per > yang schema). In general i agree with you that anything that takes more > then 5 second, it's better to probably write that logic in the > application rather than in the cohort, but we don't know all the use > cases people use it for. So i think having a config knob (with default > value to 5 second or lower) will give user an option to change it > (increase or decrease) as per their usecase.
Note that this fires for any change in the registered subtree and no other transactions involving that shard can make forward progress until the cohort finishes preCommit(). This API is very strict and should be used only as a last resort at this point. As the associated documentation states very explictly, any bugs in a user of the API has cluster-wide consequences which manifest as 'CDS is broken'. That implies you should not be talking to the data store and expect it to respond in the cohort -- which begs the question: what sort of validation takes more than 5 seconds? Bye, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
