You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by "Elek, Marton (JIRA)" <ji...@apache.org> on 2019/06/12 11:28:00 UTC

[jira] [Created] (HDDS-1674) Make ScmBlockLocationProtocol message type based

Elek, Marton created HDDS-1674:
----------------------------------

             Summary: Make ScmBlockLocationProtocol message type based
                 Key: HDDS-1674
                 URL: https://issues.apache.org/jira/browse/HDDS-1674
             Project: Hadoop Distributed Data Store
          Issue Type: Improvement
            Reporter: Elek, Marton
            Assignee: Shweta


Most of the Ozone protocols are "message type based" and not "method based".

For example in OzoneManagerProtocol.proto there is only one method:

{code}
service OzoneManagerService {
    // A client-to-OM RPC to send client requests to OM Ratis server
    rpc submitRequest(OMRequest)
          returns(OMResponse);
}
{code}

And the exact method is determined by the type of the message:

{code}

message OMResponse {
  required Type cmdType = 1; // Type of the command

  // A string that identifies this command, we generate  Trace ID in Ozone
  // frontend and this allows us to trace that command all over ozone.
  optional string traceID = 2;

  optional bool success = 3 [default=true];

  optional string message = 4;

  required Status status = 5;

  optional string leaderOMNodeId = 6;

  optional CreateVolumeResponse              createVolumeResponse          = 11;
  optional SetVolumePropertyResponse         setVolumePropertyResponse     = 12;
  optional CheckVolumeAccessResponse         checkVolumeAccessResponse     = 13;
....
}


enum Type {
  CreateVolume = 11;
  SetVolumeProperty = 12;
  CheckVolumeAccess = 13;
  InfoVolume = 14;
  DeleteVolume = 15;
  ListVolume = 16;
....
{code}

This is not the most natural way to use protobuf services but it has the additional benefit that we can propagate traceId / exception in a common way.

Earlier there was an agreement to modify all the protocols to use this "message type based" approach to make it possible to provide proper error handling.

In this issue  the ScmBlockLocationProtocol.proto should be modified to use only one message:

{code}
service ScmBlockLocationProtocolService {

  rpc send (SCMBlockLocationRequest) returns (SCMBlockLocationResponse);
}
{code}

It also requires to create the common request and response objects (with the common fields like type, traceId, success, message, status as they are used in the OzoneManagerProtocol.proto).

To make it work, the ScmBlockLocationProtocolClientSideTranslatorPB and the ScmBlockLocationProtocolServerSideTranslatorPB should be improved to wrap/unwrap the original message to/from the generic message. 

I propose to only the protocol change here (if possible) we can keep the message/status fields empty and fix the error propagation in HDDS-1258





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org