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/MDSAL-86 mdsal <p>We create an instance of this class for each RPC registration, which means we need to dynamically create a SchemaPath on each invocation.</p> <p>That schema path is used for lookup in the codec tree cache, which is lazily instantiated. Since we are using a different SchemaPath object on each lookup, equals() part of the cache lookup strays away from the identity comparison, leading to lost performance.</p> <p>Break up the Adapter such that we maintain a per-method registration, which retains the registration SchemaPath. This will result in the lookup not allocating any objects and keeping on the identity path.</p> <p>Operating System: All<br/> Platform: All</p> MDSAL-86

Split up BindingDOMRpcImplementationAdapter

Improvement Medium Resolved Done Robert Varga Robert Varga pt Thu, 28 May 2015 12:08:27 +0000 Mon, 28 Nov 2022 18:24:39 +0000 Fri, 25 Nov 2022 01:10:25 +0000 11.0.0 Binding runtime 0 4 <p>We will need to implement BindingCodecTree.getSubtreeCodec(SchemaNodeIdentifier), so that we can efficiently lookup RPC input/output as well as notifications. Once we have that, we can properly bind methods to their SchemaContext counterparts without having to go through the codec.</p> <p>This should result in a BindingDOMRpcProviderServiceAdapter having a</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> Cache&lt;<span class="code-object">Class</span>&lt;? <span class="code-keyword">extends</span> RpcService&gt;, RpcServiceClassContext&gt; rpcServiceClasses; </pre> </div></div> <p>populated lazily as services are registered. Furthermore RpcServiceClassContext should have the basic shape of:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">final</span> <span class="code-keyword">class </span>RpcServiceClassContext <span class="code-keyword">implements</span> Immutable { <span class="code-keyword">final</span> ImmutableMap&lt;SchemaNodeIdentifier, RpcServiceMethodContext&gt; methods; }</pre> </div></div> <p>Note the methods map should not be used during invocation, only during decomposition of the RPC implementation – the keys are input to DOMRpcIdentifier and values form the invocation context, which in turn looks like this:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">final</span> <span class="code-keyword">class </span>RpcServiceMethodContext <span class="code-keyword">implements</span> Immutable { <span class="code-keyword">final</span> QName inputQName; <span class="code-comment">// Note: shared between all MethodContexts in a ClassContext </span> <span class="code-keyword">final</span> BindingNormalizedNodeCodec inputCodec; <span class="code-keyword">final</span> BindingNormalizedNodeCodec outputCodec; <span class="code-keyword">final</span> RpcMethodInvoker methodInvoker; } </pre> </div></div> <p>now when an implementation is registered, we look up the RpcServiceClassContext and for each RpcServiceMethodContext we create a DOMRpcImplementation, which has a pointer to the MethodContext and the RpcService object being registered.</p> <p>During invocation we use the inputCodec/inputQName combo to create the DataObject representation of input and pass that to the methodInvoker. We then return a variation on LazyDOMRpcResultFuture, which actually holds a reference to outputCodec directly, not going through the codec/codecRegistry.</p> <p>Note that since the DOMRpcImplementations created are not multiplexing but rather each points to a single YANG RPC, we do not consult DOMRpcImplementation.invokeRpc()'s first argument.</p> <p>The problem with this decomposition, though, is that the resulting object would not be registered atomically – for that we will need an atomic</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> DOMRpcProviderService.registerRpcImplementations(Map&lt;DOMRpcIdentifier, DOMRpcImplementation&gt;);</pre> </div></div> <p>method and have that implemented.</p> <p>I think we can address this cleanly by removing the Adapter, as we won't be needing it.</p> <p>Actually, we can implement an efficient split by reusing the DOM and Binding infra existing for single-RPC invocations.</p> Relates MDSAL-796 Development External issue ID 3416 External issue URL Issue Type ODL SR Target Milestone Rank 0|i02w87: