Channels are relatively heavier weight and thus it could be a good idea to
not create a lot of them (unless you hit some throughput bottleneck). Stubs
are pretty cheap.
Channels and stubs are all thread-safe.

On Tue, Nov 12, 2019 at 1:22 PM <[email protected]> wrote:

> Sorry, i meant "Is it better to also create only one stub for all these
> calls or to create a stub for every function call..."
>
> Am Dienstag, 12. November 2019 22:18:15 UTC+1 schrieb
> [email protected]:
>>
>> After hours of reading on internet and not getting an answer i will ask
>> here. We are currently trying to replace SOAP with grpc for our client
>> server architecture. On the client side we are using grpc c++. Now the
>> question is what is the best approach to create stubs and channels. What i
>> understand is that its the best to only have one channel and use it for all
>> calls. But what about stubs. We have round about 100 functions that will
>> call the server on different threads. Is it better to also create only one
>> stub for all these calls or to create one stub and make asynchronous calls?
>> And what about thread safety?
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/643efd39-8d2e-45fc-9936-d6b8a10420f2%40googlegroups.com
> <https://groups.google.com/d/msgid/grpc-io/643efd39-8d2e-45fc-9936-d6b8a10420f2%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAB1HKY72FNjiMPKgKsh%3D_qh1Wqp-0js9-xifahyciVpCv%3D0-3g%40mail.gmail.com.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to