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

Version 1 Current »

References

CPS-1361 - Getting issue details... STATUS


Brief

After registering cmHandles through /ncmpInventory/v1/ch API and monitoring the cps.data-updated-events topic, the generated event is getting larger by each new cmHandle. After several thousand cmHandles, this causes org.apache.kafka.common.errors.RecordTooLargeException to be thrown and event publishing fails. Side effect is that CPS starts to consume CPU constantly and service performance degrades for subsequent cmHandle registrations.

The number of cmHandles after which the issue occurs depends on when the message size hits the limit of the producer's message.max.bytes configuration (1MB by default).

What is trying to be achieved:

Current Output

{
"schema": "urn:cps:org.onap.cps:data-updated-event-schema:v1",
"id": "55bcae1d-91cf-4864-bc81-5d3fc2fa3b8d",
"source": "urn:cps:org.onap.cps",
"type": "org.onap.cps.data-updated-event",
"content":

Unknown macro: { "observedTimestamp"}

}

Desired output

{
"schema": "urn:cps:org.onap.cps:data-updated-event-schema:v1",
"id": "55bcae1d-91cf-4864-bc81-5d3fc2fa3b8d",
"source": "urn:cps:org.onap.cps",
"type": "org.onap.cps.data-updated-event",
"content":

Unknown macro: { "observedTimestamp"}

}

Resolution


Currently the code is behaving as expected so the solution will require a change in behaviour. The event payload carries the whole data tree as it is designed to contain the details of the Anchor. 

The solution will require only the affected cmhandles to be included in the event however it should also maintain current behaviour for other use cases. The current POC proposal can be seen below

https://gerrit.onap.org/r/c/cps/+/132305




  • No labels