Project

General

Profile

Bug #2656

mn.getSystemMetadata() dependent on CN being available

Added by Rob Nahf about 12 years ago. Updated about 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Ben Leinfelder
Category:
Metacat
Start date:
Due date:
% Done:

100%

Milestone:
CCI-1.0.0
Product Version:
*
Story Points:
Sprint:

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 about 12 years ago

  • Category set to Metacat
  • Assignee set to Ben Leinfelder

#2 Updated by Ben Leinfelder about 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)