[CONTROLLER-1832] Transaction Trace tool wiring creates second BindingToNormalizedNodeCodec Created: 31/May/18  Updated: 07/Jun/18  Resolved: 04/Jun/18

Status: Resolved
Project: controller
Component/s: None
Affects Version/s: None
Fix Version/s: Fluorine, Oxygen SR3

Type: Bug Priority: Medium
Reporter: Michael Vorburger 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 NETVIRT-1089 Add trace:transactions to suite teard... In Progress
blocks CONTROLLER-1831 Utilities to bootstrap CDS in a stand... Resolved
Relates
relates to MDSAL-213 Serializing DataObject to JSON causes... Resolved
relates to CONTROLLER-1834 Transaction Trace tool wiring for pin... Resolved

 Description   

while working on CONTROLLER-1831 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 tpantelis and I yesterday discussed we'll remove as part of CONTROLLER-1831.

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 MDSAL-213 !?

I'll raise a Gerrit with a propose change to do this differently ASAP.



 Comments   
Comment by Michael Vorburger [ 31/May/18 ]

raised c/72530, currently in review. Will cherry-pick to stable/* if OK & merged.

Comment by Michael Vorburger [ 31/May/18 ]

tpantelis just merged c/72530. Before cherry-picking it to stable/* I am curious if jluhrsen can confirm that with this gone in on master, he does not see MDSAL-213 anymore in his NETVIRT-1089 exploration.

Comment by Michael Vorburger [ 04/Jun/18 ]

see also CONTROLLER-1834

Comment by Jamo Luhrsen [ 04/Jun/18 ]

we did have an example of this frozen class issue in one job but I just retried it and did not see the frozen class

running it again , just in case this is not 100% reproducible.

Comment by Michael Vorburger [ 06/Jun/18 ]

There is no more frozen even in the run again. 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 c/72715.

Comment by Michael Vorburger [ 07/Jun/18 ]

We unfortunately missed the train for Oxygen SR2 for this one, so SR3.

Generated at Wed Feb 07 19:56:33 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.