Thanks a lot for your quick response. I just created a bug [1] for tracking
this change
[1] https://bugs.opendaylight.org/show_bug.cgi?id=7469
From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: martes, 03 de enero de 2017 16:32
To: Diego Jesus Granados Lopez
Cc: controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] Use of DOMDataTreeCommitCohorts
The ConcurrentDOMDataBroker implements DOMDataTreeCommitCohortRegistry but it
does not advertise it from what I can see. Must've been an oversight. It either
needs to add it as an extension or, better yet, advertise the
DOMDataTreeCommitCohortRegistry interface in the OSGi service registry via
blueprint.
On Tue, Jan 3, 2017 at 9:27 AM, Diego Jesus Granados Lopez
mailto:diego.jesus.granados.lo...@ericsson.com>>
wrote:
Hi,
I’m trying to perform validation to datastore operations (they would be
unvaluable for preventing severe situations caused because of bad configuration
in SFC project). I found the fix to [1] which would be pretty much what I need,
but I’m struggling to find a way to use the proposed correction. Specifically,
from the DOMDataBroker that I’m provided via blueprint inyection, I’m unable to
access this cohorts API (specifically, I can create a DOMDataTreeCommitCohort,
but I’m unable to register it). I throughtfully read the thread [2] on
DOMDataBroker delegation / extension model, but still can’t understand how to
retrieve the ConcurrentDOMDataBroker that I could use in order to register my
cohort. From that thread, my understanding is that I shouldn’t try to cast the
DOMDataBroker directly to ConcurrentDOMDataBroker (this is correct, even though
toString() in the inyected DOMDataBroker instance returns “Clustered
ConcurrentDOMDataBroker”, direct cast fails), but to access extensions in
order to use more specific / improved behaviors. But examining all supported
extensions, the list only contains an instance of
org.opendaylight.controller.md.sal.dom.api.DOMDataTreeChangeService, which
neither can be used to register the cohort / access the ConcurrentDOMDataBroker
underneath.
So the question is: could you provide an example on how could a
DOMDataTreeCommitCohort be registered by an application, provided a
DOMDataBroker instance is available?
PS. Just in case the question raises, I’m aware of the performance implications
introduced by the use of synchronous DOMDataTreeCommitCohort validations. Let’s
assume we’d be using this for cases on which the ability to guarantee data
model consistency is more valuable than the performance price to pay.
Best regards,
Diego
[1] https://bugs.opendaylight.org/show_bug.cgi?id=1435
[2]
https://lists.opendaylight.org/pipermail/controller-dev/2016-August/012505.html
___
controller-dev mailing list
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/controller-dev
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev