metacat
metacat copied to clipboard
Metacat throws the error of user not authorized during the publish process even though ezid settings are correct
Jeanette reported that she kept getting the error of user not authorized when she published a package on Arcticdata. I checked the settings and they looked good me. Restarting tomcat fixed the issue. After I looked at the code and found Metacat caches the session from the Ezid service and renews it every 24 hours. So somehow if a session is invalid before the 24 hours life (maybe the ezid service was restarted), Metacat still keeps using it. Of course the ezid service rejects its request. I am thinking Metacat should re-login when it sees the not-authroized error during the operation.
We add the code to try to log in again when the error happens.
I fixed the issue on the publish and generate methods. We should use the same strategy for the submitDOIMetadata method in the EzidDOIService class.
The error message is:
[2023-10-19 15:42:55] [info] metacat 20231019-15:42:55: [ERROR]: FAILED Request 4 for: doi:10.18739/A2Z892G9G. unauthorized [edu.ucsb.nceas.ezid.EZIDServiceRequest:run:103]
I looked at the method submitDOIMetadata closely and found that we do use the same strategy as the other methods. However, it doesn't work. The reason is, the method ezid.createOrUpdate(identifier.getValue(), metadata); creates another thread and will not throw an exception even though the saved session expires.
Since the method submitDOIMetadata can't catch the exception from another thread, the publish button and update DOI button (in the replication admin) can't force the re-login. Only the api call - generate (mint a doi) can force the re-login.
So what's the approach here to make it more robust, @taojing2002 ? The separate thread is created (IIRC) to enable a configurable number of parallel requests to EZID, so I don't think we want to remove that. Within ezid.createOrUpdate it seems like we need to be better at catching the failure and sending it up the stack so that the re-login can occur.
During our meeting, we think we can postpone this ticket. Also I filed a ticket about this issue on the ezid repository: https://github.com/NCEAS/ezid/issues/17