Infrastructure

The method should call cn.updateSystemmetadata synchronizely and asynchronizely?

We have long emails to discuss the issue.
Hi all,

I totally see Ben’s point, and it would be better from the MN perspective to get an affirmative return right away. My original thought was that the MN would just call CN.systemMetadataChanged(), and that’d be that, just like we do in v1 where the CN holds authoritative system metadata and we make an asynchronous call to MN.systemMetadataChanged().

The size of the system metadata is certainly not the issue. I was thinking more about the number of HTTPS requests the CNs will realistically concurrently handle. Our new architecture is push-based in that the MNs hold authoritative system metadata, and on any change, we push the change to the CN. In this model, there’s no throttling. In our current pull model (d1_sync), we throttle to 8 concurrent threads per MN when calling MN.getSystemMetadata(). So, in the event that an MN gets a boat load of updated content, we’d see a flurry of un-throttled calls to the CN. Maybe that’s not a big deal. Perhaps a decent MN implementation strategy would be to 1) call CN.updateSystemMetadata() (which blocks), and in the event of a timeout, 2) tries X times, then 3) falls back to CN.systemMetadataChanged() (async).

Anyway - one question: If the call to the CN blocks, does that mean that the client call to the MN also needs to wait for a successful MN.updateSystemMetadata() call? I’m just wondering if the investigator will see the delay if the MN call to the CN isn’t very speedy.

Cheers,
Chris

On Apr 9, 2015, at 3:17 PM, Robert Nahf rnahf@epscor.unm.edu wrote:

I'm not worried so much about a long list of pending updateSystemMetadata requests, because that would assumedly be FIFO, in which case, I don't think the MN would be burdened. We already have potentially the same situation with v1.CN.setAccessPolicy() anyway.

Do any of our replication processes create long-lasting locks on the systemMetadata? I think that's the only potential source of delay (meaning, the only process I don't understand enough to know how it does locking).

Rob

Rob Nahf
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Programmer Analyst for DataONE,
Office of the Vice President for Research
The University of New Mexico
office: 505.814.7600 x8110
mobile: 520.440.0339

rnahf@unm.edu
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Did you ask.dataone.org?

On Thu, Apr 9, 2015 at 11:44 AM, Christopher Jones cjones@nceas.ucsb.edu wrote:

Andrei,

Well, hmm. I would think that we would want these decoupled, and that we should change the API documentation.  Of course, ideally we would want it to know it succeeded, but I’m just not sure that we can ensure that it will happen immediately(ish).

That’s my vote, but others may want to chime in.

Cheers,
Chris

On Apr 9, 2015, at 9:41 AM, Andrei Buium <andreib@dataone.unm.edu> wrote:

Hi Chris,
That makes sense to me. (The diagram in Matt's link shows that's the case too.)
I was assuming it's synchronous because the CN API documentation says it returns true "if the update was successful". Should this be changed to return true if the request to update was sent successfully?
And we'll favor performance (no bottleneck if the MN is doing this in one thread) over assuring that the transaction went through?


On Wed, Apr 8, 2015 at 5:18 PM, Christopher Jones <cjones@nceas.ucsb.edu> wrote:

    Hi Andrei,
    My understanding was that the call to CNCore.updateSystemMetadata () would be asynchronous and not block. Waiting for the CN to process, potentially a long queue of requests, may be a bottleneck for the MN. If the CN returns an HTTP 200, the MN can move on and the CN can deal with the new SM as soon as it can.
    Do I have this right?

    Cheers,
    Chris

    On Apr 8, 2015 3:43 PM, Robert Nahf <rnahf@epscor.unm.edu> wrote:
    >
    > Also, assuming that an update of the authoritative MN's systemMetadata is accompanied by a new dateSystemMetadataModified value, the object will be picked up by synchronization, and the CN will update their systemMetadata then.
    >
    >
    >
    > Rob Nahf
    > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
    > Programmer Analyst for DataONE,
    > Office of the Vice President for Research
    > The University of New Mexico
    > office: 505.814.7600 x8110
    > mobile: 520.440.0339  
    > rnahf@unm.edu
    > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
    >
    > Did you ask.dataone.org?
    >
    > On Wed, Apr 8, 2015 at 3:36 PM, Andrei Buium <andreib@dataone.unm.edu> wrote:
    >>
    >> Oh perfect, I was trying to find a diagram like that earlier.
    >> I was wondering about v2 mainly. 
    >> It looks like the MN will be responsible for pushing out changes made, to the CN using CNCore.updateSystemMetadata() and to other MNs using MNStorage.updateSystemMetadata(). That makes sense.
    >>
    >> Thanks!
    >> -Andrei
    >>
    >>
    >> On Wed, Apr 8, 2015 at 3:17 PM, Matt Jones <jones@nceas.ucsb.edu> wrote:
    >>>
    >>> Andrei --
    >>>
    >>> That looks correct for our v1 API.  I think the MN.updateSystemMetadata() is part of the changes in v2 API that shift maintenance authority for system metadata to Member Nodes.  This is not yet deployed in production.  See the architecture docs for a description of the pending changes:
    >>>
    >>> http://jenkins-1.dataone.org/jenkins/job/API%20Documentation%20-%20trunk/ws/api-documentation/build/html/design/SystemMetadata.html#roadmap-to-system-metadata-control-changes-draft-to-be-reviewed
    >>>
    >>> Matt
    >>>
    >>>
    >>> On Wed, Apr 8, 2015 at 12:49 PM, Andrei Buium <andreib@dataone.unm.edu> wrote:
    >>>>
    >>>> Hey all,
    >>>> I have a couple questions on MN updates of system metadata.
    >>>>
    >>>> Here is the sequence of events I've put together from the API documentation. 
    >>>> How accurate is it?
    >>>>
    >>>> - an MN updates an object's sysmeta locally
    >>>> - that MN notifies the CN using CNCore.updateSystemMetadata()
    >>>> updateSystemMetadata() blocks / runs synchronously
    >>>> (it returns true if the update was successful, implying it's synchronous)
    >>>> this call updates the sysmeta on the CN
    >>>> - the CN is responsible for notifying other MNs (those holding replicas) of the update
    >>>> it calls MNRead.systemMetadataChanged() for each MN that needs to know
    >>>> systemMetadataChanged() runs asynchronously, returning true if the message was received
    >>>> - the replica-holding MNs can use CN.getSystemMetadata() to update their copy
    >>>> we don't enforce when this happens
    >>>> The above has the CN using MN.systemMetadataChanged() to notify of the update.
    >>>> There's also MN.updateSystemMetadata(). When / by whom is that used?
    >>>>
    >>>> Thanks!
    >>>> -Andrei
    >>>>
    >>>> _______________________________________________
    >>>> developers mailing list
    >>>> developers@dataone.org
    >>>> To unsubscribe or change your subscription, email support@dataone.org
    >>>
    >>>
    >>
    >>
    >> _______________________________________________
    >> developers mailing list
    >> developers@dataone.org
    >> To unsubscribe or change your subscription, email support@dataone.org
    >
    >

_______________________________________________
developers mailing list
developers@dataone.org
To unsubscribe or change your subscription, email support@dataone.org