On Mon, Dec 11, 2017 at 5:28 PM, Michael Vorburger <[email protected]> wrote:
> On Mon, Dec 11, 2017 at 8:36 PM, Tom Pantelis <[email protected]> > wrote: > >> On Mon, Dec 11, 2017 at 2:22 PM, Michael Vorburger <[email protected]> >> wrote: >> >>> Controllers, >>> >>> looking at https://jira.opendaylight.org/browse/NETVIRT-916, half of >>> the solution could be https://git.opendaylight.org/gerrit/#/c/66355/, >>> and am wondering if the other half of the solution is in controller's >>> ConcurrentDOMDataBroker: >>> >>> Is it right for it to LOG.warn a ConflictingModificationAppliedException? >>> Shouldn't that be left to the caller? Given that a failed Future is >>> returned, why log it from controller? Because people could just ignore the >>> Future? IMHO we now have a solution for this via the @CheckReturnValue >>> which error-prone (and maybe FindBugs, I'm not sure) can verify. Only for >>> projects enforcing such tools, of course. And only if we >>> add @CheckReturnValue to WriteTransaction submit() which I think we should >>> - OK for everyone? >>> >>> Similarly for an OptimisticLockFailedException (not the case in >>> NETVIRT-916, but just while we're at it) - that IMHO also should be be WARN >>> logged by controller (if it currently is; dunno). >>> >> >> Yeah I think that was put in case callers ignore the returned Future. I >> agree it mostly adds a lot of extra noise - I'm fine with lowering it to >> DEBUG. >> > > OK, great; then I've just so proposed this in a few changes on > https://git.opendaylight.org/gerrit/#/q/topic:CONTROLLER-1802 > > What's may be still TBD is the equivalent of https://git.opendaylight.org/ > gerrit/#/c/66362/ in mdsal, or is there no such thing? > ConcurrentDOMDataBroker is CDS's broker implementation (sal-distributed-datastore) and is the one used in production.
_______________________________________________ controller-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/controller-dev
