Bug #4204
Updated by Rob Nahf almost 11 years ago
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:
<pre>
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 <error detailCode="1340" errorCode="404" name="NotFound">
135546 <description>The object with the provided identifier was not found.</description>
135547 </error>
135548
135549 [DEBUG] 2013-12-13 21:18:44,950 (TransferObjectTask:call:205) Task-urn:node:mnDemo1-syncTesting_Obs_n_Archvd:2013347131323615 Unlocked task
</pre>
The culprit is the check in D1NodeService.archive() that the pid exists in the IdentifierManager:
<pre>
// 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.");
}
</pre>
The reason this happens is that DATA objects are not created on the CNs, only the system metadata is added, and only to the Hazelcast sysmeta map:
TransferObjectTask.createObject() calls nodeComm.getCnCore.registerSystemMetadata(), handled by CNReadController in d1_cn_rest_proxy, and ends up at CNodeService.registerSystemMetadata(), and only updates the hazelcast sysmeta map.
This results in an inconsistency between the extent of pids in the hz sysmeta map (DATA, METADATA, and RESOURCE), and what is in the metacat identifier table on the CNs (no DATA pids). 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) only acts 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.) store.
<pre>
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 <error detailCode="1340" errorCode="404" name="NotFound">
135546 <description>The object with the provided identifier was not found.</description>
135547 </error>
135548
135549 [DEBUG] 2013-12-13 21:18:44,950 (TransferObjectTask:call:205) Task-urn:node:mnDemo1-syncTesting_Obs_n_Archvd:2013347131323615 Unlocked task
</pre>
The culprit is the check in D1NodeService.archive() that the pid exists in the IdentifierManager:
<pre>
// 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.");
}
</pre>
The reason this happens is that DATA objects are not created on the CNs, only the system metadata is added, and only to the Hazelcast sysmeta map:
TransferObjectTask.createObject() calls nodeComm.getCnCore.registerSystemMetadata(), handled by CNReadController in d1_cn_rest_proxy, and ends up at CNodeService.registerSystemMetadata(), and only updates the hazelcast sysmeta map.
This results in an inconsistency between the extent of pids in the hz sysmeta map (DATA, METADATA, and RESOURCE), and what is in the metacat identifier table on the CNs (no DATA pids). 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) only acts 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.) store.