https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/GENIUS-122 genius <p>Now that the registrar is being used in more general code flows there really needs to be a safety mechanism in the form of a timeout just in case the specific expected event never happens.</p> GENIUS-122

DataTreeEventCallbackRegistrar really needs a timeout

New Feature Medium Resolved Done Michael Vorburger Josh Hershberg Thu, 12 Apr 2018 12:56:38 +0000 Tue, 29 May 2018 15:03:18 +0000 Mon, 28 May 2018 11:06:20 +0000 Oxygen-SR2 Fluorine 0 2 <p>Here's my design idea. I think there should be new versions of the onX methods that accept two more params: </p> <p>onX (..., long timeout, Runnable onTimeout) ...Runnable is what you use if you want to pass a lambda that takes no params and returns nothing, right?</p> <p>I think we should consider deprecating the old versions eventually. </p> <p> </p> <p>Actually, scratch that. It should take a Consumer&lt;InstanceIdentifier&gt; which should be the instance identifier the registration was on so that if there were two registrations from the same code for different objects in the md-sal they can be differentiated by the timeout routine.</p> <p>That makes sense to me, with a Consumer&lt;InstanceIdentifier&lt;T&gt;&gt; ... I'm a little undecided how we'll related this to NextAction UNREGISTER <b>VS</b> CALL_AGAIN - does a timeout make sense for both? Let me see if I can put together a Gerrit with a (first version of) this, and we we can review the concrete code.</p> <p>actually it really should be a  Consumer&lt;DataTreeIdentifier&lt;T&gt;&gt; not a  Consumer&lt;InstanceIdentifier&lt;T&gt;&gt; </p> <p>c/70985 has (an initial first version of) this now.. still Draft; let the build situation get sorted, and I'll undraft it, for build. If that gets +1, I'll need to still extend it to cover all methods, and perhaps somehow take this idea from <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=jhershbe" class="user-hover" rel="jhershbe">jhershbe</a> into account in a follow-up change improvement:</p> <blockquote><p>I think that you need to make sure that the timeout call can not happen while the handler function is running. Like, if a notification happens and just then the timer fires, the timeout event should wait until after the DTCL finishes calling the supplied handler function. </p></blockquote> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=vorburger" class="user-hover" rel="vorburger">vorburger</a> getting the concurrency correct for this is actually not trivial; further to above, what if e.g. the DTCL were to fire while we've just called the timeout callback (but may not yet be finished with it), that's not yet handled (as of Change Set 2), and probably more such cases.</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a> may help us getting this right and if time will follow-up on c/70985 with edge case tests and needed fixes.</p> <p>Done now. <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=k.faseela" class="user-hover" rel="k.faseela">k.faseela</a> has also back-ported this from master (Fluorine) to stable Oxygen AFAIK.</p> Blocks GENIUS-119 Development Rank 0|i03da7: