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/CONTROLLER-1832 controller <p>while working on <a href="https://jira.opendaylight.org/browse/CONTROLLER-1831" title="Utilities to bootstrap CDS in a standalone environment (non-OSGi/Karaf)" class="issue-link" data-issue-key="CONTROLLER-1831"><del>CONTROLLER-1831</del></a> and reviewing blueprint wiring XML in controller, I realized that controller/opendaylight/md-sal/mdsal-trace/binding-impl/src/main/resources/org/opendaylight/blueprint/impl-blueprint.xml creates a 2nd BindingToNormalizedNodeCodec, in parallel to the original supposedly singleton one (from opendaylight/md-sal/sal-binding-broker/src/main/resources/org/opendaylight/blueprint/binding-broker.xml), via the BindingToNormalizedNodeCodecFactory, which <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a> and I yesterday discussed we'll remove as part of <a href="https://jira.opendaylight.org/browse/CONTROLLER-1831" title="Utilities to bootstrap CDS in a standalone environment (non-OSGi/Karaf)" class="issue-link" data-issue-key="CONTROLLER-1831"><del>CONTROLLER-1831</del></a>.</p> <p>Having x2 separate BindingToNormalizedNodeCodec, with separate classloading, when the Transaction Trace tool is installed (only), smells like asking for trouble... in fact, I'm wondering if perhaps this could be causing <a href="https://jira.opendaylight.org/browse/MDSAL-213" title="Serializing DataObject to JSON causes frozen class exception" class="issue-link" data-issue-key="MDSAL-213"><del>MDSAL-213</del></a> !?</p> <p>I'll raise a Gerrit with a propose change to do this differently ASAP.</p> CONTROLLER-1832

Transaction Trace tool wiring creates second BindingToNormalizedNodeCodec

Bug Medium Resolved Done Michael Vorburger Michael Vorburger Thu, 31 May 2018 13:03:43 +0000 Thu, 7 Jun 2018 16:17:59 +0000 Mon, 4 Jun 2018 11:51:20 +0000 Fluorine Oxygen SR3 0 2 <p>raised <a href="https://git.opendaylight.org/gerrit/#/c/72530/" class="external-link" target="_blank" rel="nofollow noopener">c/72530</a>, currently in review. Will cherry-pick to stable/* if OK &amp; merged.</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a> just merged c/72530. Before cherry-picking it to stable/* I am curious if <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=jluhrsen" class="user-hover" rel="jluhrsen">jluhrsen</a> can confirm that with this gone in on master, he does not see <a href="https://jira.opendaylight.org/browse/MDSAL-213" title="Serializing DataObject to JSON causes frozen class exception" class="issue-link" data-issue-key="MDSAL-213"><del>MDSAL-213</del></a> anymore in his <a href="https://jira.opendaylight.org/browse/NETVIRT-1089" title="Add trace:transactions to suite teardowns" class="issue-link" data-issue-key="NETVIRT-1089">NETVIRT-1089</a> exploration.</p> <p>see also <a href="https://jira.opendaylight.org/browse/CONTROLLER-1834" title="Transaction Trace tool wiring for ping-pong DataBroker is wrong" class="issue-link" data-issue-key="CONTROLLER-1834"><del>CONTROLLER-1834</del></a></p> <p>we did have an example of this frozen class issue in <a href="https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/builder-copy-sandbox-logs/79/jamo-mdsaltrace-netvirt-csit-1node-openstack-queens-upstream-stateful-oxygen/1/odl_1/odl1_karaf.log.gz" class="external-link" target="_blank" rel="nofollow noopener">one job </a> but I just <a href="https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/builder-copy-sandbox-logs/89/jamo-traces-netvirt-csit-1node-openstack-queens-upstream-stateful-fluorine/1/" class="external-link" target="_blank" rel="nofollow noopener">retried it</a> and did not see the frozen class</p> <p><a href="https://jenkins.opendaylight.org/sandbox/job/jamo-traces-netvirt-csit-1node-openstack-queens-upstream-stateful-fluorine/3/" class="external-link" target="_blank" rel="nofollow noopener">running it again </a>, just in case this is not 100% reproducible.</p> <p>There is <a href="https://logs.opendaylight.org/sandbox/vex-yul-odl-jenkins-2/jamo-traces-netvirt-csit-1node-openstack-queens-upstream-stateful-fluorine/3/odl_1/odl1_karaf.log.gz" class="external-link" target="_blank" rel="nofollow noopener">no more frozen even in the run again</a>. While that is of course not conclusive proof that c/72530 fixed it, it still seems to me that cherry-pick to stable/oxygen at worst couldn't hurt anyone, and at best may actually fix this; so <a href="https://git.opendaylight.org/gerrit/#/c/72715/" class="external-link" target="_blank" rel="nofollow noopener">c/72715</a>.</p> <p>We unfortunately missed the train for Oxygen SR2 for this one, so SR3.</p> Blocks NETVIRT-1089 CONTROLLER-1831 Relates MDSAL-213 CONTROLLER-1834 Development Rank 0|i03f2f: