SDN Controller Programming Guide

This method effectively unregisters the TimeStampedMetric from the metering framework so that the

framework no longer holds any references to it and thus no longer exposes it via JMX, summarizes

and persists its values, or does any other sort of processing on the TimeStampedMetric. Whether

theTimeStampedMetric is subsequently destroyed by the component or application that requested

its creation, it has disappeared from the framework's viewpoint.

Reregistering a TimeStampedMetric

If the controller bounces (goes down and then comes back up), all components and applications

that are using TimeStampedMetrics within the controller will be impacted as will the metering

framework; presumably they will initialize themselves in a predictable fashion, and if they register

theirTimeStampedMetrics following the bounce using the same MetricDescriptor information they

used before the bounce metering should recover fine; the same UIDs will be assigned to their

various TimeStampedMetrics that were assigned before the bounce and the net effect will be a

gap in the data on disk forTimeStampedMetrics whose values are persisted. But for application

components outside the controller that created and are updating TimeStampedMetricsthere may be

no indication that the controller has bounced - or gone down and stayed down - until the next time

they try to update TimeStampedMetricvalues.

Another possible, albeit unlikely, failure scenario arises should the metering service bounce while

other components and applications do not; this could happen if someone killed and restarted the

metering OSGi bundle. If this occurred, any components or applications that are

usingTimeStampedMetrics within the controller might be oblivious to the bounce as their references

to the TimeStampedMetrics they requested will still be present, but they will be effectively

unregistered from the metering framework when it reinitializes. The UIDs and MetricDescriptor data

will be preserved by the framework for TimeStampedMetrics that have their data persisted, but

they will appear to be TimeStampedMetrics that are no longer in use and just have persisted data

that is waiting to be aged out. Again, for application components outside the controller that

created and are updating TimeStampedMetricsthere may be no indication that the metering

service has bounced until the next time they try to update TimeStampedMetric values.

In order to be notified that the MetricService has gone down and/or come up, the OSGi

component that corresponds to a component or application using TimeStampedMetrics should

bind to the MetricService; then a method will be invoked when either occurrence happens to the

MetricService and the component or application can react accordingly. There is no change to

normal TimeStampedMetric creation required to handle the first failure scenario outlined above, as

all OSGi components within the controller will recover after a bounce just as they do whenever the

controller is initialized. But for the second failure scenario above, there is a way that a component

or application can react when notified that the metering service has initialized following a bounce

in which the component or application that owns TimeStampedMetrics has not bounced.

To handle such a scenario, components or applications should keep a Collection of the

TimeStampedMetrics that they allocate; each TimeStampedMetricthat is created on their behalf

should be added to the Collection. When the entire controller is initializing and the component or

application is notified that the MetricService is available this Collection will be empty or perhaps

not even exist yet, but in the second failure scenario above the Collection should contain

references to the pertinent TimeStampedMetrics when the MetricService becomes available. The

component or application can then iterate through the Collection, calling the following

MetricService method for each TimeStampedMetric.

Metric Registration API: