[MDSAL-356] Fail earlier/faster/more clearly in case of modules with same name but different namespaces (and more checks?) Created: 21/Jun/18  Updated: 09/Apr/20

Status: Confirmed
Project: mdsal
Component/s: DOM runtime
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Medium
Reporter: Michael Vorburger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive karaf.log.zip    
Issue Links:
Relates
relates to SRVUTILS-1 rename YANG modules for SRM in servic... Done

 Description   

As raised on https://lists.opendaylight.org/pipermail/mdsal-dev/2018-June/001709.html :

The new ODL "serviceutils"  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:

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)

This is seen on https://jenkins.opendaylight.org/releng/job/distribution-check-fluorine/69/consoleFull, 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 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.

I've found a few issues from the past which seem possibly related to this:

 Comments   
Comment by Michael Vorburger [ 21/Jun/18 ]

I'll be raising a series of patches on https://git.opendaylight.org/gerrit/#/q/topic:MDSAL-354 which add more detailed logging in case of the error above.

Comment by Michael Vorburger [ 26/Jun/18 ]

Attached karaf.log.zip from https://lists.opendaylight.org/pipermail/controller-dev/2018-June/014497.html

Comment by Michael Vorburger [ 26/Jun/18 ]

I wonder if this is "just an impact", or could be the cause of the problems seen here - tpantelis perhaps you have any thoughts?

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.Thread.run(Thread.java:748) [?:?]
Comment by Michael Vorburger [ 26/Jun/18 ]

https://git.opendaylight.org/gerrit/#/c/73442/ 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.

Comment by Michael Vorburger [ 26/Jun/18 ]

OK, forget about integration/distribution... we can now reproduce this more easily - credit for the original idea goes to k.faseela who said on IRC that "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)", so I just added

    <dependency>
      <groupId>org.opendaylight.genius</groupId>
      <artifactId>odl-genius-srm</artifactId>
      <version>0.5.0-SNAPSHOT</version>
      <type>xml</type>
      <classifier>features</classifier>
    </dependency>

to serviceutils/features/odl-serviceutils-srm 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.

Comment by Michael Vorburger [ 26/Jun/18 ] 
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: interface 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) ~[?:?] 
Comment by Robert Varga [ 26/Jun/18 ]

As per https://tools.ietf.org/html/rfc7950#section-6.2.1 this is not an infrastructure problem. Module names must be unique. New names should include 'odl-' prefix, i.e. odl-srm-rpcs.

Comment by Michael Vorburger [ 26/Jun/18 ]

rovarga thanks for the clarification! k.faseela 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 https://lists.opendaylight.org/pipermail/mdsal-dev/2018-June/001725.html - would that be in yangtools?

Comment by Michael Vorburger [ 26/Jun/18 ]

> possible future Enhancement as outlined on

rovarga on IRC suggested this would have to be in mdsal-binding-dom-codec, and said:

(02:35:25 CEST) rovarga_: and it certainly is not an error to add multiple sources of the same model from yangtools' perspective
(02:38:10 CEST) vorburger: rovarga_: then what between https://github.com/opendaylight/genius/blob/5ad5d6bf9b17bb66ddb35e56e895d220795febc6/srm/api/src/main/yang/srm-rpcs.yang and https://github.com/opendaylight/serviceutils/blob/7162c48453a8c369ca7abbe3e83ae269977c9f96/srm/api/src/main/yang/srm-rpcs.yang 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?
(02:38:56 CEST) rovarga_: namespace for starters
(02:39:09 CEST) rovarga_: if revisions match, the complete semantic content
rohitsakala rovarga_
(02:39:52 CEST) rovarga_: (as opposed to literal content)

Comment by Michael Vorburger [ 26/Jun/18 ]

SRVUTILS-1 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.

Generated at Wed Feb 07 20:09:36 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.