Use Case 06 - MN Synchronize

Revisions

View document revision history.

Goal

Science metadata records and system metadata for all objects available on a Member Node are synchronized to a Coordinating Node.

Summary

As content is added to Member Nodes, the associated system metadata, science metadata, and resource map documents are retrieved by a Coordinating Node. Once the objects are registered with the Coordinating Node, they are considered to be part of the DataONE system, and so will be managed accordingly - the metadata and resource map object will be replicated between Coordinating Nodes, metadata will be indexed, and the objects will be replicated to other Member Nodes as required.

Actors

Member Node, Coordinating Node

Preconditions

• CN and MN operational
• New content available on a Member Node

Triggers

• Periodic polling of MNs
• Signal to CN issued by a MN that is requesting synchronization

Post Conditions

• All system and science metadata records from a MN are also present on the CN
• The search index is updated with the new content

Figure 1. Use case diagram indicating the components and other use cases involved in this use case.

Figure 2. Sequence diagram for use case 06. Synchronize content between Member and Coordinating Node. Detail for the processObject() step provided in the activity diagram below.

Figure 3. Activity diagram indicating the execution flow after attempting to retrieve the system metadata for the object from the CN.

Implementation

The Member Node synchronization process will operate in an asynchronous manner, with a task queue on the CN service containing a list of objects that need to be added to the coordinating node populated through two mechanisms:

1. scheduled calls to MNRead.listObjects()
2. through a new notification API that is called by a Member Node after a successful create operation.

The task queue is processed by a pool of workers which retrieve the content using MNRead.get() and MNRead.getSystemMetadata(), and store the content in the Coordinating Node using the internal CNStorage.create() method.

The initial implementation will focus on using only scheduled calls to MNRead.listObjects() to populate the task queue. The scheduling information shall be set during the MN registration process.

Multiple threads should be able to process the task queue, and the number of threads should be adjustable by an administrator. The total number of threads hitting on a particular MN should be limited, the limit should be specified in the MN capabilities recorded during the registration process.

The tasks queue will need to be thread safe. In the future it may be feasible to use a distributed queue (based on Apache MQ or Zookeeper for example; shared across the CNs) so that processes on any CN can issue the MN_get() and MN_getSystemMetadata() requests.

There will likely be a significant load on the system for indexing as new content is being added - this is the case for both Mercury and Metacat. Options for disabling indexing for bulk load should be considered.

The synchronization process will certainly be more sophisticated down the road, but for now (i.e. prototype implementation) simplicity should be a priority:

• MNs are only scanned by the CN where they are registered (restriction to be dropped down the road).
• listObjects is polled (with max objects set to some limit), with results stored in a queue on the CN
• as the queue is processed and shrinks to some size, then listObjects process is polled again
• the queue is processed by n worker threads, with each task being to pop an entry from the queue, pull the content from the target, and store it in the object store.
• when there is some number of new entries in the object store, then the mercury indexing process needs to kick in. Ideally this should be updating rather than re-creating the index at each pass. This may be initiated by a cron job for the prototype implementation.

This fairly simplistic approach should be enough to get things started. Not ideal, but should suffice to get some data moving around. To implement, there is need for a few new components - a queue, a place to store state information, the code that does the polling, the code that does the object retrieval, the worker thread code, and an overall controller service.

In more detail

Retrieve objects from Member Nodes. getNextMemberNode() gets the next Member Node to work on - this could be serial selection from the list of registered MNs, could be based on the last update, perhaps from some hint returned in MN_health.ping().

New structures:

MemberNodeState
  String url;  //URL of the member node
  DateTime lastCheckTime;  // time stamp for when the MN was last polled for listOjects


RetrievalTask
  String url;
  ObjectInfo objectInfo;

Populating the harvest task queue pseudo code:

void populateTaskQueue ()
{
  ThreadSafeQueue taskQueue = getSharedTaskQueue()
  while ( keepRunning() )
  {
    if (taskQueue.length < MIN_TASKS)
    {
      MemberNodeState = getNextMemberNode();

      // This could be executed in a different thread, which would
      // enable multiple MNs to be polled at a tme if necessary
      int numNewEntries = loadMNTasks(taskQueue, mnState);
    }
  }
}

Processing the harvest task queue pseudo code:

int loadMNTasks(ThreadSafeQueue taskQueue, MemberNodeState mnState)
{
  AuthToken token = getSystemToken();
  D1cient client = D1Client( mnState.url );

  // get a list of all the new entries since lastCheckTime
  DateTime tstamp = now();

  // Will actually need to loop here to page through results
  ObjectList objectList = client.listObjects(token, mnState.lastCheckTime);
  for (ObjectInfo objinfo : objectList)
  {
    RetrievalTask task = RetrievalTask(mnState.url, objinfo)
    taskQueue.push(task)
  }
  mnState.lastCheckTime = tstamp;
  setMemberNodeState(mnState);
  return objectList.length;
}

Worker threads are responsible for retrieving each object listed in the taskQueue. The number of workers should be adjustable. An obvious target for improving efficiency is to enable requesting multiple objects in a single call to a MN (later enhancement):

// object is the next entry from the taskQueue
bool retrieveObject(String mnurl, ObjectInfo object)
{
  Authtoken token = getSystemToken();
  D1Client client = D1Client(mnurl);
  SystemMetadata sysmeta = client.getSystemMetadata( object.identifier );
  if ( isScienceMetadata(sysmeta.objectClass) )
  {
    scimeta = client.get( object.identifier );
    CN_SERVICE.create( object.identifier, sysmeta, scimeta );
  }
  else
  {
    CN_SERVICE.create( object.identifier, sysmeta );
  }
}