Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Fetch the PCI_optimization requests (from DB) for which OOF has been triggered, and corresponding ‘cluster’ details
  2. For each ‘cluster’ for which OOF has been triggered, check if the Nodeid of the Cell Ci or at least one cell in its NbrList matches with any cell in the ‘cluster’
  3. If there is a match, then the request has to be buffered, along with the cluster indication (cluster id??), else the notification has to be processed.

...

else

Buffer the notification (along with the cluster id)

fi

2.1.4. OOF Response Handling

Upon invocation of API by OOF for PCI result pass it to the relevant child thread(s) (by request id <-> thread mapping). Store the OOF results in database along with the timestamp.

2.1.5. Status update from Child thread (PCI recommendations sent to Policy)

Upon trigger from

...

Child thread that OOF

...

results have been sent to Policy

...

(as a )    Check for DMaaP message), check if there are any buffered notifications to be handled for that cluster (using cluster id)

If yes

Then

Forward it to the child thread

Else

Kill the child thread

...

the cluster handled by the Child thread. If there are any such buffered notifications, forward them to the Child thread, otherwise kill the Child thread and clean up resources associated with the cluster handled by the Child thread.

2.1.6. Terminating

Upon receiving a terminate request clean up all resources.

...

If ‘process’

...