Task #8060
CN failed to call MN.synchronizationFailed method for the arctic data center and knb mn
100%
Description
Chris and Bryce found:
So I’m trying to understand why it didn’t sync, but moreover why calls to MN.syncFailed() are failing on the MNs
And it’s happening since March 19th on both KNB and ADC
Related issues
History
#1 Updated by Jing Tao over 7 years ago
- Target version changed from CCI-2.3.4 to CCI-2.3.3
#2 Updated by Jing Tao over 7 years ago
- Related to Bug #7954: SyncFailedTask:submitSynchronizationFailed does not provide cert when connecting to MN added
#3 Updated by Jing Tao over 7 years ago
After digging around, I found that:
metacat 20170404-23:36:12: [DEBUG]: The xml information (error message) in the temp file is
<?xml version="1.0" encoding="UTF-8"?>
Synchronization task of [PID::] sla.5.1 [::PID] failed. Cause: IdentifierNotUnique: The requested identifier sla.5.1 is already used by another object andtherefore can not be used for this object. Clients should choosea new identifier that is unique and retry the operation or use CN.reserveIdentifier() to reserve one.
<?xml version="1.0" encoding="UTF-8"?>
Synchronization task of [PID::] sla.5.1 [::PID] failed. Cause: IdentifierNotUnique: The requested identifier sla.5.1 is already used by another object andtherefore can not be used for this object. Clients should choosea new identifier that is unique and retry the operation or use CN.reserveIdentifier() to reserve one.
[edu.ucsb.nceas.metacat.restservice.v2.MNResourceHandler:collectSynchronizationFailed:1653]
metacat 20170404-23:36:12: [DEBUG]: we are going to deserialzie xml file to a java object ----- [edu.ucsb.nceas.metacat.restservice.v2.MNResourceHandler:collectSynchronizationFailed:1655]
[Fatal Error] :5:6: The processing instruction target matching "[xX][mM][lL]" is not allowed.
metacat 20170404-23:36:12: [ERROR]: D1ResourceHandler: Serializing exception with code 500: The processing instruction target matching "[xX][mM][lL]" is not allowed. [edu.ucsb.nceas.metacat.restservice.D1ResourceHandler:serializeException:456]
The duplicated xml were sent to Metacat. So Metacat can't deserialize the xml file to an object.
#4 Updated by Jing Tao over 7 years ago
It turned out that the method - domToString on the class BaseException used a shared the StringWriter object. If the SynchornizationFailed object serializes (using the domToString method ) twice , the xml presentation result will duplicate. The code has existed since 2011. But the MN.synchronizationFailed still worked since we only call the method once during the process. However, a debug statement which serializes the SynchronizationFailed object was added recently, so the the object was serialized twice during the sync. So the duplicated xml was sent to the MN.
#5 Updated by Rob Nahf over 7 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 30
committed the change to d1_synchonization trunk and 2.3 branch to eliminate the initial deserialization that was causing the double xml message body in the synchronizationFailed message body.
#6 Updated by Jing Tao over 7 years ago
- Related to deleted (Bug #7954: SyncFailedTask:submitSynchronizationFailed does not provide cert when connecting to MN)
#7 Updated by Jing Tao over 7 years ago
- Related to Bug #8064: ExceptionHandler class should handle the new identifier attribute in the xml representation of exceptions added
#8 Updated by Jing Tao over 7 years ago
For the branch 2.3, the fixing works.
However, for the trunk (2.4), there is a change that the attribute "pid" has been replaced by "identifier". This change was half done (serialization). The deserialization hasn't been done.
See https://redmine.dataone.org/issues/8064.
When this bug is fixed, we can close the ticket.
#9 Updated by Jing Tao over 7 years ago
- % Done changed from 30 to 100
- Status changed from In Progress to Closed
The ticket 8064 is fixed. So both trunk and branch 2.3 work.
