Implementing client streaming on server side (java)

[Alexander Furer]

From the grpc guide "gRPC guarantees message ordering within an individual RPC call."

Given the service definition  

rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) {
}

does it mean that implementation of  onNext(HelloRequest request)  does NOT need to be synchronized ? 

In the other words, the onNext(HelloRequest request) is invoked  sequentially one after another ?

Thanks

[Carl Mastrangelo]

What that means is that the messages will never be reordered.  You MUST synchronize access to the RPC, either by ensuring only one thread ever accesses it, or adding your own synchronization.  

The comment you see is more in regards to other network stuff (like UDP), where packets can be reordered.  

[Alexander Furer]

Thanks Carl, but I'll rephrase  the question.

On the server side,my implementation of 'onNext'  aggregates the streaming messages in to some in-memory storage, say Map. No one else is accessing it till I get OnCompleted from client. 

Does this map should be ConcurrentMap (in java language)  or regular HashMap is enough ?

I'm asking if  each 'onNext' waits completion of previous one before being executed or they can be invoked in parallel ?

[Carl Mastrangelo]

Regular hashMap is enough, as long as there is exactly one map per RPC.  If there are multiple RPCs, you will need to synchronize.  (Stated differently: each request StreamObserver and map pair should be 1-1 and onto, e.g a bijection). 

More detail:   each RPC has an associated SerializingExecutor that handles the callbacks for that RPC.   The SerializingExecutor is executed inside of the executor you provided to the ServerBuilder at construction.  The SE ensures that no callback for the given RPC overlaps with any other callback for the same RPC.  Thus, you can be sure that you don't get onCancelled in the middle of onMessage.   The events may happen on different threads, which is up to the executor you provided to the server.  This is okay, because there is a "Happens Before" relationship between the callbacks.  The necessary synchronization barriers are present  to ensure you don't need to add your own.