Hi Anil,
I completely agree with your comments. It would be great if the cohort timeout
value is configurable as per the UCs requisites.
Regards
-Satish
From: controller-dev-boun...@lists.opendaylight.org
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Anil Vishnoi
Sent:
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
yeah I'm not saying it shouldn't be configurable - unfortunately, right now
it's hard-coded.
On Tue, May 16, 2017 at 2:40 PM, 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
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
yes - it is currently hard-coded to 5 sec. It was not intended for cohorts
to take 5-20 sec to validate. Cohorts are supposed to be performant as the
API javadocs stress, especially since they're currently invoked
synchronously and thus block the Shard.
On Mon, May 15, 2017 at 10:20 PM, Anil
Thanks Anil. I was able to change the timeout value through the code and its
working fine.
Regards
-Satish
From: Anil Vishnoi [mailto:vishnoia...@gmail.com]
Sent: Tuesday, May 16, 2017 7:50 AM
To: Michael Vorburger
Cc: Satish Dutt ;