1.Introduction      

Activation Grpc service is implemented by akka-grpc framework, akka-grpc is declared in a protobuf service descriptor, and requests and responses will be streamed over an HTTP/2 connection.

Client located in ContainerProxy, server located in the scheduler.

As far as we know，in upstream logic, activationMessage is pushed to ContainerProxy, but here, containerProxy using pull mode to get the activationMessage actively via Activation akka-grpc service.

2.Architecture Diagram

• ContainerProxy sends ActivationRequest via fetchActivation(Akka-grpc)
• ActivationService delegates the ActivationRequest to QueueManager.
• QueueManager responds with ActivationResponse to ActivationService.
• ActivationService responds with ActivationResponse to ContainerProxy

3.Design consideration

  In upstream logic, ContainerProxy uses push node, invoker component gets activationMessage from kafka and send it to ContainerProxy, containers will be created/deleted/paused frequently, 

  it is better for the performance to keep the created container rather than deleting or pausing it and reuse it, so if ContainerProxy uses pull mode can satisfy this.

  Below is the proto file including one method only:  `rpc FetchActivation (FetchRequest) returns (FetchResponse) {}`

  FetchRequest includes two fields

  1:fqn: the serialized content of FullyQualifiedEntityName

  2:rev:  the serialized content of DocRevision, because one action can be updated, so need to provide corresponding DocRevision as well

  FetchResponse includes one field only

  1. activationMessage, the serialize content of ActivationMessage

//#services
service ActivationService {

    //ContainerProxy call this grpc method to get ActivationMessage

    rpc FetchActivation (FetchRequest) returns (FetchResponse) {}

}
//#services

//#messages
// The request message
message FetchRequest {

      //the serialize content of FullyQualifiedEntityName
      string fqn = 1;

      //the serialize content of DocRevision
      string rev = 2;
}

// The response message
message FetchResponse {

       //the serialize content of ActivationMessage
       string activationMessage = 1;
}

4.Exception / Failure cases

• Response delay of QueueManager
  1.respond to the client with Failure
• If there is no memory queue for the given action
  

  1.Respond to the client with Failure and ContainerProxy should renew the Akka-grpc client endpoint.

  2.If there is no endpoint for the leader MemoryQueue in ETCD, the ContainerProxy terminates.