References:

Spring '@Schedule' annotation

Using Spring '@Schedule' annotation, it is possible to schedule tasks that allow us to create a watchdog.

To enable spring boot to recognise and support scheduled tasks, it is necessary to add '@EnableScheduling' as shown below

Then, all methods that are annotated with '@Schedule' are recognised as a scheduled task depending on the configuration placed.

For the example below, the method 'sayHello()' is configured to run at a fixed rate of 1000ms. Fixed-rate will invoke the task at every n millisecond and is useful for independent tasks.

Scheduled tasks can be configured in the following ways :


DescriptionNotes
Fixed-rate
  • will execute task every specified millisecond
  • recommended for independent tasks
  • The next one won't start until the previous is done as they do not run in parallel

Fixed-delay
  • the executed task runs after the specified delay time
  • useful to ensure that there's only one executed task running at a time
  • recommended for dependent tasks

Initial delay

  • initial delay can be used with fixed-rate and fixed delay
  • it is the specified delay time wherein the task will be first executed
  • recommended to use when the application needs to first complete a setup before executing scheduled tasks

Cron


Querying state and timestamp 

In NCMP, dataspace and anchor is hardcoded 

namevalue
NCMP_DATASPACE_NAMENCMP-Admin
NCMP_DMI_REGISTRY_ANCHORncmp-dmi-registry
NCMP_DMI_REGISTRY_PARENT/dmi-registry


NCMP flow



Diagram 7


CPS path

The following tree diagram reflects the new dmi-registry yang model which will have the leaves 'state' and 'lock-reason'

Based on the CPS path formats (see https://docs.onap.org/projects/onap-cps/en/latest/cps-path.html) and the above tree diagrams, it was tested that the following path allows accessing the 'state' leaf node attribute:

Wherein the test values are:

    INSERT INTO FRAGMENT (ID, DATASPACE_ID, ANCHOR_ID, PARENT_ID, XPATH, ATTRIBUTES) VALUES
    (21, 1001, 1003, 1, '/dmi-registry', '{}'),
    (22, 1001, 1003, 9, '/dmi-registry/cm-handles[@id="PNFDemo"]', '{"id": "PNFDemo","dmi-service-name": "http://172.18.192.19:8783","dmi-data-service-name": "","dmi-model-service-name": ""}'),
    (23, 1001, 1003, 10,'/dmi-registry/cm-handles[@id="sampleId_1"]/additional-properties[@name="Book1"]', '{"name": "Book1", "value": "Romance Book"}'),
    (24, 1001, 1003, 9, '/dmi-registry/cm-handles[@id="sampleId_2"]', '{"id": "sampleId_2","dmi-service-name": "http://172.18.192.19:8783","state": "ADVISED"}'),
    (25, 1001, 1003, 9, '/dmi-registry/cm-handles[@id="sampleId_3"]', '{"id": "sampleId_3","dmi-service-name": "http://172.18.192.19:8783","state": "READY"}'),
    (26, 1001, 1003, 9, '/dmi-registry/cm-handles[@id="sampleId_4"]', '{"id": "sampleId_4","dmi-service-name": "http://172.18.192.19:8783","state": "ADVISED"}');

and the groovy test:

  @Sql([CLEAR_DATA, SET_DATA])
    def 'SAMPLE: Cps Path query to determine nodes with #scenario'() {
        when: 'a query is executed to get a data node by the given cps path'
        def result = objectUnderTest.queryDataNodes(DATASPACE_NAME, ANCHOR_FOR_SHOP_EXAMPLE, cpsPath, OMIT_DESCENDANTS)
        then: 'the correct number of data nodes are retrieved'
        result.size() == expectedXPaths.size()
        and: 'xpaths of the retrieved data nodes are as expected'
        for (int i = 0; i < result.size(); i++) {
            assert result[i].getXpath() == expectedXPaths[i]
        }
        where: 'the following data is used'
        scenario                   | cpsPath                                               || expectedXPaths
        '     '                    | '//cm-handles[@id="PNFDemo"]'                      || ['/dmi-registry/cm-handles[@id="PNFDemo"]']
        '     '                    | '//additional-properties[@value="Romance Book"]'   || ['/dmi-registry/cm-handles[@id="sampleId_1"]/additional-properties[@name="Book1"]']
        '     '                    | '//cm-handles[@state="ADVISED"]'                   || ['/dmi-registry/cm-handles[@id="sampleId_2"]','/dmi-registry/cm-handles[@id="sampleId_4"]']


DB locking

Database locking is performed after retrieving a node with the status of 'ADVISED'. This is to ensure that we prevent multiple instances of NCMP accessing a cm handle, this will also ensure that model syncs will not fail.

For more information on issues and decisions for DB locking, please see CPS-898 Create method to lock and unlock an anchor. 

  • No labels