Josh, this is exactly what I am talking about.
Each service implementation is a singleton *from the perspective of gRPC*.
You cannot have more than one service implementation instance handle
requests from callers. You cannot get a fresh instance for every request.
Is there a specific gRPC
I think this is referring to the fact that you bind a single server object
for the life of the GRPC server.
Go: https://github.com/grpc/grpc-go/blob/master/server.go#L276
Java: https://github.com/grpc/grpc-java/blob/master/
compiler/src/testLite/golden/TestService.java.txt#L167
So it's not
Each server can only reference one instance of a service implementation for
the lifetime of the service, and all requests to that service are routed
concurrently to that single, shared instance, correct?
On Monday, February 27, 2017 at 4:39:26 PM UTC-8, Carl Mastrangelo wrote:
>
> No? I don't
No? I don't know where you could have got that impression but you can make
as many as you like, and share them between Servers as you please.
On Monday, February 27, 2017 at 3:51:57 PM UTC-8, Ryan Michela wrote:
>
> I mean the instance of the class that implements my service operations.
> The
I mean the instance of the class that implements my service operations. The
instance you pass to ServerBuilder.addService().
Isn't that instance a singleton from the perspective of gRPC?
On Monday, February 27, 2017 at 12:48:41 PM UTC-8, Carl Mastrangelo wrote:
>
> What do you mean by Service?
What do you mean by Service? There are hardly any places in our code
where something is a singleton.
On Saturday, February 25, 2017 at 10:31:59 PM UTC-8, Ryan Michela wrote:
>
> I'd like to know the design rationale for why gRPC services
> implementations are all concurrently executing
