Bug #2656
mn.getSystemMetadata() dependent on CN being available
100%
Description
while testing demo2 while cn-dev was unreachable, I got the following exception from a mn.getSystemMetadata call:
java.lang.AssertionError: ServiceFailure: 0 Client_Error: class
org.apache.http.conn.HttpHostConnectException: Connection to https://cn-dev.dataone.org refused [for host
GET https://demo2.test.dataone.org/knb/d1/mn/v1/meta/TierTesting:demo2:RightsHolder_testPerson.13]
Looking at D1NodeService.getSystemMetadata() in metacat, it appears that the session first attempts to authorize against the object's replica nodes' subjects (via cn.listNodes()) prior to checking the accessPolicy of the sysmeta that's in-hand.
I think this is a mistake, partly because it makes getSystemMetadata dependent on the availability of the CN, and partly because it puts a time-consuming http call (cn.listNodes()) in front of a less expensive local one (isAuthorized()).
It would work more reliably and independently if it were the other way around, and isAuthorized() preceded the section calling cn.listNodes(). It would reduce the number of calls to the CNs, too, especially if the node list could be cached.
History
#1 Updated by Rob Nahf over 12 years ago
- Category set to Metacat
- Assignee set to Ben Leinfelder
#2 Updated by Ben Leinfelder over 12 years ago
- Status changed from New to Closed
Changed the order - now we check if the caller is authorized (because of a lenient accessPolicy) then if they are not we go one step further to see if they are a MN that should have access for replication purposes.