Have you actually tried this?  Can you include an error showing that this 
is not possible?

On Monday, February 27, 2017 at 4:49:42 PM UTC-8, Ryan Michela wrote:
>
> 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 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 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?   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 singletons. There are many 
>>>>> possible instancing and threading modes that could have been used.
>>>>>
>>>>>    - Singleton instancing
>>>>>    - Per-call instancing
>>>>>    - Per-session instancing
>>>>>
>>>>>
>>>>>    - Concurrent execution
>>>>>    - Sequential execution
>>>>>
>>>>> Concurrent singletons make sense from an absolute throughput angle - 
>>>>> no object instantiation or blocking. But concurrent singletons are 
>>>>> hardest 
>>>>> for developers to work with - service implementors must be keenly aware 
>>>>> of 
>>>>> shared state and mult-threading concerns. 
>>>>>
>>>>>    1. Why was concurrent singleton chosen as the only out-of-the-box 
>>>>>    way to implement gRPC (java) services? 
>>>>>    2. Would API for supporting other threading and instancing modes 
>>>>>    be accepted in a PR?
>>>>>
>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/50eb23e0-4092-40f6-9f87-e5fb1a6251e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to