Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Related Jira(s):

CPS-1415 - Getting issue details... STATUS


Description

  1. Define scenarios which cause a CM Handle to go stale
  2. Implement changes to support tracking of CM Handle Freshness/Staleness

What might trigger a cmhandle to go to STALE?

  1. dmi plugin identifies that the device is no longer contactable
  2. dmi plugin identifies that an underlying device manager managing the device (node) is out of sync with the device itself. 

Scope

  1. Currently only supporting NONE and COMPLETE. PARTIAL and POOR may be added later as below.

Changes to DMI Registry Model

We will not be making changes to the DMI Registry Model, Public Properties of the CMHandle will be used where needed.

Triggers of CMHandle trust level change

DMI Availability

Trust level defined by NCMP's communication with a DMI Plugin.

10 minute limit should be configurable with 10 as default.

Hazelcast Map?

DMI AvailabilityTrust Level
Available / Unavailable for less than 10 minutes COMPLETE
Unavailable for over 10 minutesNONE

Last Data Update

Trust Level defined by Client's use of NCMP endpoints to change data related to a CMHandle (passthrough only).

10 minute limit should be configurable with 10 as default.

Stored in public properties

Elapsed time since last data change for CM HandleTrust Level
Less than 10 minutesCOMPLETE
Over 10 minutesNONE

Open Question: External Notifications NCMP is subscribed to should effect this?

Device Heart Beat

Assumed functionality is that this will be defined by the DMI Plugin as NCMP does not communicate with device directly

Interface in NCMP for DMI Plugin to be able to tell when device HB has been lost.

10 minute limit should be configurable with 10 as default.

Elapsed time since last DMI Plugin lost Device HBTrust Level
Less than 10 minutesCOMPLETE
Over 10 minutesNONE

Schema Model Mismatch

Occurs when data change has been called for a CMHandle and the data change does not fit the defined schema for that CMHandle Anchor (passthrough only).

If this error occurs Trust Level is set to NONE. 


IssueDescription

CM Handle sync

Assumption is that at CMHandle registration the CMHandle is originally persisted as NONE trustLevel

As CMHandle moves to READY, NONE moves to COMPLETE, Else stays as NONE

The DataSync does not effect this as is related to cache.



Last Data Update

What Data?

What about changes to the CMHandle Properties etc?



Last Data UpdateExternal Notifications NCMP is subscribed to should effect this?

  • No labels