bug: Incorrect VLAN port URIs right after provisioning

[xi-yang]

When SENSE-O pushes a delta with a SwithcingSubnet and included VLAN ports, the URI for a VLAN port would look like this.

urn:ogf:network:es.net:2013::kans-cr6:lag-30:+:conn+8462e1cb-4b0c-4e26-ae79-91d8d6906b78:vt+l2-policy-Connection_1:vlanport+3137

This normally works. But in one test, the RM modeled the URI as

urn:ogf:network:es.net:2013::kans-cr6:lag-30:+:vlan+3137:cid+16880eff-de8e-43c7-ab00-9eed7629a8d5

This indicated that some correlation metadata in the RM db had been broken. More importantly, this time, it happened right after the provisioning. No RM reboot like before. Note that the SwitchingSubnet URI still looked correct. It was just the VLAN port URIs.

A few tests before this worked fine. I did observe some slowness of OSCARS (or RM) in canceling a circuit before this. So maybe that timing was a trigger.

Also note that when debugging this, try some restart of the RM or OSCARS and see if we can reliably retain the resource URI metadata.

[jmacauley]

This looks like a timing issue. The second STP format is generated when a newly discovered connection is not in the metadata store. This would indicate a problem between the writing of the metadata for a connection and the asynchronous reservation response for the connection. We will investigate the timing of the storage and if any database caching issues may be occurring between threads.