[INFRAUTILS-58] JobCoordinator does not retain Thread Context Class Loader Created: 15/Oct/18  Updated: 05/Nov/18  Resolved: 05/Nov/18

Status: Resolved
Project: infrautils
Component/s: jobcoordinator
Affects Version/s: None
Fix Version/s: Neon

Type: Bug Priority: Medium
Reporter: Robert Varga Assignee: Michael Vorburger
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks GENIUS-223 GENIUS Version Bump Patches Ready Resolved
Relates
relates to TSC-179 Genius CSI broken by ietf-interface r... Resolved

 Description   

As shown in https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/genius-csit-1node-upstream-all-neon/68/odl_1/odl1_karaf.log.gz , indirecting access to the datastore via JobCoordinator means that the binding code executes in a different class loder - hence augmentations cannot be located:

2018-10-14T13:08:13,950 | ERROR | jobcoordinator-main-task-2 | JobCoordinatorImpl               | 335 - org.opendaylight.infrautils.jobcoordinator-impl - 1.5.0.SNAPSHOT | Direct Exception (not failed Future) when executing job, won't even retry: JobEntry{key='default-transport-zone', mainWorker=org.opendaylight.genius.itm.confighelpers.ItmMonitorIntervalWorker@51560836, rollbackWorker=null, retryCount=0/3, futures=null}
org.opendaylight.mdsal.binding.dom.codec.impl.IncorrectNestingException: Class interface org.opendaylight.yang.gen.v1.urn.opendaylight.genius.interfacemanager.rev160406.IfTunnel is not valid child of interface org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.interfaces.rev140508.interfaces.Interface
	at org.opendaylight.mdsal.binding.dom.codec.impl.IncorrectNestingException.create(IncorrectNestingException.java:25) ~[?:?]
	at org.opendaylight.mdsal.binding.dom.codec.impl.DataContainerCodecContext.childNonNull(DataContainerCodecContext.java:165) ~[?:?]
	at org.opendaylight.mdsal.binding.dom.codec.impl.DataObjectCodecContext.bindingPathArgumentChild(DataObjectCodecContext.java:185) ~[?:?]
	at org.opendaylight.mdsal.binding.dom.codec.impl.BindingCodecContext.getCodecContextNode(BindingCodecContext.java:133) ~[?:?]
	at org.opendaylight.mdsal.binding.dom.codec.impl.BindingCodecContext.newWriter(BindingCodecContext.java:110) ~[?:?]
	at org.opendaylight.mdsal.binding.dom.codec.impl.BindingNormalizedNodeCodecRegistry.toNormalizedNode(BindingNormalizedNodeCodecRegistry.java:112) ~[?:?]
	at org.opendaylight.mdsal.binding.dom.adapter.BindingToNormalizedNodeCodec.toNormalizedNode(BindingToNormalizedNodeCodec.java:162) ~[?:?]
	at org.opendaylight.controller.md.sal.binding.impl.AbstractWriteTransaction.merge(AbstractWriteTransaction.java:51) ~[?:?]
	at org.opendaylight.controller.md.sal.binding.impl.BindingDOMWriteTransactionAdapter.merge(BindingDOMWriteTransactionAdapter.java:40) ~[?:?]
	at org.opendaylight.genius.itm.confighelpers.ItmMonitorIntervalWorker.toggle(ItmMonitorIntervalWorker.java:68) ~[?:?]
	at org.opendaylight.genius.itm.confighelpers.ItmMonitorIntervalWorker.toggleTunnelMonitoring(ItmMonitorIntervalWorker.java:59) ~[?:?]
	at org.opendaylight.genius.itm.confighelpers.ItmMonitorIntervalWorker.call(ItmMonitorIntervalWorker.java:46) ~[?:?]
	at org.opendaylight.genius.itm.confighelpers.ItmMonitorIntervalWorker.call(ItmMonitorIntervalWorker.java:26) ~[?:?]
	at org.opendaylight.infrautils.jobcoordinator.internal.JobCoordinatorImpl$MainTask.runWithUncheckedExceptionLogging(JobCoordinatorImpl.java:404) [335:org.opendaylight.infrautils.jobcoordinator-impl:1.5.0.SNAPSHOT]
	at org.opendaylight.infrautils.utils.concurrent.LoggingUncaughtThreadDeathContextRunnable.run(LoggingUncaughtThreadDeathContextRunnable.java:60) [341:org.opendaylight.infrautils.util:1.5.0.SNAPSHOT]
	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402) [?:?]
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) [?:?]
	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056) [?:?]
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692) [?:?]
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157) [?:?]

 Comments   
Comment by Robert Varga [ 15/Oct/18 ]

I believe the TCCL should be captured when the job is enqueued and the ClassLoader should be installed as TCCL while the job is executing. Otherwise there is a major difference between when the job's code is executed without JobCoordinator and without it.

Comment by Michael Vorburger [ 31/Oct/18 ]

rovarga thanks for filing this. I'm trying to assess the priority of this vs. others tasks I have pendinging.. k.faseela just raised it on IRC, and I'm trying to understand if this issue a Blocker for CSIT following the Neon MRI version bump? Or does MDSAL-379 work around this, so no rush? I'll see if I can propose a fix... what you propose (above) doesn't seem terribly difficult to implement? /Cc FYI skitt.

Comment by Michael Vorburger [ 31/Oct/18 ]

rovarga (or tpantelis or skitt) so apparently, as k.faseela has just reported on IRC, even with my change c/77377/1 which does make the JobCoordinator retain the TCCL, the IncorrectNestingException still happens in CSIT ... did I just make a silly mistake in 77377, or do we have a bigger issue here re.  class loading in OSGi ? 

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