Reference Guide

public interface MetricService {
public void removeMetric(TimeStampedMetric toRemove);
}
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
the TimeStampedMetric 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
their TimeStampedMetrics 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 for TimeStampedMetrics whose values are persisted. But for application
components outside the controller that created and are updating TimeStampedMetrics there 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 using
TimeStampedMetrics 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 TimeStampedMetrics there 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
52