Infrastructure

When attempting to reflect an mn.archive event during synchronization using cn.archive (TransferObjectTask.updateSystemMetadata()), a NotFound exception is thrown by the call to metacat, at D1NodeService.archive(). for example:

135538 [ INFO] 2013-12-13 21:18:43,476 (TransferObjectTask:write:430) Task-urn:node:mnDemo1-syncTesting_Obs_n_Archvd:2013347131323615 Pid Exists. Must be an Update
135539 [ INFO] 2013-12-13 21:18:43,477 (TransferObjectTask:write:462) Task-urn:node:mnDemo1-syncTesting_Obs_n_Archvd:2013347131323615 Update sysMeta because checksum is same
135540 [ INFO] 2013-12-13 21:18:43,479 (TransferObjectTask:updateSystemMetadata:687) Task-urn:node:mnDemo1-syncTesting_Obs_n_Archvd:2013347131323615 Update ObsoletedBy
135541 [ INFO] 2013-12-13 21:18:43,945 (TransferObjectTask:updateSystemMetadata:692) Task-urn:node:mnDemo1-syncTesting_Obs_n_Archvd:2013347131323615 Updated ObsoletedBy
135542 [ INFO] 2013-12-13 21:18:43,945 (TransferObjectTask:updateSystemMetadata:697) Task-urn:node:mnDemo1-syncTesting_Obs_n_Archvd:2013347131323615 Update Archived
135543 [ERROR] 2013-12-13 21:18:44,182 (TransferObjectTask:write:488) Task-urn:node:mnDemo1-syncTesting_Obs_n_Archvd:2013347131323615
135544 <?xml version="1.0" encoding="UTF-8"?>
135545
135546 The object with the provided identifier was not found.
135547
135548

135549 [DEBUG] 2013-12-13 21:18:44,950 (TransferObjectTask:call:205) Task-urn:node:mnDemo1-syncTesting_Obs_n_Archvd:2013347131323615 Unlocked task

The culprit is the check in D1NodeService.archive() that the pid exists in the IdentifierManager:

// check for the existing identifier
try {
localId = IdentifierManager.getInstance().getLocalId(pid.getValue());
} catch (McdbDocNotFoundException e) {
throw new NotFound("1340", "The object with the provided " + "identifier was not found.");
}

The reason the error happens is that DATA objects are not created on the CNs, only the system metadata is added via registerSystemMetadata, and only to the Hazelcast sysmeta map:
TransferObjectTask.createObject() calls nodeComm.getCnCore.registerSystemMetadata(), which is handled by CNReadController in d1_cn_rest_proxy, and ultimately ends up at CNodeService.registerSystemMetadata(), which only updates the hazelcast sysmeta map.

This results in an inconsistency between the extent of pids in the hz sysmeta map (which include DATA, METADATA, and RESOURCE formats), and the metacat identifier table on the CNs (only METADATA and RESOURCE format pids). There seems to be also an inconsistency in what the locus of control is for systemMetadata when hz is involved (metacat as CN) - archive checks with, and acts on the database tables, while other methods (setObsoletedBy, for example) only act on the hz systemMetadata map.

(As an aside, It's also unclear to me how changes made to the hz systemMetadata map are propagated to the underlying data store.)

Are there other CN methods that update systemMetadata that similarly bypass the hazelcast map that might have similar issues?