Page History

...

Collection<DataNode> queryDataNodes(String dataspaceName, String anchorName, String cpsPath, FetchDescendantsOption fetchDescendantsOption);
Collection<DataNode> getDataNodes(String dataspaceName, String anchorName, String xpath, FetchDescendantsOption fetchDescendantsOption);
Collection<DataNode> getDataNodesForMultipleXpaths(String dataspaceName, String anchorName, Collection<String> xpaths, FetchDescendantsOption fetchDescendantsOption);

Current Issues contributing to high memory usage

...

Additionally, internal APIs in CPS Reference Implementation (cps-ri) use List<FragmentEntity>, e.g.

List<FragmentEntity> findByAnchorAndCpsPath(AnchorEntity anchorEntity, CpsPathQuery cpsPathQuery);

When a CPS path query is run, this will result in a List<FragmentEntity> which needs to be converted to a Collection<DataNode>. Thus, the Fragment Entities cannot be garbage collected until the list is converted to Data Nodes. This doubles the memory usage.

Additionally, NCMP uses CPS path queries, e.g. to find CM handles in a given state. NCMP will then convert Collection<DataNode> to Collection<YangModelCmHandle>. Again, the Collection<DataNode> cannot be garbage collected until fully converted to YangModelCmHandles. This again results in doubling of memory usage.

Similar applies when converting to NcmpServiceCmHandle.

NCMP also contains many queries where only partial results are needed, making a Streams API ideal.

Proposed Solution

A Streams API version of CPS Core read operations:

Stream<DataNode> queryDataNodesAsStream(String dataspaceName, String anchorName, String cpsPath, FetchDescendantsOption fetchDescendantsOption);

This Stream will implement pagination when fetching data from the FragmentRepository.

CPS and NCMP Rest APIs

Instead of returning Collections from Rest APIs, a Stream may be returned, greatly reducing memory.