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-356 mdsal <p>As raised on <a href="https://lists.opendaylight.org/pipermail/mdsal-dev/2018-June/001709.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/mdsal-dev/2018-June/001709.html</a> :</p> <p>The new ODL <em>"serviceutils"</em>  project is hitting a weird issue in the integration/distribution karaf run, which makes me suspect there may be a concurrency related issue in BindingToNormalizedNodeCodec, or code used by it:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>2018-06-20T18:35:42,573 | ERROR | SystemReadyService-0 | TestBundleDiag | 350 - org.opendaylight.infrautils.ready-impl - 1.4.0.SNAPSHOT | NOK org.opendaylight.serviceutils.srm-impl:0.2.0.SNAPSHOT: OSGi state = Active, Karaf bundleState = Failure, due to: Declarative ServicesBlueprint6/20/18 6:35 PMException: Unable to initialize bean .component-2org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to initialize bean .component-2 at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:738) (...) Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException: Error processing "rpc-implementation" for class org.opendaylight.serviceutils.srm.impl.SrmRpcProvider at org.opendaylight.controller.blueprint.ext.RpcImplementationBean.init(RpcImplementationBean.java:69) (...) Caused by: java.lang.IllegalStateException: Schema for interface org.opendaylight.yang.gen.v1.urn.opendaylight.serviceutils.srm.rpcs.rev170711.SrmRpcsService is not available. at com.google.common.base.Preconditions.checkState(Preconditions.java:585) at org.opendaylight.mdsal.binding.dom.adapter.BindingToNormalizedNodeCodec.getModuleBlocking(BindingToNormalizedNodeCodec.java:303)</pre> </div></div> <p>This is seen on <a href="https://jenkins.opendaylight.org/releng/job/distribution-check-fluorine/69/consoleFull" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/job/distribution-check-fluorine/69/consoleFull</a>, but several people have locally done a "mvn clean install" on integration/distribution master, and not been able to locally reproduce above... so it would seem that under some... timing <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/help_16.png" height="16" width="16" align="absmiddle" alt="" border="0"/> condition only hit on the distribution running on Jenkins, the Schema for that RPC interface defined in the new serviceutils/srm/api cannot (yet?) be found.</p> <p>I've found a few issues from the past which seem possibly related to this:</p> <ul> <li><a href="https://jira.opendaylight.org/browse/YANGTOOLS-827" title="NullPointerException " class="issue-link" data-issue-key="YANGTOOLS-827"><del>YANGTOOLS-827</del></a></li> <li><a href="https://jira.opendaylight.org/browse/CONTROLLER-1427" title="Exception in config-pusher when installing odl-openflowplugin-all (and -li)" class="issue-link" data-issue-key="CONTROLLER-1427"><del>CONTROLLER-1427</del></a></li> </ul> MDSAL-356

Fail earlier/faster/more clearly in case of modules with same name but different namespaces (and more checks?)

Improvement Medium Confirmed Unresolved Unassigned Michael Vorburger Thu, 21 Jun 2018 14:17:15 +0000 Thu, 9 Apr 2020 20:26:44 +0000 DOM runtime 0 2 <p>I'll be raising a series of patches on <a href="https://git.opendaylight.org/gerrit/#/q/topic:MDSAL-354" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/q/topic:MDSAL-354</a> which add more detailed logging in case of the error above.</p> <p>Attached karaf.log.zip from <a href="https://lists.opendaylight.org/pipermail/controller-dev/2018-June/014497.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/controller-dev/2018-June/014497.html</a></p> <p>I wonder if this is "just an impact", or could be the cause of the problems seen here - <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a> perhaps you have any thoughts?</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">2018-06-26T14:56:07,529 | ERROR | Framework Event Dispatcher: org.eclipse.osgi.internal.framework.EquinoxEventPublisher@748741cb | srm-shell | 518 - org.opendaylight.serviceutils.srm-shell - 0.2.0.SNAPSHOT | FrameworkEvent ERROR - org.opendaylight.serviceutils.srm-shell java.util.NoSuchElementException: No value present at java.util.Optional.get(Optional.java:135) ~[?:?] at org.opendaylight.controller.blueprint.ext.RpcUtil.decomposeRpcService(RpcUtil.java:39) ~[?:?] at org.opendaylight.controller.blueprint.ext.AbstractInvokableServiceMetadata.retrievedSchemaContext(AbstractInvokableServiceMetadata.java:91) ~[?:?] at org.opendaylight.controller.blueprint.ext.AbstractInvokableServiceMetadata.onSchemaService(AbstractInvokableServiceMetadata.java:85) ~[?:?] at org.opendaylight.controller.blueprint.ext.StaticServiceReferenceRecipe.retrack(StaticServiceReferenceRecipe.java:75) ~[?:?] at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.start(AbstractServiceReferenceRecipe.java:140) ~[18:org.apache.aries.blueprint.core:1.8.3] at org.opendaylight.controller.blueprint.ext.StaticServiceReferenceRecipe.startTracking(StaticServiceReferenceRecipe.java:46) ~[276:org.opendaylight.controller.blueprint:0.9.0.SNAPSHOT] at org.opendaylight.controller.blueprint.ext.AbstractDependentComponentFactoryMetadata.retrieveService(AbstractDependentComponentFactoryMetadata.java:120) ~[276:org.opendaylight.controller.blueprint:0.9.0.SNAPSHOT] at org.opendaylight.controller.blueprint.ext.AbstractDependentComponentFactoryMetadata.retrieveService(AbstractDependentComponentFactoryMetadata.java:105) ~[276:org.opendaylight.controller.blueprint:0.9.0.SNAPSHOT] at org.opendaylight.controller.blueprint.ext.AbstractInvokableServiceMetadata.onRpcRegistry(AbstractInvokableServiceMetadata.java:78) ~[276:org.opendaylight.controller.blueprint:0.9.0.SNAPSHOT] at org.opendaylight.controller.blueprint.ext.StaticServiceReferenceRecipe.retrack(StaticServiceReferenceRecipe.java:75) [276:org.opendaylight.controller.blueprint:0.9.0.SNAPSHOT] at org.opendaylight.controller.blueprint.ext.StaticServiceReferenceRecipe.track(StaticServiceReferenceRecipe.java:52) [276:org.opendaylight.controller.blueprint:0.9.0.SNAPSHOT] at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceAdded(AbstractServiceReferenceRecipe.java:362) [18:org.apache.aries.blueprint.core:1.8.3] at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceChanged(AbstractServiceReferenceRecipe.java:341) [18:org.apache.aries.blueprint.core:1.8.3] at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109) [?:?] at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:920) [?:?] at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?] at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) [?:?] at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862) [?:?] at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801) [?:?] at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127) [?:?] at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:225) [?:?] at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:469) [?:?] at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:472) [18:org.apache.aries.blueprint.core:1.8.3] at org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:193) [18:org.apache.aries.blueprint.core:1.8.3] at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:726) [18:org.apache.aries.blueprint.core:1.8.3] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:412) [18:org.apache.aries.blueprint.core:1.8.3] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:275) [18:org.apache.aries.blueprint.core:1.8.3] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?] at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106) [18:org.apache.aries.blueprint.core:1.8.3] at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) [18:org.apache.aries.blueprint.core:1.8.3] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?] at java.lang.<span class="code-object">Thread</span>.run(<span class="code-object">Thread</span>.java:748) [?:?]</pre> </div></div> <p><a href="https://git.opendaylight.org/gerrit/#/c/73442/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/73442/</a> will provide more details to help understand this - but I expect that it will only re-confirm that there is some weird problem related to the SrmRpcsService, with an IllegalArgumentException with details, instead of this NoSuchElementException.</p> <p>OK, forget about integration/distribution... we can now reproduce this more easily - credit for the original idea goes to <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=k.faseela" class="user-hover" rel="k.faseela">k.faseela</a> who said on IRC that <em>"the failure happens only with odl-integration-all, and not even with odl-genius-rest.. I was doubting whether it is failing only when two srm-rpcs are there (even though the namepsace is diferent)"</em>, so I just added</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> &lt;dependency&gt; &lt;groupId&gt;org.opendaylight.genius&lt;/groupId&gt; &lt;artifactId&gt;odl-genius-srm&lt;/artifactId&gt; &lt;version&gt;0.5.0-SNAPSHOT&lt;/version&gt; &lt;type&gt;xml&lt;/type&gt; &lt;classifier&gt;features&lt;/classifier&gt; &lt;/dependency&gt;</pre> </div></div> <p>to <tt>serviceutils/features/odl-serviceutils-srm</tt> and, bingo - the SFT of odl-serviceutils-srm now fails with above! This increasingly points to us having identified a bug in a corner case in mdsal - there must be something somewhere not handling the namespace of RPCs correctly.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">2018-06-26T13:46:19,967 | ERROR | Framework Event Dispatcher: org.eclipse.osgi.internal.framework.EquinoxEventPublisher@2f8f5f62 | srm-shell | 199 - org.opendaylight.serviceutils.srm-shell - 0.2.0.SNAPSHOT | FrameworkEvent ERROR - org.opendaylight.serviceutil s.srm-shell java.lang.IllegalArgumentException: Module not found in SchemaContext: QNameModule{ns=urn:opendaylight:serviceutils:srm:rpcs, rev=2017-07-11} ; service: <span class="code-keyword">interface</span> org.opendaylight.yang.gen.v1.urn.opendaylight.serviceutils.srm.rpcs.rev170711.SrmRpcsService at org.opendaylight.controller.blueprint.ext.RpcUtil.lambda$decomposeRpcService$0(RpcUtil.java:39) ~[?:?] at java.util.Optional.orElseThrow(Optional.java:290) ~[?:?] at org.opendaylight.controller.blueprint.ext.RpcUtil.decomposeRpcService(RpcUtil.java:39) ~[?:?] </pre> </div></div> <p>As per <a href="https://tools.ietf.org/html/rfc7950#section-6.2.1" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc7950#section-6.2.1</a> this is not an infrastructure problem. Module names must be unique. New names should include 'odl-' prefix, i.e. odl-srm-rpcs.</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a> thanks for the clarification! <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=k.faseela" class="user-hover" rel="k.faseela">k.faseela</a> will do renaming (in the new serviceutils, not the existing genius; they want to remove that one, after having migrated to serviceutils FYI). But instad of moving this JIRA from mdsal to genius project, could we have this for a possible future Enhancement as outlined on <a href="https://lists.opendaylight.org/pipermail/mdsal-dev/2018-June/001725.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/mdsal-dev/2018-June/001725.html</a> - would that be in yangtools?</p> <p>&gt; possible future Enhancement as outlined on </p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a> on IRC suggested this would have to be in mdsal-binding-dom-codec, and said:</p> <blockquote><p>(02:35:25 CEST) rovarga_: and it certainly is not an error to add multiple sources of the same model from yangtools' perspective<br/> (02:38:10 CEST) vorburger: rovarga_: then what between <a href="https://github.com/opendaylight/genius/blob/5ad5d6bf9b17bb66ddb35e56e895d220795febc6/srm/api/src/main/yang/srm-rpcs.yang" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/opendaylight/genius/blob/5ad5d6bf9b17bb66ddb35e56e895d220795febc6/srm/api/src/main/yang/srm-rpcs.yang</a> and <a href="https://github.com/opendaylight/serviceutils/blob/7162c48453a8c369ca7abbe3e83ae269977c9f96/srm/api/src/main/yang/srm-rpcs.yang" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/opendaylight/serviceutils/blob/7162c48453a8c369ca7abbe3e83ae269977c9f96/srm/api/src/main/yang/srm-rpcs.yang</a> is "conflicting" and what really should be detected? If it's no simply multiple sources of the same model, is it multiple source of a module with a different namespace?<br/> (02:38:56 CEST) rovarga_: namespace for starters<br/> (02:39:09 CEST) rovarga_: if revisions match, the complete semantic content<br/> rohitsakala rovarga_ <br/> (02:39:52 CEST) rovarga_: (as opposed to literal content)</p></blockquote> <p><a href="https://jira.opendaylight.org/browse/SRVUTILS-1" title="rename YANG modules for SRM in serviceutils which are forked from genius to avoid packaging modules with conflicting names" class="issue-link" data-issue-key="SRVUTILS-1"><del>SRVUTILS-1</del></a> will fix the YANG moddule name clash problem between SRM in serviceutils and genius; this issue is about a possible Enhancement in mdsal to make this kind of problem easier to understand should it happen again in the future.</p> Relates SRVUTILS-1 Development Rank 0|i03fsv: