On Tue, May 16, 2017 at 3:05 PM, Robert Varga <n...@hq.sk> wrote: > 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'. > I think it's pretty clear from the documentation.
> > 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? > I think given the context API sets, even 1 second is a high value, so what kind of transaction can even take 5 seconds, let aside more than 5 second ? For example for my application I might even prefer to use 1 second, but there is no way to configure it as of now. So rather than assuming that no cohort will take more then 5 second, let user decide what value they want to use based on their use case. > > Bye, > Robert > > -- Thanks Anil
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
