Re: [grpc-io] gRPC Cancellation Token

['Sanjay Pujare' via grpc.io]

Use context.TryCancel() as described in
https://github.com/grpc/grpc/issues/17292

On Fri, Sep 22, 2023 at 1:13 AM Ahmet Yılmaz  wrote:

> Hello Everyone,
>
> Im working grpc server client project on c++, Im trying to cancel server
> rpc with a request from client, but I didn'tHow can I cancel server
> rpc  from client side ?
>
> Thanks
> Best regards
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/e3bcdccf-45b5-4166-bfff-d0a786b1824fn%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6i3cwZdu%2BgR_V%2Bk%3D%2BeLk3DV6m6UMWKPuPdET4YZtxpBYg%40mail.gmail.com.

Re: [grpc-io] Re: Vulnerability Assessment- CVE-2023-33953

['Sanjay Pujare' via grpc.io]

This issue should answer your question
https://github.com/grpc/grpc-java/issues/10553 .

On Wed, Sep 20, 2023 at 7:17 PM VIJAYABALAN G 
wrote:

> Can I have an update on this please?
>
> On Thu, 14 Sept 2023, 11:49 am VIJAYABALAN G, 
> wrote:
>
>> We are using gRPC java implementation in many of our applications across
>> organization. Recently, we came to know about the vulnerability as
>> mentioned in the subject. Please help to clarify the following points.
>> 1. Is this vulnerability limited to C++ implementation?
>> 2. We are using gRPC v1.37.1 (java). Is java implementation is also
>> impacted?
>>
>>
>>
>> -- Forwarded message -
>> From: VIJAYABALAN G 
>> Date: Fri, 8 Sept 2023, 12:18 pm
>> Subject: Vulnerability Assessment- CVE-2023-33953
>> To: 
>>
>>
>> Dear team,
>>
>> Trust you are well!!
>>
>> We are using gRPC java implementation in many of our applications across
>> organization. Recently, we came to know about the vulnerability as
>> mentioned in the subject. Please help to clarify the following points.
>> 1. Is this vulnerability limited to C++ implementation?
>> 2. We are using gRPC v1.37.1 (java). Is java implementation is also
>> impacted?
>>
>>
>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/CAF4%3Dm6iAsnd6WgXjzZMYWe01_ac6k2yQdK9X0T8%2BRfCcmVfzug%40mail.gmail.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6gSV5%2B_KyojDRexE0KFifXBh0VLcrukBC%2BeJhjhU8D%3Dqw%40mail.gmail.com.

Re: [grpc-io] Re: After the channel is created, it takes 1000+ms to transition from IDEL state to CONNECTING state.How can i reduce the time required to change state?

['Sanjay Pujare' via grpc.io]

Oh, I didn't realize your grpc java version was so old. Good to know your
issue is resolved.

On Fri, Aug 25, 2023 at 1:23 AM '邹会江' via grpc.io 
wrote:

> Thanks！
> I upgrade the grpc-java version from 1.3.3 to 1.51.0, and the IDLE time is
> reduced from 1000ms to 300ms.
>
> 在2023年8月25日星期五 UTC+8 13:05:56 写道：
>
>> Instead of modifying and using the jre/lib logging.properties file can
>> you try using one for your application alone as described in my previous
>> message (use Java property java.util.logging.config.file and so on)?
>>
>> On Wednesday, August 23, 2023 at 7:49:39 PM UTC-7 邹会江 wrote:
>>
>>> 1. I modified the logging.properties file under jre/lib:
>>> handlers=java.util.logging.ConsoleHandler
>>> io.grpc.ChannelLogger.level=FINEST
>>> io.grpc.level=FINEST
>>> io.netty.level=FINEST
>>> java.util.logging.ConsoleHandler.level=ALL
>>>
>>> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
>>> but grpc doesn't have any log output to the console.
>>>
>>> 在2023年8月24日星期四 UTC+8 02:32:08 写道：
>>>
 On Wed, Aug 23, 2023 at 1:37 AM '邹会江' via grpc.io <
 grp...@googlegroups.com> wrote:

> Sanjay Pujare：
> Thank you for your reply!
> 1. How do  i enable trace logging?
>

 It uses java util logging so to enable using JAVA_OPTS:

 export JAVA_OPTS="-Djava.util.logging.config.file=/logging.properties"

 And in /logging.properties have this:

 handlers=java.util.logging.ConsoleHandler
 io.grpc.ChannelLogger.level=FINEST
 io.grpc.level=FINEST
 io.netty.level=FINEST
 java.util.logging.ConsoleHandler.level=ALL

 java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

 Or you can tweak it to your liking.


> 2. DNS resolution,TLS hanshake and TCP connection.In this case,the
> state of channel should be CONNECTING?


 Yes.


> Therefore,the TCP connectio only affects the CONNECTING time, but not
> the IDLE time.
>

 Not sure I understand this comment/question. But when it is trying to
 establish the TCP connection, yes the status is CONNECTING


>
> 在2023年8月23日星期三 UTC+8 14:23:02 写道：
>
>> Most of the time is spent in IDLE -> CONNECTING transition. From this
>> doc
>> https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md
>> which says for CONNECTING
>>
>> CONNECTING: The channel is trying to establish a connection and is
>> waiting to make progress on one of the steps involved in name resolution,
>> TCP connection establishment or TLS handshake. This may be used as the
>> initial state for channels upon creation.
>>
>> DNS resolution and TLS handshake (since you are not calling
>> usePlaintext() on the builder) are possible culprits. Even TCP connection
>> establishment is a possibility depending on where the target is. If you
>> enable trace logging you might be able to figure out.
>>
>> On Tue, Aug 22, 2023 at 10:08 PM '邹会江' via grpc.io <
>> grp...@googlegroups.com> wrote:
>>
>>> Thank you for your reply!
>>> 1. The first time:
>>> The transition from idle state to connecting takes: 3377 ms,
>>> The transition from idle state to ready takes: 3679 ms
>>> 2. The second time:
>>> The transition from idle state to connecting takes: 1643 ms,
>>> The transition from idle state to ready takes: 1797 ms
>>> 3.The third time:
>>> The transition from idle state to connecting takes: 1019 ms,
>>> The transition from idle state to ready takes: 1049 ms
>>> 4. What is my enviroment?
>>> MacBook Pro (16-inch, 2019)
>>> 2.6 GHz 6 core Intel Core i7
>>> 16 GB 2667 MHz DDR4
>>>
>>> 在2023年8月23日星期三 UTC+8 04:31:28 写道：
>>>
 Another question is whether this is the same the second time you
 create a channel.  The first time, the JVM may be taking time doing 
 class
 loading.

 On Tue, Aug 22, 2023 at 8:41 AM 'Yuri Golobokov' via grpc.io <
 grp...@googlegroups.com> wrote:

> Hello,
> What is the round-trip time? How much time does DNS resolution
> take?
>
> On Tuesday, August 22, 2023 at 12:02:21 AM UTC-7 邹会江 wrote:
>
>> ### JAVA Code
>>
>> ```
>> channel =
>> ManagedChannelBuilder.forTarget(param.getTarget()).build();
>> long channelStart = System.currentTimeMillis();
>> asyncStub = ASRRouteGrpc.newStub(channel);
>> asrResponseStreamObserver = new
>> ASRResponseStreamObserver(speechTranscriberListener);
>> requestObserver =
>> asyncStub.route(asrResponseStreamObserver);
>> RouteRequest requestConf = newRequestHead(param);
>> traceId = requestConf.getAsrConfig().getTraceId();

Re: [grpc-io] Re: After the channel is created, it takes 1000+ms to transition from IDEL state to CONNECTING state.How can i reduce the time required to change state?

['Sanjay Pujare' via grpc.io]

On Wed, Aug 23, 2023 at 1:37 AM '邹会江' via grpc.io 
wrote:

> Sanjay Pujare：
> Thank you for your reply!
> 1. How do  i enable trace logging?
>

It uses java util logging so to enable using JAVA_OPTS:

export JAVA_OPTS="-Djava.util.logging.config.file=/logging.properties"

And in /logging.properties have this:

handlers=java.util.logging.ConsoleHandler
io.grpc.ChannelLogger.level=FINEST
io.grpc.level=FINEST
io.netty.level=FINEST
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

Or you can tweak it to your liking.


> 2. DNS resolution,TLS hanshake and TCP connection.In this case,the state
> of channel should be CONNECTING?


Yes.


> Therefore,the TCP connectio only affects the CONNECTING time, but not the
> IDLE time.
>

Not sure I understand this comment/question. But when it is trying to
establish the TCP connection, yes the status is CONNECTING


>
> 在2023年8月23日星期三 UTC+8 14:23:02 写道：
>
>> Most of the time is spent in IDLE -> CONNECTING transition. From this doc
>> https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md
>> which says for CONNECTING
>>
>> CONNECTING: The channel is trying to establish a connection and is
>> waiting to make progress on one of the steps involved in name resolution,
>> TCP connection establishment or TLS handshake. This may be used as the
>> initial state for channels upon creation.
>>
>> DNS resolution and TLS handshake (since you are not calling
>> usePlaintext() on the builder) are possible culprits. Even TCP connection
>> establishment is a possibility depending on where the target is. If you
>> enable trace logging you might be able to figure out.
>>
>> On Tue, Aug 22, 2023 at 10:08 PM '邹会江' via grpc.io <
>> grp...@googlegroups.com> wrote:
>>
>>> Thank you for your reply!
>>> 1. The first time:
>>> The transition from idle state to connecting takes: 3377 ms,
>>> The transition from idle state to ready takes: 3679 ms
>>> 2. The second time:
>>> The transition from idle state to connecting takes: 1643 ms,
>>> The transition from idle state to ready takes: 1797 ms
>>> 3.The third time:
>>> The transition from idle state to connecting takes: 1019 ms,
>>> The transition from idle state to ready takes: 1049 ms
>>> 4. What is my enviroment?
>>> MacBook Pro (16-inch, 2019)
>>> 2.6 GHz 6 core Intel Core i7
>>> 16 GB 2667 MHz DDR4
>>>
>>> 在2023年8月23日星期三 UTC+8 04:31:28 写道：
>>>
 Another question is whether this is the same the second time you create
 a channel.  The first time, the JVM may be taking time doing class loading.

 On Tue, Aug 22, 2023 at 8:41 AM 'Yuri Golobokov' via grpc.io <
 grp...@googlegroups.com> wrote:

> Hello,
> What is the round-trip time? How much time does DNS resolution take?
>
> On Tuesday, August 22, 2023 at 12:02:21 AM UTC-7 邹会江 wrote:
>
>> ### JAVA Code
>>
>> ```
>> channel =
>> ManagedChannelBuilder.forTarget(param.getTarget()).build();
>> long channelStart = System.currentTimeMillis();
>> asyncStub = ASRRouteGrpc.newStub(channel);
>> asrResponseStreamObserver = new
>> ASRResponseStreamObserver(speechTranscriberListener);
>> requestObserver =
>> asyncStub.route(asrResponseStreamObserver);
>> RouteRequest requestConf = newRequestHead(param);
>> traceId = requestConf.getAsrConfig().getTraceId();
>> ConnectivityState currentChannelState =
>> channel.getState(true);
>> while (currentChannelState != ConnectivityState.READY) {
>> CountDownLatch latchUntilChannelReady = new
>> CountDownLatch(1);
>> channel.notifyWhenStateChanged(currentChannelState,
>> latchUntilChannelReady::countDown);
>> latchUntilChannelReady.await();
>> currentChannelState = channel.getState(true);
>> if (currentChannelState ==
>> ConnectivityState.CONNECTING) {
>> long channelConnecting =
>> System.currentTimeMillis();
>> LOGGER.info("The transition from idle state to
>> connecting takes: {} ms", channelConnecting - channelStart);
>> }
>> }
>> long channelReady = System.currentTimeMillis();
>> if (LOGGER.isInfoEnabled()) {
>> LOGGER.info("Trace id: {}, channel start time: {},
>> channel ready time: {}, creating channel takes: {} ms", traceId,
>> channelStart, channelReady,
>> channelReady - channelStart);
>> }
>> ```
>> ### LOGGER
>>
>> ```
>> 2023-08-22 14:12:34,816 INFO  client.ASRClient - The transition from
>> idle state to connecting takes: 1009 ms
>> 2023-08-22 14:12:34,841 INFO  client.ASRClient - Trace id:
>> 

Re: [grpc-io] Adding a new service in server at runtime

['Sanjay Pujare' via grpc.io]

Which language are you talking about?

On Wed, Aug 23, 2023 at 4:47 AM Dan Ab  wrote:

> Is it possible to add new service in the server after it has started? If
> not is there any workaround?
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/692c04a2-3aee-4e23-a56f-cc4fe44d192fn%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hu2kUYk7q7RhYDZ%2BaKd49zOTywz35T8A5UsinNZx%2BpzA%40mail.gmail.com.

Re: [grpc-io] Re: After the channel is created, it takes 1000+ms to transition from IDEL state to CONNECTING state.How can i reduce the time required to change state?

['Sanjay Pujare' via grpc.io]

Most of the time is spent in IDLE -> CONNECTING transition. From this doc
https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md
which says for CONNECTING

CONNECTING: The channel is trying to establish a connection and is waiting
to make progress on one of the steps involved in name resolution, TCP
connection establishment or TLS handshake. This may be used as the initial
state for channels upon creation.

DNS resolution and TLS handshake (since you are not calling usePlaintext()
on the builder) are possible culprits. Even TCP connection establishment is
a possibility depending on where the target is. If you enable trace logging
you might be able to figure out.

On Tue, Aug 22, 2023 at 10:08 PM '邹会江' via grpc.io 
wrote:

> Thank you for your reply!
> 1. The first time:
> The transition from idle state to connecting takes: 3377 ms,
> The transition from idle state to ready takes: 3679 ms
> 2. The second time:
> The transition from idle state to connecting takes: 1643 ms,
> The transition from idle state to ready takes: 1797 ms
> 3.The third time:
> The transition from idle state to connecting takes: 1019 ms,
> The transition from idle state to ready takes: 1049 ms
> 4. What is my enviroment?
> MacBook Pro (16-inch, 2019)
> 2.6 GHz 6 core Intel Core i7
> 16 GB 2667 MHz DDR4
>
> 在2023年8月23日星期三 UTC+8 04:31:28 写道：
>
>> Another question is whether this is the same the second time you create a
>> channel.  The first time, the JVM may be taking time doing class loading.
>>
>> On Tue, Aug 22, 2023 at 8:41 AM 'Yuri Golobokov' via grpc.io <
>> grp...@googlegroups.com> wrote:
>>
>>> Hello,
>>> What is the round-trip time? How much time does DNS resolution take?
>>>
>>> On Tuesday, August 22, 2023 at 12:02:21 AM UTC-7 邹会江 wrote:
>>>
 ### JAVA Code

 ```
 channel =
 ManagedChannelBuilder.forTarget(param.getTarget()).build();
 long channelStart = System.currentTimeMillis();
 asyncStub = ASRRouteGrpc.newStub(channel);
 asrResponseStreamObserver = new
 ASRResponseStreamObserver(speechTranscriberListener);
 requestObserver =
 asyncStub.route(asrResponseStreamObserver);
 RouteRequest requestConf = newRequestHead(param);
 traceId = requestConf.getAsrConfig().getTraceId();
 ConnectivityState currentChannelState =
 channel.getState(true);
 while (currentChannelState != ConnectivityState.READY) {
 CountDownLatch latchUntilChannelReady = new
 CountDownLatch(1);
 channel.notifyWhenStateChanged(currentChannelState,
 latchUntilChannelReady::countDown);
 latchUntilChannelReady.await();
 currentChannelState = channel.getState(true);
 if (currentChannelState ==
 ConnectivityState.CONNECTING) {
 long channelConnecting = System.currentTimeMillis();
 LOGGER.info("The transition from idle state to
 connecting takes: {} ms", channelConnecting - channelStart);
 }
 }
 long channelReady = System.currentTimeMillis();
 if (LOGGER.isInfoEnabled()) {
 LOGGER.info("Trace id: {}, channel start time: {},
 channel ready time: {}, creating channel takes: {} ms", traceId,
 channelStart, channelReady,
 channelReady - channelStart);
 }
 ```
 ### LOGGER

 ```
 2023-08-22 14:12:34,816 INFO  client.ASRClient - The transition from
 idle state to connecting takes: 1009 ms
 2023-08-22 14:12:34,841 INFO  client.ASRClient - Trace id:
 6afd2c67-e8c5-4cea-bd5c-4b82591a52aa, channel start time: 1692684753807,
 channel ready time: 1692684754841, creating channel takes: 1034 ms
 ```
 ### Description
  code logic
 1. first create channel
 2. mark a time stamp(channelStart) after the channel is created
 3. get the state of channel ,the state is IDEL
 4. when the state of channel changes from IDEL to CONNECTING,mark a
 time stamp(channelConnecting)
 5. when the state of channel changes from CONNECTING to READY, mark a
 time stamp(channelReady)

  Log info
 1. It takes 1009ms for channel from IDLE state to CONNECTING state.
 2. It takes 25ms for channel from CONNECTIONG state to READY state.
 ### What's i supposed
 1. Does it take too long for a channel to change from IDLE to
 CONNECTING?
 2. I want to reduce the time it takes for a channel to go from IDLE to
 CONNECTING.

>>> --
>>> 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 grpc-io+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> 

Re: [grpc-io] Re: Received message larger than max error

['Sanjay Pujare' via grpc.io]

No idea. It comes from here
https://github.com/grpc/grpc/blob/master/include/grpc/impl/grpc_types.h#L181
but I don't know the source of that default.

On Thu, Aug 17, 2023 at 1:35 PM Chandra Shekhar  wrote:

> Thanks sanjay. You are right its more of an audio server issue than grpc.
> Any pointers why the channel size is set at 4 mb default ? any good
> optimization reasons ?
> Thanks and Regards,
> Shekhar
>
>
> On Wed, Aug 16, 2023 at 10:53 PM 'sanjay...@google.com' via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> I think your question should be directed to the team of audio server
>> software you are using rather than gRPC. If you think this is really a gRPC
>> issue please provide more details.
>>
>> On Thursday, August 10, 2023 at 3:09:26 PM UTC-7 Chandra Shekhar wrote:
>>
>>> I have fixed the issue by setting the grpc.max_message_length = -1 in
>>> stearming audioplayer server instance here
>>>
>>>
>>> audio2face-2023.1.1\exts\omni.audio2face.player\omni\audio2face\player\scripts\streaming_server\server.py.
>>>
>>> not sure why the grpc.sever as was intialized at 4 mb default
>>> grpc.mesage lenght. It would make it unsuitable for sending the audio data.
>>> Is there any way we can push the audio in compressed format mp3 ?
>>>
>>>
>>> On Thursday, 10 August 2023 at 21:57:02 UTC+5:30 Chandra Shekhar wrote:
>>>
 I am facing this issue. The message size I am pushing to is bigger
 (13417774 vs. 4194304).

 Message=<_InactiveRpcError of RPC that terminated with:
 status = StatusCode.RESOURCE_EXHAUSTED
 details = “Received message larger than max (13417774 vs. 4194304)”
 debug_error_string = "UNKNOWN:Error

 push_audio_track
 response = stub.PushAudio(request)
 push_audio_track(a2f_url, wavarr, sample_rate, a2f_avatar_instance)

 I tried fixing it by creating a grpc channel with max send/receive
 message length of unlimited (-1). while creating the channel.
 ('grpc.max_message_length', -1), ('grpc.max_send_message_length', -1),
 ('grpc.max_receive_message_length', -1)

 But it doesnt work. I guess I need to set these values at the grpc
 server side as well  ? cant find where to set this inside audio2face.

 Tried using push_audio_track and push_audio_track_stream as well. Error
 remains the same.

 Any help on this would be much appreciated

 --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "grpc.io" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/grpc-io/ePa4XBKbVL8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> grpc-io+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/grpc-io/cfe3477e-498f-4c15-a446-2e090159d213n%40googlegroups.com
>> 
>> .
>>
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6ixvdh08LgUBP2A8k-rx%3Das-h1K0a1VUuJN-u7Wu-NO-A%40mail.gmail.com.

Re: [grpc-io] Re: Java: Geeting error when trying to connect the gRPC service on dev environment .

['Sanjay Pujare' via grpc.io]

Thanks. Copying @grpc.io  for wider
distribution...

On Thu, Jul 13, 2023 at 10:47 AM Jigar Tailor  wrote:

> Hey Sanjay,
> Thanks for reaching out.
> So that was a versioning problem of grpc dependencies.
> The 'transitive dependencies'that we can not see on build.gradle but only
> in the library those weren't up to date with other dependencies of grpc. So
> I upgraded all to the latest version. And it resolved my issue.
>
> On Thu, Jul 13, 2023 at 6:51 PM 'sanjay...@google.com' via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> Do you have a stack trace? Also which version of grpc-java are you using?
>> Hopefully all your jars are the same version?
>>
>> On Thursday, July 13, 2023 at 12:33:32 AM UTC-7 Jigar Tailor wrote:
>>
>>> Hello everyone,
>>> please assist me with the below problem..
>>> I am getting the below error when trying to connect the gRPC service on
>>> the dev environment.
>>> *java.util.ServiceConfigurationError: io.grpc.ManagedChannelProvider:
>>> io.grpc.netty.NettyChannelProvider Unable to get public no-arg constructor*
>>>
>>> I am using the below code to create the channel and then create the stub.
>>> public static ManagedChannel channel = ManagedChannelBuilder
>>> .forTarget("dev")
>>> .useTransportSecurity()
>>> .build();
>>>
>>> public static PayoutServiceGrpc.PayoutServiceBlockingStub userStub =
>>> PayoutServiceGrpc.newBlockingStub(channel);
>>>
>>> I have dev URL only not a port. So that's why I am using ".forTarget"
>>> method.
>>>
>>> One weird thing is in my another project the below code is working
>>> perfectly and connecting gRPC services on dev environment but same code is
>>> not working for my above project.
>>> static ManagedChannel channel = Grpc
>>> .newChannelBuilder("dev", TlsChannelCredentials.create())
>>> .build();
>>>
>>> public static PayoutServiceGrpc.PayoutServiceBlockingStub userStub =
>>> PayoutServiceGrpc.newBlockingStub(channel);
>>>
>>> Please help me. Thanks in advance.
>>>
>> --
>> 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 grpc-io+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/grpc-io/052e2816-e1ac-4679-a5c3-9c238cde8032n%40googlegroups.com
>> 
>> .
>>
>
>
> --
>
> *Kind Regards,*
>
> *Jigar Tailor*
>
> *Senior QA Engineer*
>
> M. +27 61 376 4578 <+27%2061%20376%204578>
>
> M. +27 81 371 9689 <+27%2081%20371%209689>
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6gjivD2NK6MdSt7%2BZdoPN3aZ_8gDKigvNDx%2BjEPEQBoXw%40mail.gmail.com.

Re: [grpc-io] Grpc does not reconnect

['Sanjay Pujare' via grpc.io]

Which gRPC language library are you using - on the client and server side?

On Mon, Jul 10, 2023 at 1:53 PM Jgm  wrote:

> Hello everyone,
>
> I am facing a problem with gRPC and microservices. When sending a request
> from "Service A" to "Service B," if the connection between them is lost,
> "Service A" sometimes fails to reconnect to "Service B" without any
> explicit error. Consequently, the messages remain stuck, and the gRPC
> continues retrying. It appears that the issue might be related to resolving
> the DNS of "Service B," causing the request to get stuck. Also, I added a
> deadline option, sometimes it works and sometimes it doesn't
>
> Is there a solution to this problem?
>
> Config file:
> return {
> transport: Transport.GRPC,
> options: {
> maxReceiveMessageLength: 99 * 1024 * 1024,
> maxSendMessageLength: 99 * 1024 * 1024,
> url: url,
> keepalive: {
> 'keepaliveTimeMs': 6,
> 'keepaliveTimeoutMs': 2,
> 'keepalivePermitWithoutCalls': 1,
> },
> channelOptions: {
> "grpc.max_connection_age_ms": 3,
> "grpc.max_connection_age_grace_ms": 1,
> "grpc.lb_policy_name": "round_robin",
> "grpc.service_config": JSON.stringify({loadBalancingConfig: [{ round_robin
> : {} } ] } )
> }
> },
> };
>
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/dd6578b9-cb4f-4e3d-829c-90c8df1021een%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6gU5ySrhHsnO96fcYd82iDdObaM4bvR%3DF_6mrWL9FNCwg%40mail.gmail.com.

Re: [grpc-io] Re: Some gRPC releases are missing in Maven Central

['Sanjay Pujare' via grpc.io]

No. Based on my understanding of the CVEs, those vulnerabilities only exist
in the grpc C/C++ code base so there is no question of releasing patches
for grpc Java.

On Tue, Jul 4, 2023 at 3:02 AM Yaroslav Brahintes 
wrote:

> Thanks, my bad
>
> Is there a chance those security patches will be release for java version
> as well 1.54.2 and 1.52.2?
>
> On Sunday, 18 June 2023 at 18:46:38 UTC+3 sanjay...@google.com wrote:
>
>> Your links to v1.52.2 
>>  and v1.54.2  are for
>> the releases of grpc core (C/C++). For grpc-java (which is what you will
>> find on Maven central) you can find the releases at
>> https://github.com/grpc/grpc-java/releases. The "Grpc core" in Maven
>> central is just the grpc-core artifact of grpc-java and not to be confused
>> with the grpc core repository for C/C++.
>>
>> On Saturday, June 17, 2023 at 9:46:54 AM UTC-7 Yaroslav Brahintes wrote:
>>
>>> *Some gRPC releases are missing in Maven Central
>>> . For example:*
>>>
>>>- CVE-2023-32731  fixes
>>>that had been released in v1.54.2
>>>
>>>- CVE-2023-1428  fixes
>>>that had been released in v1.52.2
>>>
>>>
>>> Wondering if there's a specific reason why we shouldn't publish them to
>>> Maven? Also, could you recommend a good place for us to pull fixed patch
>>> versions without needing to upgrade minor versions
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "grpc.io" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/grpc-io/Y81gl6AP3Qw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/1c0d755c-6ef7-4ccb-a238-2bd9bb9e1824n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6j5yC067Hoth6QpdNPyCT29f_0VCWY4w8yWwfjT4SUdSA%40mail.gmail.com.

Re: [grpc-io] Retries and deadlines

['Sanjay Pujare' via grpc.io]

Yes. Check this out
https://github.com/grpc/proposal/blob/master/A6-client-retries.md#maximum-number-of-retries

"gRPC's call deadline applies across all attempts for a given RPC. For
example, if the specified deadline for an RPC is July 23 9:00:00pm PDT the
operation will fail after that time regardless of how many attempts were
configured or attempted."

On Tue, Jun 27, 2023 at 10:22 AM Aleh Linkin  wrote:

> Hello.
> Am I right that there is only one deadline per request for all retries?
> Are there any way to set deadline per each retry?
>
> Thank you.
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/1d325922-8398-4613-9543-cd84de35bc8fn%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hRZVtXEn%2BBaQW%3DqLjDDLci0sa2ssmE%3DJw_QL9ZoZ%3Dksg%40mail.gmail.com.

Re: [grpc-io] Re: Proxyless gRPC services in Istio mesh

['Sanjay Pujare' via grpc.io]

(adding grpc.io group back)

On Wed, May 24, 2023 at 2:57 PM Wesley Hartford 
wrote:

> Hi,
>
> My suggestion that the connection was falling back to insecure was not
> evidence based, I'm still trying to wrap my head around how all this is
> working.
>

Okay.


>
> The target address on the client side is using the xds:/// prefix.
>
> I've enabled trace level logging on the io.grpc.xds logger but I'm not
> seeing any additional log messages, have I missed something? I'm using
> slf4j and logback and have the SLF4JBridgeHandler installed.
>

The code uses Java util logging so you can just something like
-Djava.util.logging.config.file=/logging.properties in your Java invocation
command line and enable the logger for io.grpc.xds  .


>
> The grpc-bootstrap.json file seems reasonable, though I don't know just
> what it all means (I've attached the content). The three pem files
> referenced in certificate_providers point to real files containing
> apparently valid PEM content.
>
> You've mentioned a couple times enabling vs. disabling mTLS, are you
> referring to some specific setting on the client and/or server, or in istio
> somewhere? My understanding has been that with the Xds server and channel,
> both will use mTLS unless I specifically set the mtls mode to DISABLE in a
> PeerAuthentication resource, which I haven't done. I've experimented with
> mtls mode set to PERMISSIVE and STRICT. Is the problem something as simple
> as not enabling mTLS somewhere?
>

In your first post you said "I got everything working without too much
trouble ... ... When I configure Istio to enforce STRICT mTLS..." I got the
impression that you got everything working in plaintext (without enabling
mTLS) and then you enabled mTLS via Istio which is when you saw connection
problems. I was just referring to the same - you enable mTLS in Istio
security policy.

I suggest couple of additional tests to troubleshoot this:

- instead of using Xds Channel and Server credentials use the Tls Channel
and Server credentials with the same files provided by Istio (under
/var/lib/istio/data). You can check out the doc at
https://grpc.github.io/grpc-java/javadoc/io/grpc/TlsChannelCredentials.html
and
https://grpc.github.io/grpc-java/javadoc/io/grpc/TlsServerCredentials.html
. Note that even if you are using XDS for load balancing, service discovery
you can use Tls credentials for security.

- if you can try a Golang (or C++) example with your Istio setup and verify
mTLS is working with those examples.

Hope that helps.



>
> Thanks again,
>
> Wesley
>
> On Wed, May 24, 2023 at 10:27 AM 'sanjay...@google.com' via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> On Wednesday, May 24, 2023 at 8:41:20 AM UTC-7 Wesley Hartford wrote:
>>
>> Thanks for getting back to me, Sanjay. As far as I can tell, my client
>> and server are both using the appropriate Xds credentials:
>> The client code is at
>> https://github.com/wfhartford/kotlin-grpc-xds/blob/18598a7e9210be7265bc753b136cb424d087ab77/client/src/main/kotlin/ca/cutterslade/kotlingrpcxds/client/main.kt#L26
>>   Grpc.newChannelBuilder(targetUrl,
>> XdsChannelCredentials.create(InsecureChannelCredentials.create())).build()
>>
>> The server code is at
>> https://github.com/wfhartford/kotlin-grpc-xds/blob/18598a7e9210be7265bc753b136cb424d087ab77/server/src/main/kotlin/ca/cutterslade/kotlingrpcxds/server/main.kt#L45
>>   XdsServerBuilder.forPort(8443,
>> XdsServerCredentials.create(InsecureServerCredentials.create()))
>>
>> The insecure credentials provided to both a fallback, and it looks like
>> the sample you linked is doing the same thing.
>>
>>
>> Yes, you are right - Xds credentials are being correctly used so that's
>> not an issue.
>>
>> I'm not sure why, but I'm guessing that the secure connection is failing
>> and it is falling back to insecure.
>>
>>
>> No, that cannot be the case. As described here
>> https://github.com/grpc/proposal/blob/master/A29-xds-tls-security.md#programming-api
>> fallback credentials are *not* meant to be used when secure connection
>> fails. If you suspect that's happening can you provide some evidence (logs
>> etc)?
>>
>>
>> Based on the example you linked, the only other requirement is that the
>> GRPC_XDS_BOOTSTRAP environment variable is set, which is being done by
>> the istio sidecar; kubectl describe pod shows that both the client and
>> server containers have two environment variables injected:
>>   GRPC_XDS_EXPERIMENTAL_SECURITY_SUPPORT:  true
>>   GRPC_XDS_BOOTSTRAP:
>>  /etc/istio/proxy/grpc-bootstrap.json
>>
>>
>> The bootstrap file (and the GRPC_XDS_BOOTSTRAP environment variable) is
>> required not just for security but overall XDS support. Based on your
>> observations in the first email it looks like client and server are able to
>> communicate based on xds configuration so that part must be working. Just
>> to confirm your client did use the "xds:///" prefix to access your service,
>> right?
>>
>> If you are certain that XDS is working 

Re: [grpc-io] Re: Connection leak on GRPC Java client

['Sanjay Pujare' via grpc.io]

Hmmm, so what you are saying is that the current logic assumes that an
"idle" connection is to be closed from the server side and only then the
client side will perform the corresponding clean up.

Are you able to see (say with netstat) that connections are getting leaked
since the client never closes them? And on these connections there are no
outstanding RPCs?

On Sat, Apr 29, 2023 at 1:23 AM Arthur Naseef  wrote:

> The POC project I linked can be used to see that the client never
> initiates a close - at least for the Netty client code.  So a faulty
> server/proxy/gateway can cause the client to leak connections
> indefinitely.  Digging through the GRPC + Netty code, I did not find any
> path that closes the connection except when the socket close is seen by the
> client.
>
> Trying with the OK HTTP implementation, it's better, but I still am
> running into a problem that the POC does not reproduce.
>
> Art
>
>
> On Friday, April 28, 2023 at 12:03:21 PM UTC-7 Yuri Golobokov wrote:
>
>> Yes, it should close. But I'm not sure if the client or the nginx
>> initiates the closing.
>>
>> On Fri, Apr 28, 2023 at 10:20 AM Arthur Naseef  wrote:
>>
>>> Should the connection close after all calls are complete, or have failed
>>> to start?
>>>
>>> Art
>>>
>>>
>>> On Friday, April 28, 2023 at 9:06:55 AM UTC-7 Yuri Golobokov wrote:
>>>
 GOAWAY just prevents new streams(calls) from being started on the
 connection. If you have live streams on the connection it will stay open
 until all calls are completed.

 On Fri, Apr 28, 2023 at 8:44 AM Arthur Naseef 
 wrote:

> Let me clarify one point - I was expecting the client to close the
> connection after the GOAWAY.  Is there a reason to leave the connection
> open after that point?
>
> Art
>
>
> On Friday, April 28, 2023 at 8:42:58 AM UTC-7 Arthur Naseef wrote:
>
>> Thank you for the response.  we are aware of the semantics, and they
>> do as advertised - the Channel goes into IDLE on the GOAWAY.  However, 
>> the
>> CONNECTION itself lingers indefinitely.  So every time we get a GOAWAY 
>> from
>> the server, we leak a connection - until that connection is closed by the
>> server itself.  I was expecting the connection to close after receiving 
>> the
>> GOAWAY.
>>
>> We call getState with true as a means of ensuring the client does its
>> best to keep the connection to the server.  The README.md in the POC
>> project explain why.  In short - the server pushes messages to the client
>> (via GRPC stream), the server cannot initiate the connection to the 
>> client,
>> and the client does not know when the server will send messages.  So, the
>> client does it's best to keep the connection to the server active at all
>> times.
>>
>> Art
>>
>> On Friday, April 28, 2023 at 2:13:58 AM UTC-7 sanjay...@google.com
>> wrote:
>>
>>> Take a look at
>>> https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md
>>> - it says "...channels that receive a GOAWAY when there are no active or
>>> pending RPCs should also switch to IDLE..."
>>>
>>> Also according to
>>> https://github.com/grpc/grpc-java/blob/master/api/src/main/java/io/grpc/ManagedChannel.java#L78
>>> if you call `getState` with `true` then "the channel will try to make a
>>> connection if it is currently IDLE ". And that might explain why your
>>> `getState` call itself causes a new connection to be created. I haven't
>>> looked at your code in detail but do you need to call `getState` with
>>> `true`? Can you try with `false` ?
>>>
>>>
>>>
>>>
>>>
>>> On Friday, April 28, 2023 at 3:13:37 AM UTC+5:30 Arthur Naseef wrote:
>>>
 I am running into an issue with the GRPC Java client in which the
 client leaks connections over time.  Reading through the grpc-java 
 code,
 debugging, and instrumenting has led my the following question:

- Does the netty client code ever close the connection except
when it sees the socket close intiaited externally (i.e. by the O/S 
 or the
server)?

 Here is a small project that (1) contains a description of the
 problem and some of the history related to it, and (2) can be used to
 reproduce the connection leak.

 https://github.com/artnaseef/opennms-poc-hs1384

 In brief, we see the following:

- The NGINX ingress times out a request
- The NGINX ingress sends a GOAWAY packet to the client.
- The client channel transitions to IDLE but does not close the
connection.
- The client creates a new connection for the channel, which
transitions to CONNECTING and then READY
- The list of transports for the channel 

Re: [grpc-io] Rate Limiting in GRPC

['Sanjay Pujare' via grpc.io]

- is the limit static or dynamic?
- is the limit set on the client side i.e. the limit could be enforced
completely on the client side before messages are sent out?
- so what do you want to happen when a client attempts to send a message
above the limit? Should the RPC fail at the client
side? Or should the server end the RPC with an error?
- or you don't want any RPC to fail but only throttle the message sending
until something else happens

Since your high level use case is not clear I had to ask these questions.


On Thu, Apr 27, 2023 at 6:46 PM Husain Dalroti  wrote:

> Yes, we want to limit the number of messages.
>
>
> On Tuesday, April 25, 2023 at 8:51:22 AM UTC+5:30 Sanjay Pujare wrote:
>
>> So you want to limit the number of messages in an RPC? What’s the
>> use-case?
>>
>> On Thu, Apr 20, 2023 at 2:09 PM Husain Dalroti  wrote:
>>
>>> Hi Team,
>>>
>>> We want to achieve rate limiting on the number of messages to be send by
>>> each client on particular stream at cluster level.
>>>
>>> If there is any documentation related to this , it would be much hepful.
>>>
>>> Thanks !!
>>>
>>> --
>>> 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 grpc-io+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/243899cb-1abd-4fb2-a0b0-86fe96639fa4n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/ca5303fe-dd19-48f8-94a6-96812c30e5b2n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6iKb%3DyX8b%3DATi7QviKHwYYgy4L9O3JUwLGbn8CN-BzFog%40mail.gmail.com.

Re: [grpc-io] Rate Limiting in GRPC

['Sanjay Pujare' via grpc.io]

So you want to limit the number of messages in an RPC? What’s the use-case?

On Thu, Apr 20, 2023 at 2:09 PM Husain Dalroti  wrote:

> Hi Team,
>
> We want to achieve rate limiting on the number of messages to be send by
> each client on particular stream at cluster level.
>
> If there is any documentation related to this , it would be much hepful.
>
> Thanks !!
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/243899cb-1abd-4fb2-a0b0-86fe96639fa4n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6gjBde107ghk9bBhQ8E%2BkGSVYUxvfJSMzW37hg4_t-6LQ%40mail.gmail.com.

Re: [grpc-io] Re: Add support for cross-compiling for s390x platform #9455

['Sanjay Pujare' via grpc.io]

Okay, I saw a recent comment (~around 2 weeks ago) in the PR so I thought
there was an active discussion going on. But that comment is probably from
you to indicate your interest in the PR. I suggest adding another comment
and tagging @ejona86 and the contributor saying you are blocked.

On Sun, Mar 19, 2023 at 11:20 PM Dilip Bhagavan 
wrote:

> hi Sanjay, thank you for your prompt response. Can you please point out
> what needs to be done since this is still open?
>
>  In the discussion I don't see any response from the maintainer after
> protobuf related fix has been identified.
>
> On Sat, 18 Mar 2023 at 03:40, 'sanjay...@google.com' via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> Assuming you are talking about
>> https://github.com/grpc/grpc-java/pull/9455 it is already being looked
>> at as you can see the comments in the PR.
>>
>> On Wednesday, March 15, 2023 at 11:04:30 PM UTC-7 Dilip Bhagavan wrote:
>>
>>> This PR adds the s390x packages to the maven artifacts published for
>>> this component. Can someone take a look at this PR.
>>>
>>> Regards,
>>> Dilip
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "grpc.io" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/grpc-io/Q8a9u0ebRHw/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> grpc-io+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/grpc-io/a1a625cc-a7d7-4500-ad7c-f3899b559092n%40googlegroups.com
>> 
>> .
>>
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6htxmn2a71fHR7evQF9AFzPzX-bABA3ABwhg2PwzxXXnQ%40mail.gmail.com.

Re: [grpc-io] Re: How does gRPC maintain sessions securely?

['Sanjay Pujare' via grpc.io]

> can it trust that it's talking to the same client over the same RPC?  And
if so, why?

Yes, because an RPC is an unbroken stream in an unbroken TCP connection
which is always with one specific client.

I suggest you familiarize yourself with the concepts of a http2 stream, a
TCP connection, a gRPC channel and so on.

On Sun, Mar 19, 2023 at 2:10 PM Eric Robins  wrote:

> Ok, I think I'm getting closer to understanding what I need to
> understand.  I'm admittedly being a bit loose with terminology, and I
> believe it's the instantiation and maintenance of an *RPC* on which I
> need to focus.  By default - without trying to intercept every message that
> the client sends to the server - is an RPC that has been authenticated
> initially expected to be secure throughout its lifecycle?  In other words,
> if the server authenticates the client upon RPC instantiation, can it trust
> that it's talking to the same client over the same RPC?  And if so, why?
>
> Thanks.
>
> On Friday, March 17, 2023 at 4:55:08 PM UTC-5 sanjay...@google.com wrote:
>
>> Comments inline below:
>>
>> On Friday, March 17, 2023 at 12:57:31 PM UTC-7 Eric Robins wrote:
>>
>> Ok, I have a simple POC of a bidrectional streaming RPC up in Java.  The
>> client instantiates the non-blocking message stub a single time and the
>> request and response StreamObservers are re-used throughout the
>> communication between client/server.
>>
>>
>> Yes, your observation is consistent with how a streaming RPC is works. A
>> single StreamObserver (one each on request and response side) will be used
>> throughout the life of a streaming RPC.
>>
>>
>> I confirmed in Wireshark that the same HTTP/2 stream is being reused for
>> all communications.  This is ideal and is how our organization will likely
>> implement if/when we start using gRPC.
>>
>>
>> Yes a bidirectional streaming RPC *does* mean a single HTTP/2 stream will
>> be used for that RPC and you could say is the definition of it.
>>
>>
>> Implemented on the server is an interceptor - similar to what you've
>> linked in above.
>>
>>
>> I think you are talking about the JwtServerInterceptor in
>> https://github.com/grpc/grpc-java/tree/master/examples/example-jwt-auth.
>> This interceptor gets invoked per RPC but *does not* intercept (or listen
>> to) messages in an RPC. It should be easy to modify your interceptor to
>> intercept (listen to) each incoming request message. Take a look at
>> https://github.com/grpc/grpc-java/blob/master/gcp-observability/src/main/java/io/grpc/gcp/observability/interceptors/InternalLoggingServerInterceptor.java
>> to see how the interceptor returns a SimpleForwardingServerCallListener<
>> ReqT> to intercept each (request) message in onMessage(ReqT message).
>>  You add your authorization logic there.
>>
>>
>> I'm noticing that it's only invoked once, when the channel is first
>> established.
>>
>>
>> I would like to make sure you are clear about the distinction between
>> channel, stream, message and so on. A channel is one or more TCP
>> connections and is used for multiple RPCs. Each RPC is an http2 stream and
>> consists of one or more request/response messages. What you are probably
>> trying to say is that "...it's only invoked once, when an RPC is first
>> started." Whereas what you want is an invocation per (request) message in
>> an RPC.
>>
>> Subsequent communication with the server from the client doesn't result
>> in any new hits to the interceptor.  If I don't reuse streams it will be
>> invoked every time new streams are established.  Is this expected behavior
>> - for interceptors only to fire during the first time a client makes a call
>> over a newly established stream?  If so then I come back to my original
>> question that started this thread: how would we consider the established
>> stream and channel secure, how how does the server continue to trust that
>> it's the same client with which it's communicating?
>>
>>
>> As mentioned above if you modify your server interceptor to "intercept"
>> each request message in onMessage(ReqT message) then you are set. Having
>> said that if you are trying to authorize each request message in the
>> request stream then it may not be the right model - one of the reasons is
>> there is metadata (headers) for the whole RPC and not per message so it
>> does not make sense to authorize each request message.
>>
>>
>> Thanks in advance.  If there's a more appropriate place to get ongoing
>> support for questions such as these, please let me know.
>>
>>
>> This is probably the right place for asking such questions.
>>
>>
>> Eric
>>
>> On Thursday, March 2, 2023 at 4:03:30 PM UTC-6 sanjay...@google.com
>> wrote:
>>
>> On Thursday, March 2, 2023 at 9:57:15 AM UTC-8 Eric Robins wrote:
>>
>> Thanks - this discussion is helpful.  When I mentioned interceptors I was
>> looking specifically at Java, which is likely to be the language chosen.  I
>> am however looking at this from a security perspective as an engineer
>> attempting 

[grpc-io] Re: gRPC Netty exception when using proxyless xDS based example with TLS

['Sanjay Pujare' via grpc.io]

- would you be able to share your reproducible test-case?

- could you share more of the log? I would like to see why there are
multiple calls to updateSslContext

I suspect this might be something specific about the Java control plane or
how it is used but I am not sure.



>
> -- Forwarded message -
> From: Oleg Cohen 
> Date: Thursday, February 2, 2023 at 7:22:02 PM UTC-8
> Subject: gRPC Netty exception when using proxyless xDS based example with
> TLS
> To: grpc.io 
>
>
> Greetings,
>
> I have gotten the XDS example working with Java Control Plane. When I
> added TLS-based creds, the example works correctly, but I observe the
> following execption on the gRPC xDS-based client:
>
> java.util.NoSuchElementException:
> SecurityProtocolNegotiators$ClientSdsHandler#0
>
> Below is more info on the contex where the issue occured.
>
> In the code in SecurityProtocolNegotiators class the exception occurs in
> this code segment:
>
> @Override
>
> public void updateSslContext(SslContext sslContext) {
>
> logger.log(
>
> Level.FINEST,
>
> "ClientSdsHandler.updateSslContext authority={0}, ctx.name={1}",
>
> new Object[]{grpcHandler.getAuthority(), ctx.name()});
>
> ChannelHandler handler =
>
> InternalProtocolNegotiators.tls(sslContext).newHandler(grpcHandler);
>
> // Delegate rest of handshake to TLS handler
>
> ctx.pipeline().addAfter(ctx.name(), null, handler);
>
> fireProtocolNegotiationEvent(ctx);
>
> ctx.pipeline().remove(bufferReads);
>
> }
>
> @Override
>
> public void onException(Throwable throwable) {
>
> ctx.fireExceptionCaught(throwable);
>
> }
>
> }
> Would appreciate any info on what causes the exception and whether it
> needs to be handled/ignored!
>
> Thanks,
> Oleg
>
> A20:08:52.692 [fileWatcher-0] DEBUG
> io.grpc.netty.shaded.io.netty.handler.ssl.OpenSsl - Supported protocols
> (OpenSSL): [SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3]
>
> 20:08:52.692 [fileWatcher-0] DEBUG
> io.grpc.netty.shaded.io.netty.handler.ssl.OpenSsl - Default cipher suites
> (OpenSSL): [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
> TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256,
> TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
> TLS_CHACHA20_POLY1305_SHA256]
>
> [2023-02-02 20:08:52] [FINE ] Selecting OPENSSL
>
> 20:08:52.830 [fileWatcher-0] DEBUG
> io.grpc.netty.shaded.io.netty.util.ResourceLeakDetectorFactory - Loaded
> default ResourceLeakDetector:
> io.grpc.netty.shaded.io.netty.util.ResourceLeakDetector@7cf88c53
>
> [2023-02-02 20:08:52] [FINEST ] ClientSdsHandler.updateSslContext
> authority=be-srv, ctx.name=SecurityProtocolNegotiators$ClientSdsHandler#0
>
> [2023-02-02 20:08:52] [FINEST ] ClientSdsHandler.updateSslContext
> authority=be-srv, ctx.name=SecurityProtocolNegotiators$ClientSdsHandler#0
>
> [2023-02-02 20:08:52] [FINEST ] ClientSdsHandler.updateSslContext
> authority=be-srv, ctx.name=SecurityProtocolNegotiators$ClientSdsHandler#0
>
> [2023-02-02 20:08:52] [FINEST ] [NettyClientTransport<23>:
> (be.cluster.local/127.0.0.1:50051)] WaitUntilActive started
>
> [2023-02-02 20:08:52] [FINER ] [NettyClientTransport<23>:
> (be.cluster.local/127.0.0.1:50051)] ClientSds completed
>
> 20:08:52.838 [grpc-nio-worker-ELG-1-7] WARN
> io.grpc.netty.shaded.io.netty.channel.DefaultChannelPipeline - An
> exceptionCaught() event was fired, and it reached at the tail of the
> pipeline. It usually means the last handler in the pipeline did not handle
> the exception.
>
> java.util.NoSuchElementException:
> SecurityProtocolNegotiators$ClientSdsHandler#0
>
>at
> io.grpc.netty.shaded.io.netty.channel.DefaultChannelPipeline.getContextOrDie(
> DefaultChannelPipeline.java:1073)
>
>at
> io.grpc.netty.shaded.io.netty.channel.DefaultChannelPipeline.addAfter(
> DefaultChannelPipeline.java:302)
>
>at
> io.grpc.netty.shaded.io.netty.channel.DefaultChannelPipeline.addAfter(
> DefaultChannelPipeline.java:290)
>
>at
> io.grpc.xds.internal.security.SecurityProtocolNegotiators$ClientSdsHandler$2.updateSslContext(
> SecurityProtocolNegotiators.java:220)
>
>at
> io.grpc.xds.internal.security.SslContextProviderSupplier$1.updateSslContext(
> SslContextProviderSupplier.java:70)
>
>at io.grpc.xds.internal.security.SslContextProvider$1.run(
> SslContextProvider.java:123)
>
>at
> io.grpc.netty.shaded.io.netty.util.concurrent.AbstractEventExecutor.runTask(
> AbstractEventExecutor.java:174)
>
>at
> io.grpc.netty.shaded.io.netty.util.concurrent.AbstractEventExecutor.safeExecute(
> AbstractEventExecutor.java:167)
>
>at
> io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(
> SingleThreadEventExecutor.java:470)
>
>at 

Re: [grpc-io] Re: Python: server-side abort() always throws exception on calling client-side?

['Sanjay Pujare' via grpc.io]

If you feel strongly about this, you can open an issue on
https://github.com/grpc/grpc for Python.

On Thu, Dec 29, 2022 at 12:22 AM Jens Troeger 
wrote:

> Thank you!
>
> Looking at the code for _InactiveRpcError
> 
> it does indeed inherit from RpcError
> .
> Unfortunately though, that base class doesn’t give any hint regarding the
> actual failure which, I suspect, is why subclasses and their status codes
> exist. Declaring code()
> 
>  (and
> other useful helpers) as an abstract method on RpcError would be helpful 樂
>
> On Wednesday, December 28, 2022 at 7:17:55 PM UTC+1 sanjay...@google.com
> wrote:
>
>> Check this out
>> https://grpc.github.io/grpc/python/grpc.html#grpc-exceptions
>>
>> "Raised by the gRPC library to indicate non-OK-status RPC termination."
>> (although it doesn't reference InactiveRpcError there for which I don't
>> have an answer)
>>
>> Exception is the only way to indicate an error in the RPC since returning
>> error via the return value is not possible.
>>
>>
>>
>>
>> On Wednesday, December 28, 2022 at 6:08:55 AM UTC-8 jens.t...@gmail.com
>> wrote:
>>
>>> Hello, suppose I create a request
>>>
>>> request = SomeRequest(name="Name", data=data)
>>>
>>> and send that off to the gRPC server:
>>>
>>> response = some_stub.DoStuff(request)
>>>
>>> then all works fine for grpc.Status.OK
>>> . However, it
>>> seems that any error response status causes an exception on the calling
>>> client, e.g.
>>>
>>> E   grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that
>>> terminated with:
>>> E status = StatusCode.INVALID_ARGUMENT
>>> E details = "..."
>>> E debug_error_string = "..."
>>> E   >
>>>
>>> Is that exception intended, i.e. does *any* error response *always*
>>> result in an exception here?
>>>
>>> I’m also a little befuddled by the “inactive” and I wonder if I’m
>>> missing something, or if this just odd naming?
>>>
>>> Much thanks!
>>> Jens
>>>
>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/84889b3a-945a-4163-b08c-2218e2a7f069n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6g2B6exOrbfNcN4F4CeWR6FNoO8PgH7rj2QgiozeOzSvw%40mail.gmail.com.

Re: [grpc-io] Re: Manual control flow

['Sanjay Pujare' via grpc.io]

> Thanks for helping.
>
> Is ManualFlowControlClient.java
> 
>  for
> controlling reply stream or request stream.
>

To control the response stream (from line 97). But it also does the request
stream management through the onReadyHandler (lines 77-87)


>
> I understand flowControlWindow can change the receiver buffer.
> And the sender buffer is fixed. Is there a recommended way to work around
> the fixed sender buffer?
>

Not that I am aware of. Maybe there are other ways to achieve what you want?


>
>
>
> On Wed, Dec 28, 2022 at 10:33 AM 'sanjay...@google.com' via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> On Tuesday, December 27, 2022 at 3:16:03 PM UTC-8 liuya...@gmail.com
>> wrote:
>>
>>> Hi,
>>>
>>> We want to implement some manual control flow that are aware of memory
>>> size..
>>>
>>> From this post, it seems the default client and server buffer size are
>>> pretty small.
>>> https://github.com/grpc/grpc-java/issues/9197
>>>
>>> What's the recommended way or work around to control the buffer size
>>> during the high load?
>>>
>>
>> The cited link does talk about ability to set the receiver buffer size
>> using flowControlWindow()
>> 
>>  (in
>> both NettyServerBuilder and NettyClientBuilder) although the sender buffer
>> size is fixed. Does that work?
>>
>>
>>> Another question is when OnReadyHandler will be called for bi-di
>>> streaming server?
>>>
>>> My understanding is:
>>>
>>> For client side, it gets called the client side gets some buffer because
>>> the packet got sent out over the network.
>>>
>>> For server side, I am not sure when it is called? I understand there is
>>> some buffer in server side as well. so it is called when server side's
>>> message gets consumed?
>>>
>>
>> Take a look at ManualFlowControlServer example
>> .
>> It says "The onReadyHandler will be invoked when the consuming side has
>> enough buffer space to receive more messages."
>>
>> Further down it says "Signal the request sender to send one message. This
>> happens when isReady() turns true, signaling that the receive buffer has
>> enough free space to receive more messages."
>>
>> Hope that helps.
>>
>>
>>
>>
>> --
>> 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 grpc-io+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/grpc-io/42f9f8cb-84d7-4cf0-bfef-0f133c8f5920n%40googlegroups.com
>> 
>> .
>>
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6h7EY%3D%3Ddtd9%2B39amKgDNGBPg2yPwRdOAwmdd5Ugojqdhw%40mail.gmail.com.

Re: [grpc-io] Re: bidi streaming RPC auto flow control and thread model

['Sanjay Pujare' via grpc.io]

Yes, if you call ServerBuilder.executor()

On Thu, Dec 22, 2022 at 2:29 PM y  wrote:

>
>
> On Thu, Dec 22, 2022 at 2:04 PM Sanjay Pujare 
> wrote:
>
>>
>>
>> On Thu, Dec 22, 2022 at 1:47 PM y  wrote:
>>
>>>
>>>
>>> If service a and service b are implemented on the same server, do they
>>> share the same thread pool?
>>>
>>
>> Yes. But you can provide a threadpool/executor per server :
>> ServerBuilder.executor()
>>
>
> I see. This means if I create two grpc servers in the same physical
> server, they can have different thread pools?
>
>
>>
>>
>>>
>>> On Thu, Dec 22, 2022 at 1:14 PM 'sanjay...@google.com' via grpc.io <
>>> grpc-io@googlegroups.com> wrote:
>>>

>>> Wondering if there is limited token by default for auto flow
>>> control?
>>>
>>
>> I guess there has to be a limit for backpressure to work. Are you
>> asking if it's possible to change the token limit?
>>
> Yeah. I am asking what the limit is by default. If I want to change
> it, I have to do manual flow control I suppose?
>

 It is 1 : it asks for one more request-message after receiving a
 message:  see
 https://github.com/grpc/grpc-java/blob/master/stub/src/main/java/io/grpc/stub/ServerCalls.java#L266



>
>>
>>
>>>
>>> If not, say I have 20 threads, one rpc with 20 streams with blocking
>>> onNext()  will block 20 threads?
>>>
>>
>> One rpc is one stream. Unless you are saying there are 20 incoming
>> rpc instances of the same method in which case there will be 20 streams.
>> You are right: it will take up 20 threads.
>>
>>
> Sorry for the confusion. I meant for StreamingRPC. Say one rpc client
> (one rpc method) calls onNext() 10 times. and each onNext() for the rpc
> server side is blocking. How many threads will this rpc block?
>

 All messages in a streaming RPC are strictly sequential so it will take
 only one thread on the server side. Unless a message is completely
 processed the next message in the stream is not accepted for processing.



 --
 You received this message because you are subscribed to a topic in the
 Google Groups "grpc.io" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/grpc-io/7LV3MC9Dwkg/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 grpc-io+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/grpc-io/d0de588d-ef5b-4fad-a735-5d513e4abaddn%40googlegroups.com
 
 .

>>>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6gjywijC7FhR%2BENmpMP%2BQvexe0idM9UHhSUZtweKLy01A%40mail.gmail.com.

Re: [grpc-io] Re: bidi streaming RPC auto flow control and thread model

['Sanjay Pujare' via grpc.io]

On Thu, Dec 22, 2022 at 1:47 PM y  wrote:

>
>
> If service a and service b are implemented on the same server, do they
> share the same thread pool?
>

Yes. But you can provide a threadpool/executor per server :
ServerBuilder.executor()



>
> On Thu, Dec 22, 2022 at 1:14 PM 'sanjay...@google.com' via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>>
> Wondering if there is limited token by default for auto flow control?
>

 I guess there has to be a limit for backpressure to work. Are you
 asking if it's possible to change the token limit?

>>> Yeah. I am asking what the limit is by default. If I want to change it,
>>> I have to do manual flow control I suppose?
>>>
>>
>> It is 1 : it asks for one more request-message after receiving a
>> message:  see
>> https://github.com/grpc/grpc-java/blob/master/stub/src/main/java/io/grpc/stub/ServerCalls.java#L266
>>
>>
>>
>>>


>
> If not, say I have 20 threads, one rpc with 20 streams with blocking
> onNext()  will block 20 threads?
>

 One rpc is one stream. Unless you are saying there are 20 incoming rpc
 instances of the same method in which case there will be 20 streams. You
 are right: it will take up 20 threads.


>>> Sorry for the confusion. I meant for StreamingRPC. Say one rpc client
>>> (one rpc method) calls onNext() 10 times. and each onNext() for the rpc
>>> server side is blocking. How many threads will this rpc block?
>>>
>>
>> All messages in a streaming RPC are strictly sequential so it will take
>> only one thread on the server side. Unless a message is completely
>> processed the next message in the stream is not accepted for processing.
>>
>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "grpc.io" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/grpc-io/7LV3MC9Dwkg/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> grpc-io+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/grpc-io/d0de588d-ef5b-4fad-a735-5d513e4abaddn%40googlegroups.com
>> 
>> .
>>
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6ijaGMWxRqXG_JPgWS1oPmaYMW64--Py1TtqdPFkGacpA%40mail.gmail.com.

Re: [grpc-io] Re: bidi streaming RPC auto flow control and thread model

['Sanjay Pujare' via grpc.io]

On Sun, Dec 18, 2022 at 9:34 PM y  wrote:

> Thanks for answering the question!
>
> I have one concern on blocking the onNext call.
> I assume blocking onNext call blocks grpc executor pool.
>
> Say I have a high QPS for streaming RPC, and one rpc request sends a lot
> more streams than the others, will this starve the grpc executor pool and
> block the other RPCs as well?
>

Yes, that one blocking onNext() will use one thread which won't be
available for other RPCs.


>
> Yes. I did see the manual flow control. Can you comment on the pros and
> cons of using manual vs automatic?
>

Automatic being automatic you don't have to do much but has the potential
problem of pool starvation but of course the blocked RPC anyway does not
need a thread.

Manual flow control gives you more control (using serverCallStreamObserver.
request(1) to request next etc) and you can potentially use your thread to
do your work so onNext() can return and pool available for other RPCs.


>
> Thanks again for helping out!
>
>
>
> On Sunday, December 18, 2022 at 5:11:59 PM UTC-7 sanjay...@google.com
> wrote:
>
>> Take a look at
>> https://github.com/grpc/grpc-java/tree/master/examples/src/main/java/io/grpc/examples/manualflowcontrol
>> and disableAutoRequest() for manual flow control.
>>
>> I think it is okay to block on onNext() call for automatic flow control.
>> Check this
>> https://grpc.github.io/grpc-java/javadoc/io/grpc/stub/CallStreamObserver.html#disableAutoInboundFlowControl--
>> which says "automatic flow control where a token is returned to the peer
>> after a call to the 'inbound' StreamObserver.onNext(Object)
>> 
>>  has
>> completed."
>>
>> On Friday, December 16, 2022 at 4:23:58 PM UTC-8 liuya...@gmail.com
>> wrote:
>>
>>> Hi,
>>>
>>> I am trying to use bidi streaming RPC for multiple large chunks of data.
>>>
>>> I was wondering how to flow control is done for bidi streaming java.
>>>
>>> If I want to apply backpressure from server side, can I just block on
>>> onNext() call? My understanding is this should be a grpc executor task I
>>> shouldn't block.
>>>
>>> Does this mean I have to do the manual control flow to apply back
>>> pressure and there is no default option?
>>>
>>> Thanks!
>>>
>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/bb149d94-de2f-4b79-b641-b4c03c3ae7fcn%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6g7M4ipX4qVsE-7NS%3DiD%3DJiakz5NMYp-fSpkQWyRoeOaA%40mail.gmail.com.

Re: [grpc-io] Add request message field values to context

['Sanjay Pujare' via grpc.io]

Instead of messing with interceptors (since you are not dealing with
metadata) have you considered just using methods related to context(s)?
e.g. on the server side you can just restructure your existing stub code
and do something like

public void sayHello(HelloRequest req, StreamObserver
responseObserver) {
  String resource = req.getName();

  MyCallable callable = new MyCallable(); // your server code is in MyCallable

  result = Context.current().withValue(ResourceNameKey,
resource).wrap(callable);

  responseObserver.onNext(result);

}


I think this is much easier than using an interceptor and/or delaying the
call etc. Or else you can have the client itself insert the resource name
in Metadata in which case the serverInterceptor can read that and add it to
the server context. Hopefully you know how to do that.

On Fri, Sep 23, 2022 at 8:15 AM 'Hans Wustrack' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hi all,
>
> I'm implementing a simple resource oriented API with a gRPC server. Every
> request message type will have a 'name' field (or similar) that specifies
> the resource to be operated on. I would like to add the value of that name
> field to the gRPC context on every request, so it can be used later in
> application code.
>
> As this is an action I'd like to perform on every request, a
> ServerInteceptor seemed like an appropriate place to add this bit of
> functionality. In implementing, I've taken inspiration from previous
> questions here and on the github repo:
> https://groups.google.com/g/grpc-io/c/_osH2D6L9Ck
> https://github.com/grpc/grpc-java/issues/5414
>
> Our server will only accept unary calls, so the pattern of delaying
> next.startCall() by setting a NOOP listener until we receive the first
> message seems okay for our use case. In OnMessage, we'll parse the request
> message and call Contexts.interceptCall with the necessary info from the
> request.
>
> I have a few questions about this approach:
>
> - We need to call call.request(1) to initiate the request for the first
> message (as discussed in grpc-io/c/_osH2D6L9Ck). Would this create issues
> if we need more than one ServerInterceptor of this type? I.e. we'd have
> multiple interceptors initially with NOOP listeners delaying the call and
> calling call.request(1).
>
> - I couldn't find many examples of implementing a ServerInterceptor that
> adds a piece of information from a request message to the context. Should
> we consider other ways of handling this like including the necessary values
> in Metadata or adding to context in the handlers?
>
> Thanks!
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/e6463490-403d-4140-8a37-76477541491dn%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6jr5G6xHF-zSgswGnRrgaiw9XpmEB3K2X%3D%3DmHsDZdHjPA%40mail.gmail.com.

Re: [grpc-io] how to implement Grpc health check in java/kotlin

['Sanjay Pujare' via grpc.io]

> this is what i was looking for. but why there is no mention of this class
in docs or anywhere?

Good question. You may consider contributing to https://grpc.io/ (source at
https://github.com/grpc/grpc.io) or at least report this as an issue with
suggestions about content to be added.


On Sat, Aug 27, 2022 at 10:29 PM Siddhant  wrote:

> thank you very much.
> this is what i was looking for. but why there is no mention of this class
> in docs or anywhere?
> none the less, thank you very much...
> also, i was depending on `grpc-protobuf` and `grpc-protobuff` and runtime
> `grpc-netty-shaded`, since examples are doing the same.
> it took me 10 mins to figure out it's in `grpc-services`. rn, for testing
> i used, `grpc-all` and it's working.
> but `all` is quite heavy it seems. i will only use  `grpc-services`, if
> that works.
> anyway, that's on my side... :)
>
> Many thanks,
> siddhant kumar
>
> On Sunday, August 28, 2022 at 3:28:09 AM UTC+5:30 sanjay...@google.com
> wrote:
>
>> For Java take a look at
>> https://github.com/grpc/grpc-java/blob/master/services/src/main/java/io/grpc/protobuf/services/HealthStatusManager.java
>> to see if that's what you're looking for.
>>
>>
>>
>> On Sat, Aug 27, 2022 at 9:03 AM Siddhant  wrote:
>>
>>> hi all,
>>> i am trying to add simple health check to my grpc application, but
>>> unable to
>>> the documentation are lacking any good example, maybe it's very trivial
>>> and i am just not able to understand.
>>> i followed the docs on
>>> https://cloud.google.com/blog/topics/developers-practitioners/health-checking-your-grpc-servers-gke.
>>> but i didn't understand what i need to do?
>>> 2nd,
>>> https://github.com/grpc-ecosystem/grpc-health-probe/#using-the-grpc-health-checking-protocol
>>> here it say, "Most of the languages listed above provide helper functions
>>> that hides implementation details. This eliminates the need for you to
>>> implement the Check rpc yourself." but there's nothing like
>>> HealthGrpc predefined.
>>> from https://github.com/grpc/grpc/blob/master/doc/health-checking.md do
>>> i need to declare this .proto file? i did and generated source files, but
>>> idk what to do now.
>>> i can't find any example or anything. maybe i didn't search enough, idk.
>>> it would be very helpful if someone could guide me...
>>>
>>> thank you,
>>> siddhant kumar
>>>
>>> links,
>>>
>>> https://cloud.google.com/blog/topics/developers-practitioners/health-checking-your-grpc-servers-gke
>>> https://github.com/grpc-ecosystem/grpc-health-probe/
>>>
>>> https://github.com/grpc/grpc-java/blob/master/services/src/generated/main/grpc/io/grpc/health/v1/HealthGrpc.java
>>> https://github.com/grpc/grpc/blob/master/doc/health-checking.md
>>>
>>> https://grpclib.readthedocs.io/en/latest/health.html
>>>
>>> --
>>> 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 grpc-io+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/9b1a79bb-3e2d-451f-9315-b04036a79c6bn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/5e8063e3-b7ae-4cba-97fb-d4f25fb71ba8n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hseu-1Uk-58YS%3Da0cA0%3DV2urNhFMwaY2fEhjKPU8n_6g%40mail.gmail.com.

Re: [grpc-io] how to implement Grpc health check in java/kotlin

['Sanjay Pujare' via grpc.io]

For Java take a look at
https://github.com/grpc/grpc-java/blob/master/services/src/main/java/io/grpc/protobuf/services/HealthStatusManager.java
to see if that's what you're looking for.



On Sat, Aug 27, 2022 at 9:03 AM Siddhant  wrote:

> hi all,
> i am trying to add simple health check to my grpc application, but unable
> to
> the documentation are lacking any good example, maybe it's very trivial
> and i am just not able to understand.
> i followed the docs on
> https://cloud.google.com/blog/topics/developers-practitioners/health-checking-your-grpc-servers-gke.
> but i didn't understand what i need to do?
> 2nd,
> https://github.com/grpc-ecosystem/grpc-health-probe/#using-the-grpc-health-checking-protocol
> here it say, "Most of the languages listed above provide helper functions
> that hides implementation details. This eliminates the need for you to
> implement the Check rpc yourself." but there's nothing like
> HealthGrpc predefined.
> from https://github.com/grpc/grpc/blob/master/doc/health-checking.md do i
> need to declare this .proto file? i did and generated source files, but idk
> what to do now.
> i can't find any example or anything. maybe i didn't search enough, idk.
> it would be very helpful if someone could guide me...
>
> thank you,
> siddhant kumar
>
> links,
>
> https://cloud.google.com/blog/topics/developers-practitioners/health-checking-your-grpc-servers-gke
> https://github.com/grpc-ecosystem/grpc-health-probe/
>
> https://github.com/grpc/grpc-java/blob/master/services/src/generated/main/grpc/io/grpc/health/v1/HealthGrpc.java
> https://github.com/grpc/grpc/blob/master/doc/health-checking.md
>
> https://grpclib.readthedocs.io/en/latest/health.html
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/9b1a79bb-3e2d-451f-9315-b04036a79c6bn%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6jSuNSNukrz_ECSMggeoEzQz2uqaw9y9zf4UGG%2BvrT4Gg%40mail.gmail.com.

Re: [grpc-io] gRPC endpoint behind reverse proxy - non root path

['Sanjay Pujare' via grpc.io]

> ...So the question is, is this still not possible to be done?

Correct.

You can use the gRPC service name(s) and enumerate those service names in
the reverse proxy to route gRPC traffic accordingly.

Alternatively your gRPC clients can use a different hostname (but the
traffic arrives at the same reverse proxy) and the reverse proxy can route
traffic based on the hostname.

On Thu, Aug 4, 2022 at 3:26 AM Iootu Iootu  wrote:

> I’m currently developing a simple gRPC mock server that listens on the
> same port for both HTTP requests and gRPC (HTTP/2). The solution is not
> configured with TLS and is very similar to the one here
> .
>
> This for local environment, works perfectly (for both the HTTP server and
> gRPC server). They are both accessible through localhost:8080. However, for
> productive environments we are using a reverse proxy approach, using
> HAProxy, and the service is then accessible via a non root path.
>
> Which to me, it seems very similar to this post
> . So the
> question is, is this still not possible to be done?
>
> Is routing traffic via subdomains still the only possible solution?
>
> Thanks.
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/3c13dcf9-3a1a-41f0-8bcc-2730061f7f88n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6jbb8vZ2n4A5Esb8XPDwnbaB2j-XKQxxs7wiN_3EzOEFQ%40mail.gmail.com.

Re: [grpc-io] Re: Caused by: io.grpc.netty.shaded.io.netty.handler.ssl.SslHandshakeTimeoutException: handshake timed out after 10000ms

['Sanjay Pujare' via grpc.io]

This message tells you the root cause:

Caused by: java.security.cert.CertificateException: No subject alternative
names present

Your server certificate needs to have a SAN (subject alternative name) - or
CN - that matches the server identity (either hostname or IP).  You can
read up more here https://www.rfc-editor.org/rfc/rfc6125#section-6.4


On Thu, Aug 4, 2022 at 4:49 AM VALENTINA FERRO 
wrote:

>  My tentatives to resolve this issue has not been well.
>
> Can you help me to identification of possible issue?
>
> Il giorno mar 2 ago 2022 alle ore 12:02 VALENTINA FERRO <
> valentina.ferr...@gmail.com> ha scritto:
>
>> The problem was in configuration Server Python, I resolved this issue.
>> But now I have a new issue.
>>
>> Caused by: javax.net.ssl.SSLHandshakeException: General OpenSslEngine
>> problem
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.ReferenceCountedOpenSslEngine.handshakeException(ReferenceCountedOpenSslEngine.java:1898)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.ReferenceCountedOpenSslEngine.wrap(ReferenceCountedOpenSslEngine.java:822)
>> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:564)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:1039)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.wrapNonAppData(SslHandler.java:925)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1407)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.unwrapNonAppData(SslHandler.java:1325)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.access$1800(SslHandler.java:168)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler$SslTasksRunner.resumeOnEventExecutor(SslHandler.java:1716)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler$SslTasksRunner.access$2000(SslHandler.java:1607)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler$SslTasksRunner$2.run(SslHandler.java:1768)
>> at
>> io.grpc.netty.shaded.io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
>> at
>> io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
>> at
>> io.grpc.netty.shaded.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:503)
>> at
>> io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
>> at
>> io.grpc.netty.shaded.io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>> at
>> io.grpc.netty.shaded.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>> at java.base/java.lang.Thread.run(Thread.java:833)
>> Caused by: java.security.cert.CertificateException: No subject
>> alternative names present
>> at
>> java.base/sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:142)
>> at
>> java.base/sun.security.util.HostnameChecker.match(HostnameChecker.java:101)
>> at
>> java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:452)
>> at
>> java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:426)
>> at
>> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:292)
>> at
>> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:144)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:234)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:748)
>> at
>> io.grpc.netty.shaded.io.netty.internal.tcnative.CertificateVerifierTask.runTask(CertificateVerifierTask.java:36)
>> at
>> io.grpc.netty.shaded.io.netty.internal.tcnative.SSLTask.run(SSLTask.java:48)
>> at
>> io.grpc.netty.shaded.io.netty.internal.tcnative.SSLTask.run(SSLTask.java:42)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.ReferenceCountedOpenSslEngine$TaskDecorator.run(ReferenceCountedOpenSslEngine.java:1465)
>> at
>> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler$SslTasksRunner.run(SslHandler.java:1785)
>> at
>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>> at
>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>> ... 1 more
>>
>> I think that is a problem with keys-certificate of SSL/TLS
>>
>> Il giorno lun 1 ago 2022 alle ore 19:13 'sanjay...@google.com' via
>> grpc.io  ha scritto:
>>
>>> Are you using the same Python server instance for plaintext and SSL/TLS?
>>> Don't you also have to configure the Python server to use TLS?
>>>
>>> On Monday, August 1, 2022 at 3:13:51 AM UTC-7 valentin...@gmail.com
>>> wrote:
>>>
 Hi,

 I have a Client-Java and Server python, this is my problem:
 Whitout autenthication is ok, but SSL/TLS throw 

Re: [grpc-io] Re: Caused by: io.grpc.netty.shaded.io.netty.handler.ssl.SslHandshakeTimeoutException: handshake timed out after 10000ms

['Sanjay Pujare' via grpc.io]

Okay, that seems to be a user-error and I am assuming you can take care of
it.

On Tue, Aug 2, 2022 at 3:02 AM VALENTINA FERRO 
wrote:

> The problem was in configuration Server Python, I resolved this issue. But
> now I have a new issue.
>
> Caused by: javax.net.ssl.SSLHandshakeException: General OpenSslEngine
> problem
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.ReferenceCountedOpenSslEngine.handshakeException(ReferenceCountedOpenSslEngine.java:1898)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.ReferenceCountedOpenSslEngine.wrap(ReferenceCountedOpenSslEngine.java:822)
> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:564)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:1039)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.wrapNonAppData(SslHandler.java:925)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1407)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.unwrapNonAppData(SslHandler.java:1325)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.access$1800(SslHandler.java:168)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler$SslTasksRunner.resumeOnEventExecutor(SslHandler.java:1716)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler$SslTasksRunner.access$2000(SslHandler.java:1607)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler$SslTasksRunner$2.run(SslHandler.java:1768)
> at
> io.grpc.netty.shaded.io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> at
> io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
> at
> io.grpc.netty.shaded.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:503)
> at
> io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at
> io.grpc.netty.shaded.io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.grpc.netty.shaded.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.security.cert.CertificateException: No subject alternative
> names present
> at
> java.base/sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:142)
> at
> java.base/sun.security.util.HostnameChecker.match(HostnameChecker.java:101)
> at
> java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:452)
> at
> java.base/sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:426)
> at
> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:292)
> at
> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:144)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:234)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:748)
> at
> io.grpc.netty.shaded.io.netty.internal.tcnative.CertificateVerifierTask.runTask(CertificateVerifierTask.java:36)
> at
> io.grpc.netty.shaded.io.netty.internal.tcnative.SSLTask.run(SSLTask.java:48)
> at
> io.grpc.netty.shaded.io.netty.internal.tcnative.SSLTask.run(SSLTask.java:42)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.ReferenceCountedOpenSslEngine$TaskDecorator.run(ReferenceCountedOpenSslEngine.java:1465)
> at
> io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler$SslTasksRunner.run(SslHandler.java:1785)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> ... 1 more
>
> I think that is a problem with keys-certificate of SSL/TLS
>
> Il giorno lun 1 ago 2022 alle ore 19:13 'sanjay...@google.com' via grpc.io
>  ha scritto:
>
>> Are you using the same Python server instance for plaintext and SSL/TLS?
>> Don't you also have to configure the Python server to use TLS?
>>
>> On Monday, August 1, 2022 at 3:13:51 AM UTC-7 valentin...@gmail.com
>> wrote:
>>
>>> Hi,
>>>
>>> I have a Client-Java and Server python, this is my problem:
>>> Whitout autenthication is ok, but SSL/TLS throw this from blockingStub
>>>
>>> Exception in thread "main" io.grpc.StatusRuntimeException: UNAVAILABLE:
>>> io exception
>>> Channel Pipeline: [SslHandler#0, ProtocolNegotiators$ClientTlsHandler#0,
>>> WriteBufferingAndExceptionHandler#0, DefaultChannelPipeline$TailContext#0]
>>> at
>>> io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:271)
>>> at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:252)
>>> at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:165)
>>> at grpcProtos.ServiceGrpc$ServiceBlockingStub.login(ServiceGrpc.java:316)
>>> at 

Re: [grpc-io] Re: Grouping data from different RPC methods by the same client

['Sanjay Pujare' via grpc.io]

Seems okay to me

On Tue, Jun 28, 2022 at 9:08 AM Jiayi Guo  wrote:

> The Project_ID is most often empty. I plan to store requests to both RPC
> methods in a (maybe concurrentHashMap)HashMap>, is that a
> good idea or do you see any problem with that approach?
>
> tisdag 28 juni 2022 kl. 17:57:06 UTC+2 skrev sanjay...@google.com:
>
>> I guess this is really application logic and not a gRPC issue. You say
>> "There is a Build_ID field in each request but I am not sure if it's unique
>> for each client". Can you combine this with another id say project_id
>> 
>>  to
>> make it unique?
>>
>> On Tuesday, June 28, 2022 at 12:46:03 AM UTC-7 Jiayi Guo wrote:
>>
>>> It also includes grouping messages from the same stream.
>>>
>>> tisdag 28 juni 2022 kl. 09:17:39 UTC+2 skrev Jiayi Guo:
>>>
 Hi

 I am looking for a way to group the data from multiple clients and
 store them to a database. The service (the Bazel Event Service
 )
 has 2 RPC methods, 1 unary and  1 bidirectional streaming RPC using
 blockingStub and AsyncStub. I am coding a server that should separate data
 from concurrent clients and group requests to both RPC calls together,
 probably to store them somewhere. There is a Build_ID field in each request
 but I am not sure if it's unique for each client, so is there any other way
 to do it efficiently?

 Language: Java

 Thanks!

>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "grpc.io" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/grpc-io/HTFu_G_-7vQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/b1eb5da8-a77e-4545-8776-94a716e583a4n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hHE%2BevL3zwXgbu%2BoM%2B%2B0c%3D%2BnEyz-diZsJAtKYYW1fpXg%40mail.gmail.com.

Re: [grpc-io] keep channel alive without activity

['Sanjay Pujare' via grpc.io]

Comments inline below:

On Mon, May 16, 2022 at 8:35 AM Rajat Goyal 
wrote:

> Hi Sanjay / Grpc team,
>
> I have implemented RPC based regular pings. Like I am sending some
> dummy request each minute to LB once connected from client side.
> I observed below :
> a) This method works fine if there is no request from the server side.
> This way the connection is alive for many hours without issues.
>

"request from the server side": just want to clarify what is being said.
You mean a response message since a server can only send response messages
back. Or did you mean server sending requests on a different connection to
another server?



> b) But this method doesn't work if there is some bi-directional
> request from the server. The moment it receives a response from server, the
> connections is dropped from LB after exactly 5 mins, even if I am sending a
> regular dummy request from the client side every minute.
>

Again I would like to clarify your "bi-directional request from the server"
: do you mean a bi-di RPC into the server where server is sending responses
to the client? And in such a case the LB drops the connection after 5 mins?


>
> I also checked the server logs the dummy request is being received every
> min, which means client is sending regular 1 min ping, but still LB is
> dropping the connection.
> While in case there is no response from server side, the connection is not
> dropped by LB.
>
> Can you please help me what grpc / LB might be doing in both cases ?
>

To summarize my understanding of what you are. saying: when a connection is
established through the ALB to a gRPC backend the connection stays alive
indefinitely if the client only sends a dummy RPC every minute. This dummy
RPC has a dummy request but no response (only header(s) and status code).
As soon as you send any real RPCs where the server sends any response
messages then the LB does not keep the connection alive but drops it 5
minutes after the last non-dummy RPC. Is this correct?



>
> Regards,
> Rajat
>
>
> On Tue, Jan 11, 2022 at 4:01 AM Sanjay Pujare 
> wrote:
>
>> Check this
>> https://stackoverflow.com/questions/66818645/http2-ping-frames-over-aws-alb-grpc-keepalive-ping
>>
>> "*ALB does not support the HTTP2 ping frames*."
>>
>> On Mon, Jan 10, 2022 at 12:16 PM Rajat Goyal 
>> wrote:
>>
>>> ALB is configured with idle-timeout - 5 minutes.
>>> I configured bi-di client with :
>>>  keepAliveWithoutCalls(true).keepAliveTime(90,
>>> TimeUnit.SECONDS).keepAliveTimeout(10, TimeUnit.SECONDS)
>>> while server is configured with :
>>> permitKeepAliveWithoutCalls(true).permitKeepAliveTime(1, TimeUnit.MINUTES)
>>>
>>> But I received INTERNAL: HTTP/2 error code: PROTOCOL_ERROR Received Rst
>>> Stream after exactly 5 minutes. Which looks like ALB has dropped the
>>> connection after 5 minutes.
>>>
>>> Any idea how we can keep idle connection alive ?
>>>
>>>
>>>
>>> On Mon, Jan 10, 2022 at 10:39 PM Rajat Goyal 
>>> wrote:
>>>
 Hi Sanjay,

  I see that bi-directional streamObserver object gets call back
 onError() in case of any error in network.

 Isn't that done by any heartbeat mechanism already?. If so, then
 connection at ALB should be active with these ping-pong packets ?

 Regards,
 Rajat

 On Mon, 10 Jan, 2022, 10:33 pm Sanjay Pujare, 
 wrote:

> This may probably help?
> https://grpc.io/blog/grpc-on-http2/#keeping-connections-alive ?
>
> On Mon, Jan 10, 2022 at 8:54 AM Rajat Goyal <
> rajatgoyal247...@gmail.com> wrote:
>
>> Hi,
>>
>>   Gentle reminder for any resolution for above.
>>
>> Regards,
>> Rajat
>>
>> On Sun, 9 Jan, 2022, 6:50 pm Rajat Goyal, 
>> wrote:
>>
>>> Hi,
>>>
>>>  We have a system where clients open bi-directional grpc stream
>>> to ALB, which proxies to one of active server. So
>>>
>>>  bi-di
>>> client <>  ALB  <> server
>>>
>>> In-case of any failure of connection, clients re-connects to us as
>>> we want to keep a bi-di channel open.
>>>
>>> Question is : How can we keep the channel open even if there is no
>>> activity for sometime. ALB are configured with 300 sec idle-timeout 
>>> which
>>> means it will drop the connection if no packets are exchanged in 300 
>>> sec.
>>>
>>> As we want to keep the connection open as much possible ( only
>>> re-create in-case of any issue),  and not let it die due to idle 
>>> timeout,
>>> what properties should server can client set ?
>>> Should keep-alive setting at both client & server help out ?
>>>
>>>
>>> --
>>> 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 grpc-io+unsubscr...@googlegroups.com.

[grpc-io] GRPC-Java v1.44.1 Released

['Sanjay Pujare' via grpc.io]

(Artifacts uploaded and available in maven although will take a day to show
up in search.maven.org)

(from the release notes
):
v1.44.1  Latest

Bug Fixes

   - xds: fix the validation code to accept new-style
   CertificateProviderPluginInstance wherever used (#8901
    fixes #8885
   )
   - binder: Fix a ServiceConnection leak (#8861
    closes #8726
   )
   - android: fix for app coming to foreground (#8904
    closes #8850
   )

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6j_C5Lb5%2Bm_rof1y9w%3DpyP6_jHsRT88YqGFRYgJjKAw_w%40mail.gmail.com.

Re: [grpc-io] Re: GRPC Client Server Communication

['Sanjay Pujare' via grpc.io]

The gRPC-on-gRPC tunnel including the reverse-tunnel use-case is described
in this PR https://github.com/grpc/grpc-java/pull/3987 . You may want to
look into it.

On Wed, Feb 9, 2022 at 10:37 AM 'Yuri Golobokov' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Normally gRPC client creates its own TCP connection(s) to communicate with
> a gRPC server.
> I am not aware of an option to reuse some existing TCP connection.
> Can you provide more details on problems you are trying to solve? What is
> the reasoning behind this architecture? Why do you want gRPC server to be
> on clients?
>
> On Sunday, February 6, 2022 at 10:04:43 PM UTC-8 karraka...@gmail.com
> wrote:
>
>> [image: Screenshot 2022-02-07 at 11.29.25.png]
>>
>> Hi All,
>>
>> Above is the architecture I am trying to achieve. I already have a TCP
>> connection, as shown, between TCP Server and Client. I am trying to
>> communicate GRPC client present in public network using either Django/Flask
>> to GRPC Server present in TCP Client.
>>
>> As mentioned I can have multiple clients connected to server.
>>
>> I am trying to figure out how the GRPC client communicates to GRPC
>> server.
>>
>> One thing is, as GRPC uses TCP, can I use pre-established connection
>> between TCP server and TCP Client for. GRPC communication (OR) are there
>> any other options.
>>
>> Any suggestions would be helpful.
>>
>> Thanks.
>>
>>
>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/4b950aef-059b-4efe-91b8-3f528bcfa86bn%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6j0X4%3DeVhe0iVm10dXpYANvQ7k5u82P24a_7QF5cT1fCA%40mail.gmail.com.

Re: [grpc-io] call forwarding/chaining in grpc

['Sanjay Pujare' via grpc.io]

So B is just a proxy? Have you looked into using Envoy
 which supports gRPC?

On Tue, Feb 8, 2022 at 5:32 AM Mayuresh Karandikar 
wrote:

> What is the best way to implement call forwarding/chaining using grpc.
>
> Example scenario: Client A wishes to call service in client C through
> server/client B.
> A -> B -> C.
>
> I can implement both server and client in B and manually forward the call.
> Looking to see if there is a way to do this wihout intervention from
> application logic. Something that is supported at grpc stack level.
>
> Thanks
> Mayuresh
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/e0be1e87-41d2-4621-be4a-a322abfef0d1n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6h9Fc_oeYZUsqzeCSCytByKzsB7mwtSH-4Rr%2BgvpGVbZA%40mail.gmail.com.

Re: [grpc-io] keep channel alive without activity

['Sanjay Pujare' via grpc.io]

Check this
https://stackoverflow.com/questions/66818645/http2-ping-frames-over-aws-alb-grpc-keepalive-ping

"*ALB does not support the HTTP2 ping frames*."

On Mon, Jan 10, 2022 at 12:16 PM Rajat Goyal 
wrote:

> ALB is configured with idle-timeout - 5 minutes.
> I configured bi-di client with :
>  keepAliveWithoutCalls(true).keepAliveTime(90,
> TimeUnit.SECONDS).keepAliveTimeout(10, TimeUnit.SECONDS)
> while server is configured with :
> permitKeepAliveWithoutCalls(true).permitKeepAliveTime(1, TimeUnit.MINUTES)
>
> But I received INTERNAL: HTTP/2 error code: PROTOCOL_ERROR Received Rst
> Stream after exactly 5 minutes. Which looks like ALB has dropped the
> connection after 5 minutes.
>
> Any idea how we can keep idle connection alive ?
>
>
>
> On Mon, Jan 10, 2022 at 10:39 PM Rajat Goyal 
> wrote:
>
>> Hi Sanjay,
>>
>>  I see that bi-directional streamObserver object gets call back
>> onError() in case of any error in network.
>>
>> Isn't that done by any heartbeat mechanism already?. If so, then
>> connection at ALB should be active with these ping-pong packets ?
>>
>> Regards,
>> Rajat
>>
>> On Mon, 10 Jan, 2022, 10:33 pm Sanjay Pujare, 
>> wrote:
>>
>>> This may probably help?
>>> https://grpc.io/blog/grpc-on-http2/#keeping-connections-alive ?
>>>
>>> On Mon, Jan 10, 2022 at 8:54 AM Rajat Goyal 
>>> wrote:
>>>
 Hi,

   Gentle reminder for any resolution for above.

 Regards,
 Rajat

 On Sun, 9 Jan, 2022, 6:50 pm Rajat Goyal, 
 wrote:

> Hi,
>
>  We have a system where clients open bi-directional grpc stream to
> ALB, which proxies to one of active server. So
>
>  bi-di
> client <>  ALB  <> server
>
> In-case of any failure of connection, clients re-connects to us as we
> want to keep a bi-di channel open.
>
> Question is : How can we keep the channel open even if there is no
> activity for sometime. ALB are configured with 300 sec idle-timeout which
> means it will drop the connection if no packets are exchanged in 300 sec.
>
> As we want to keep the connection open as much possible ( only
> re-create in-case of any issue),  and not let it die due to idle timeout,
> what properties should server can client set ?
> Should keep-alive setting at both client & server help out ?
>
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/532f5551-e978-467e-b71c-0031a54953bfn%40googlegroups.com
> 
> .
>
 --
 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 grpc-io+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/grpc-io/CALO6TtuVMUxHQmZMGj1wvD7r4qvRQuKd2gy0j%2B0z8b8EYdw7BA%40mail.gmail.com
 
 .

>>>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6gSsVNn67rThtbs2VkoGjFo%3DRe5nWCgNXNJ-N3L73zz8A%40mail.gmail.com.

Re: [grpc-io] keep channel alive without activity

['Sanjay Pujare' via grpc.io]

This may probably help?
https://grpc.io/blog/grpc-on-http2/#keeping-connections-alive ?

On Mon, Jan 10, 2022 at 8:54 AM Rajat Goyal 
wrote:

> Hi,
>
>   Gentle reminder for any resolution for above.
>
> Regards,
> Rajat
>
> On Sun, 9 Jan, 2022, 6:50 pm Rajat Goyal, 
> wrote:
>
>> Hi,
>>
>>  We have a system where clients open bi-directional grpc stream to
>> ALB, which proxies to one of active server. So
>>
>>  bi-di
>> client <>  ALB  <> server
>>
>> In-case of any failure of connection, clients re-connects to us as we
>> want to keep a bi-di channel open.
>>
>> Question is : How can we keep the channel open even if there is no
>> activity for sometime. ALB are configured with 300 sec idle-timeout which
>> means it will drop the connection if no packets are exchanged in 300 sec.
>>
>> As we want to keep the connection open as much possible ( only re-create
>> in-case of any issue),  and not let it die due to idle timeout, what
>> properties should server can client set ?
>> Should keep-alive setting at both client & server help out ?
>>
>>
>> --
>> 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 grpc-io+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/grpc-io/532f5551-e978-467e-b71c-0031a54953bfn%40googlegroups.com
>> 
>> .
>>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/CALO6TtuVMUxHQmZMGj1wvD7r4qvRQuKd2gy0j%2B0z8b8EYdw7BA%40mail.gmail.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6j43bytnoip4j-CgvrE3R7TQP-UmEWUO6HGgPihK9DqvQ%40mail.gmail.com.

Re: [grpc-io] Re: How to use serviceTransportFilter in GRPC JAVA Server

['Sanjay Pujare' via grpc.io]

On Mon, Aug 23, 2021 at 7:57 AM Sidhartha Thota 
wrote:

> Hi Sanjay,
>
> Yes. my requirement is that I need my server to know about a client
> connection init/termination status. Do we have any other way to accomplish
> this? Please note, I need client address when it disconnects.
>

Use TRANSPORT_ATTR_REMOTE_ADDR



> I will try once again if transportReady() is called after RPC call is
> started.
>

I am confident that if transportReady() works, then transportTerminated
will work too.


>
> On Fri, Aug 20, 2021 at 2:30 PM 'sanjay...@google.com' via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> Do you see the callback `transportReady()` being called? Pls make sure
>> `transportReady()` is called. Because of lazy init the connection may not
>> even have been created unless you sent RPCs
>>
>> Also what's your use case that you need to know about a client connection
>> init/termination status?
>>
>> On Thursday, August 19, 2021 at 12:57:26 AM UTC-7 siddhu...@gmail.com
>> wrote:
>>
>>> Hi,
>>>
>>> I am looking for a java GRPC server to know if any client (clients are
>>> c++ if it matters) connection disconnected abruptly due to network issue. I
>>> learnt from google search that GRPC java have serviceTransportFilter(
>>> https://grpc.github.io/grpc-java/javadoc/io/grpc/ServerTransportFilter.html)
>>> which can be added to ServerBuilder and the functions `transportReady`
>>> and `transportTerminated` are called when client is connected and
>>> disconnected. I added transport filter to my serverbuilder and killed by
>>> client program using `kill -9` but I don't see these method getting
>>> triggered. Am i missing anything? or my understanding about transport
>>> filter is wrong?
>>>
>>> My serverTransportFilter implementation
>>> public class GRPCServerTransportFilter extends ServerTransportFilter {
>>> private static final Logger LOG = LoggerFactory.getLogger(
>>> GRPCServerTransportFilter.class);
>>>
>>> @Override
>>> public Attributes transportReady(final Attributes transportAttrs) {
>>> LOG.info("Client connected {}", transportAttrs.toString());
>>> return transportAttrs;
>>> }
>>>
>>> @Override
>>> public void transportTerminated(final Attributes transportAttrs) {
>>> LOG.info("Client disconnected {}", transportAttrs.toString());
>>> }
>>> }
>>>
>>>
>>> NettyServerBuilder build code
>>> io.grpc.Server server server = NettyServerBuilder.forPort(port)
>>> .permitKeepAliveWithoutCalls(true)
>>> .permitKeepAliveTime(keepAliveTimeOut, TimeUnit.SECONDS)
>>> .addService(new GeyserListenerGRPCService(this::executeHandler,
>>> this::onError, this::onCompleted))
>>> .addTransportFilter(new GRPCServerTransportFilter())
>>> .build();
>>> server.start();
>>>
>>> --
>>> Thanks,
>>> Sid.
>>>
>> --
>> 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 grpc-io+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/grpc-io/a741f7c7-1c8c-4925-8a37-fdcc48c4ef4cn%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Thanks,
> Sidhartha Thota.
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6jQoqLAsKKKrtdWE%3DbvAv3j5%2BLCwq_pz1vYhwUYQA-BoQ%40mail.gmail.com.

Re: [grpc-io] forward web proxy for grpc?

['Sanjay Pujare' via grpc.io]

Envoy proxy (
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/http/http_proxy)
and NGINX support http2 so one of them might work for you.

On Thu, Jul 8, 2021 at 9:43 AM Elhanan Maayan  wrote:

> hi...
> i'm trying to create a lab with a forward web proxy that will forward http
> and grpc requests , i've tried tiny proxy buy it doesn't support http/2
> i'm not sure squid does.
>
> i'm not looking for reverse proxy, just an http proxy outwards to the
> internet
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/3f700c74-ec76-424f-b43c-2adb8ed41c5en%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6gG%2BhsCjusd-nSocte%3DKwv_c_-wb88zRG_H9pRuF93ZXw%40mail.gmail.com.

Re: [grpc-io] How to test a rpc call sent by python stub to a go grpc server

['Sanjay Pujare' via grpc.io]

Have you looked into https://grpc.github.io/grpc/python/grpc_testing.html
or using InProcess transport
https://github.com/grpc/grpc/tree/master/src/core/ext/transport/inproc using
grpc core?

On Mon, Jul 5, 2021 at 3:52 AM Johannes Hofmann  wrote:

>
> Hello,
>
> So I have created a class that is using grpc stub to talk to a go server.
> That works fine. This class does not have tests yet. For unit tests i
> would like to mock the channel and response from the go server [gobgp] so
> it may be tested without the actual grpc server running.
>
> Can you please help me to figure out how this can be done?
>
> Regards,
> Joe
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/5339d614-e7da-4525-af7a-2d68788cb169n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hbrm6Xw8BJkW8TewUyDR-O4qR8E5aQ53Y%3D3qU2ttieLQ%40mail.gmail.com.

Re: [grpc-io] Re: abstract gRPC protocol clarification: client half-closing

['Sanjay Pujare' via grpc.io]

https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#requests
mentions EOS which is described as

"For requests, EOS (end-of-stream) is indicated by the presence of the
END_STREAM flag on the last received DATA frame. In scenarios where the
Request stream needs to be closed but no data remains to be sent
implementations MUST send an empty DATA frame with this flag set."


On Sun, May 30, 2021 at 7:18 AM Piotr Morgwai Kotarbinski 
wrote:

> I've noticed that in case of the java client code, calling
> `requestObserver.onCompleted()` results in a call to `
> io.netty.handler.codec.http2.DefaultHttp2FrameWriter.writeData(...)
> `
> with `endStream` param set to `true` in case of netty, and in case of
> okHttp in a call to `io.grpc.okhttp.internal.framed.Http2.Writer.data()
> `
> with `outFinished` param set to `true`. In both cases this results in
> `END_STREAM` flag to be set, so it seems my guess was correct. However some
> confirmation from someone more familiar with the protocol internals would
> be welcomed :)
>
> Thanks!
>
> On Sunday, May 30, 2021 at 2:26:51 PM UTC+7 Piotr Morgwai Kotarbinski
> wrote:
>
>> Hi all,
>> I was reading the protocol overview here
>> https://github.com/grpc/grpc/blob/master/CONCEPTS.md#abstract-grpc-protocol
>> One thing that is unclear to me is how a streaming client signals end of
>> its stream to a server (so called 'client half-closing'). The abstract part
>> says nothing about it. My only guess that in case of HTTP/2 implementation
>> clients basically close their input stream, but not sure about it. Could
>> someone with a deep knowledge of the protocol clarify this please?
>>
>> Thanks!
>>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/87e3fc86-f3c4-4c5a-8be7-e0b773b078d1n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6jo67dbE4Px%2BoCHo1BniZ4bwm_2%3DK7Bwo-pOXNg0G9fFA%40mail.gmail.com.

Re: [grpc-io] Re: Bi-directional Streams with Multithreads-JAVA

['Sanjay Pujare' via grpc.io]

Just want to comment on the following :

> I guess bi-di streams required to be used as ping-pong. Therefore, there
could be a race condition where client or server's rate of writes is more
data read causing out of sync in stream headers.

Have you taken a look at
https://github.com/grpc/grpc-java/tree/master/examples/src/main/java/io/grpc/examples/manualflowcontrol
? It shows that bi-di processing doesn't have to be ping pong.


On Thu, May 27, 2021 at 9:31 AM nitish bhardwaj 
wrote:

> Hi Eric,
>
> Thanks for sharing this information. Unary calls works fine for me. But,
> when I switched to streams both client and server side, it starts giving
> that error message.
>
> I guess bi-di streams required to be used as ping-pong. Therefore, there
> could be a race condition where client or server's rate of writes is more
> data read causing out of sync in stream headers.
>
> Please share your thoughts.
>
> Thanks & Regards,
> Nitish
>
> On Thu, 27 May 2021, 11:03 Eric Gribkoff,  wrote:
>
>> Hi,
>>
>> It sounds like you are trying to send multiple messages for a unary RPC,
>> which results in the "Too many responses" error. The distinction between
>> unary-response and server-streaming RPC here is about the semantics of the
>> service - namely, how many responses the server can send - and not
>> performance. Both unary and streaming RPCs use streams under the hood. It
>> sounds like you may have other synchronization challenges with your
>> specific service, which would up to your application and not gRPC's stream
>> handler to enforce, but you could also consider just changing your RPC
>> service definition to specify that the server response will be streaming.
>>
>> There was also a somewhat related discussion that you might find helpful
>> on this old question on the grpc-java repository:
>> https://github.com/grpc/grpc-java/issues/6323
>>
>> Thanks,
>>
>> Eric
>>
>> On Wed, May 26, 2021 at 10:01 PM nitish bhardwaj <
>> bhardwaj.nitis...@gmail.com> wrote:
>>
>>> *NOTE*: The same code works perfectly if I switch streams to normal
>>> GRPC calls.
>>>
>>> But, to avoid extra latency, I need to use streams.
>>>
>>> On Thursday, May 27, 2021 at 10:25:55 AM UTC+5:30 nitish bhardwaj wrote:
>>>
 Hi,

 I am trying to use bi-directional streams with JAVA. Everything works
 as expected in a POC of bi-di stream where I have 1 client and server which
 reads and writes to it.

 But, it starts to break when I use the same in a mature way.

 *UseCase:* I am trying to implement gossip using grpc in Java.
 Whenever any server receives a request, it gossips to the other 2 servers
 using grpc streams. For an instance, I have 4 servers, server1, server2,
 server3 and server4. All servers have 1 client configured to connect to
 every other server.

 whenever any server receives a message, it selects the other two
 servers and transmits the message and the other server does the same.

 *Issue: *As each request would be served in a new thread by grpc, I
 get an error
 Cancelling the stream with status Status{code=INTERNAL, description=Too
 many) responses, cause=null}

 That's bcz every request is read and write to stream isn't sync as it
 might not have got a response from server stream but it has written new
 data to it on a new request.

 What can be done to overcome this problem?

 Thanks for the support!!

>>> --
>>> 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 grpc-io+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/7fe537c0-ac40-48eb-913c-5c1ad8be066cn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/CAO-rZtSWWfPRDh2usDbS%2BEuAPAxLXgHNLbdU4H8egDWufUucCA%40mail.gmail.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hzET15R5qFjZV%2BKvVRu-tSrCn6%3D53TCzS_BgYOcqMCaA%40mail.gmail.com.

Re: [grpc-io] Configure MAX_CONCURRENT_STREAMS for HTTP/2

['Sanjay Pujare' via grpc.io]

On Thu, May 20, 2021 at 5:35 PM Bill Li  wrote:

> Cool thank you!
>
> One additional question, given the application and scenario I have above,
> will setting a higher value for MAX_CONCURRENT_STREAMS help in terms of the
> throughput from server to the client?
>

Hard to say. Increasing the concurrent streams (calls) on a single
connection can result in higher throughput if there is spare capacity in
the connection that can be utilized by the concurrent streams.

On the other hand it could have an adverse impact on the throughput if the
streams are bottlenecked on that single connection when there is no spare
capacity and/or the connection has some network capacity/connectivity
issues.

It will be nice if you could share your results after experimenting
with MAX_CONCURRENT_STREAMS.


>
> Thanks,
> Bill
>
> On Thursday, 20 May 2021 at 16:34:55 UTC-4 sanjay...@google.com wrote:
>
>> On Wed, May 19, 2021 at 2:32 PM Bill Li  wrote:
>>
>>> 
>>>
>>
>>> Upon adding the block, I was able to make multiple threads executing
>>> onNext() concurrently.
>>>
>>> I am just curious about whether this is the right way of doing
>>> synchronization. From the best practice perspective, what is the best way
>>> of doing synchronization?
>>>
>>
>> Your code should work since you are synchronizing on
>> *serverCallStreamObserver* which is being used in multiple threads. I
>> can't think of anything better in this particular case.
>>
>> Is multithreading a common thing to do or recommended when calling
>>> onNext()?
>>>
>>
>> Most non-trivial applications would use multiple threads and they should
>> be able to use gRPC streams with appropriate synchronization in place (as
>> you have done above). Another (and a better?) way to do this would be to
>> use a Queue and have a single thread reading from the Queue to feed the
>> responseObserver and your producer threads feeding the Queue.
>>
>>
>>>
>>> Thanks,
>>> Bill
>>>
>>> On Wednesday, 19 May 2021 at 01:47:54 UTC-4 sanjay...@google.com wrote:
>>>
 Pls include a code snippet of what you want to do. Show how you intend
 to share "one ResponseObserver".

 On Tue, May 18, 2021 at 6:56 PM Bill Li  wrote:

> Got it, thanks!
>
> I am currently implementing a server-side streaming application. Can
> one ResponseObserver be shared by multiple threads sending response stream
> back to the client through onNext() method? Just want to confirm if there
> is a race condition in calling onNext() at the same time.
>
> On Tuesday, 18 May 2021 at 19:28:43 UTC-4 sanjay...@google.com wrote:
>
>> With NettyServerBuilder you can use maxConcurrentCallsPerConnection(int
>> maxCalls)
>> 
>>
>>
>> This is the same as setting MAX_CONCURRENT_STREAMS per connection.
>>
>> On Tue, May 18, 2021 at 3:36 PM Bill Li  wrote:
>>
>>> Hi,
>>>
>>> Does anyone know or have an example for configuring the parameter
>>> MAX_CONCURRENT_STREAMS for gRPC server written in Java?
>>>
>>> Thanks,
>>> Bill
>>>
>>> --
>>> 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 grpc-io+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/cbb2fd35-a01a-4128-879d-08cbc91049b0n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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 grpc-io+u...@googlegroups.com.
>
 To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/0eb808f0-b1e0-4b5f-86e6-ffa15b7149d8n%40googlegroups.com
> 
> .
>
 --
>>> 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 grpc-io+u...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/065aecd9-0190-4bde-8a91-aae0edc2a0e5n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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
> 

Re: [grpc-io] Configure MAX_CONCURRENT_STREAMS for HTTP/2

['Sanjay Pujare' via grpc.io]

On Wed, May 19, 2021 at 2:32 PM Bill Li  wrote:

> 
>
> Upon adding the block, I was able to make multiple threads executing
> onNext() concurrently.
>
> I am just curious about whether this is the right way of doing
> synchronization. From the best practice perspective, what is the best way
> of doing synchronization?
>

Your code should work since you are synchronizing on
*serverCallStreamObserver* which is being used in multiple threads. I can't
think of anything better in this particular case.

Is multithreading a common thing to do or recommended when calling onNext()?
>

Most non-trivial applications would use multiple threads and they should be
able to use gRPC streams with appropriate synchronization in place (as you
have done above). Another (and a better?) way to do this would be to use a
Queue and have a single thread reading from the Queue to feed the
responseObserver and your producer threads feeding the Queue.


>
> Thanks,
> Bill
>
> On Wednesday, 19 May 2021 at 01:47:54 UTC-4 sanjay...@google.com wrote:
>
>> Pls include a code snippet of what you want to do. Show how you intend to
>> share "one ResponseObserver".
>>
>> On Tue, May 18, 2021 at 6:56 PM Bill Li  wrote:
>>
>>> Got it, thanks!
>>>
>>> I am currently implementing a server-side streaming application. Can one
>>> ResponseObserver be shared by multiple threads sending response stream back
>>> to the client through onNext() method? Just want to confirm if there is a
>>> race condition in calling onNext() at the same time.
>>>
>>> On Tuesday, 18 May 2021 at 19:28:43 UTC-4 sanjay...@google.com wrote:
>>>
 With NettyServerBuilder you can use maxConcurrentCallsPerConnection(int
 maxCalls)
 


 This is the same as setting MAX_CONCURRENT_STREAMS per connection.

 On Tue, May 18, 2021 at 3:36 PM Bill Li  wrote:

> Hi,
>
> Does anyone know or have an example for configuring the parameter
> MAX_CONCURRENT_STREAMS for gRPC server written in Java?
>
> Thanks,
> Bill
>
> --
> 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 grpc-io+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/cbb2fd35-a01a-4128-879d-08cbc91049b0n%40googlegroups.com
> 
> .
>
 --
>>> 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 grpc-io+u...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/0eb808f0-b1e0-4b5f-86e6-ffa15b7149d8n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/065aecd9-0190-4bde-8a91-aae0edc2a0e5n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6h2ng_mepX29y3FOkQYSzG5eZAeAMTnbcOVHvFTRtyvZA%40mail.gmail.com.

Re: [grpc-io] Configure MAX_CONCURRENT_STREAMS for HTTP/2

['Sanjay Pujare' via grpc.io]

Pls include a code snippet of what you want to do. Show how you intend to
share "one ResponseObserver".

On Tue, May 18, 2021 at 6:56 PM Bill Li  wrote:

> Got it, thanks!
>
> I am currently implementing a server-side streaming application. Can one
> ResponseObserver be shared by multiple threads sending response stream back
> to the client through onNext() method? Just want to confirm if there is a
> race condition in calling onNext() at the same time.
>
> On Tuesday, 18 May 2021 at 19:28:43 UTC-4 sanjay...@google.com wrote:
>
>> With NettyServerBuilder you can use maxConcurrentCallsPerConnection(int
>> maxCalls)
>> 
>>
>>
>> This is the same as setting MAX_CONCURRENT_STREAMS per connection.
>>
>> On Tue, May 18, 2021 at 3:36 PM Bill Li  wrote:
>>
>>> Hi,
>>>
>>> Does anyone know or have an example for configuring the parameter
>>> MAX_CONCURRENT_STREAMS for gRPC server written in Java?
>>>
>>> Thanks,
>>> Bill
>>>
>>> --
>>> 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 grpc-io+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/cbb2fd35-a01a-4128-879d-08cbc91049b0n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/0eb808f0-b1e0-4b5f-86e6-ffa15b7149d8n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hRwKWdJunUeHcke327yQ-agKAUpcv2KpO%3DOV8W2f%2BCqw%40mail.gmail.com.

Re: [grpc-io] Configure MAX_CONCURRENT_STREAMS for HTTP/2

['Sanjay Pujare' via grpc.io]

With NettyServerBuilder you can use maxConcurrentCallsPerConnection(int
maxCalls)



This is the same as setting MAX_CONCURRENT_STREAMS per connection.

On Tue, May 18, 2021 at 3:36 PM Bill Li  wrote:

> Hi,
>
> Does anyone know or have an example for configuring the parameter
> MAX_CONCURRENT_STREAMS for gRPC server written in Java?
>
> Thanks,
> Bill
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/cbb2fd35-a01a-4128-879d-08cbc91049b0n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6gOWW1_BpNtGz6X9tYFE4rEi1g-7omNVQJ%3DRiW%2BousXpA%40mail.gmail.com.

Re: [grpc-io] grpc connections and threadpool question

['Sanjay Pujare' via grpc.io]

I'll let someone from the gRPC C++ side answer your questions.

On Thu, May 13, 2021 at 9:08 PM Jeff Steger  wrote:

>
> Hi Sanjay,
>
> I am using C++. Does this help you to clarify your below statements?
>
> Jeff
>
>
> On Thu, May 13, 2021 at 7:42 PM 'Sanjay Pujare' via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> Comments/questions below:
>>
>> On Thu, May 13, 2021 at 4:12 PM Jeff Steger  wrote:
>>
>>> Hi all,
>>>
>>> I have a quick question about grpc connections. I am running a grpc
>>> synchronous server that mostly replies to single (not streaming) requests
>>> with single (not streaming) replies.
>>>
>>
>> Which language are you using?
>>
>> I understand that each new request is handled by a thread from the grpc
>>> framework’s threadpool. I notice that for even after the request is handled
>>> and a reply is sent and processed by the client, the tcp connection between
>>> the client and server is not taken down. How long does the connection
>>> persist?
>>>
>>
>> According to this doc
>> https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md
>>
>>
>> "When there has been no RPC activity on a channel for a specified
>> IDLE_TIMEOUT, i.e., no new or pending (active) RPCs for this period,
>> channels that are READY or CONNECTING switch to IDLE.  We will use a
>> default IDLE_TIMEOUT of 300 seconds (5 minutes)."
>>
>> Is it in anyway coupled to the lifetime of the thread in the threadpool?
>>>
>>
>> The thread lifetime and connection lifetime should be unrelated.
>>
>> When does the threadpool reclaim the thread that was used to process the
>>> request? Thanks for your help!
>>>
>>
>> Depends on the gRPC language you are using.
>>
>>
>>>
>>> Jeff
>>>
>> --
>>> 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 grpc-io+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/CAA-WHu%3DfP%2BFTT5PHXMF7sE3QakXvD5VaHqEf2WYdjm2zWtz95g%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/grpc-io/CAA-WHu%3DfP%2BFTT5PHXMF7sE3QakXvD5VaHqEf2WYdjm2zWtz95g%40mail.gmail.com?utm_medium=email_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 grpc-io+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hdJfvHP3xb5tLOSotSC4JqKzxiCYYjepx8Gq%3DWprJWVQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hdJfvHP3xb5tLOSotSC4JqKzxiCYYjepx8Gq%3DWprJWVQ%40mail.gmail.com?utm_medium=email_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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6j_8eeX5eX6p6DtXBG3pNH1__ji_zCFW_PyNZUFCrNp8A%40mail.gmail.com.

Re: [grpc-io] grpc connections and threadpool question

['Sanjay Pujare' via grpc.io]

Comments/questions below:

On Thu, May 13, 2021 at 4:12 PM Jeff Steger  wrote:

> Hi all,
>
> I have a quick question about grpc connections. I am running a grpc
> synchronous server that mostly replies to single (not streaming) requests
> with single (not streaming) replies.
>

Which language are you using?

I understand that each new request is handled by a thread from the grpc
> framework’s threadpool. I notice that for even after the request is handled
> and a reply is sent and processed by the client, the tcp connection between
> the client and server is not taken down. How long does the connection
> persist?
>

According to this doc
https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md


"When there has been no RPC activity on a channel for a specified
IDLE_TIMEOUT, i.e., no new or pending (active) RPCs for this period,
channels that are READY or CONNECTING switch to IDLE.  We will use a
default IDLE_TIMEOUT of 300 seconds (5 minutes)."

Is it in anyway coupled to the lifetime of the thread in the threadpool?
>

The thread lifetime and connection lifetime should be unrelated.

When does the threadpool reclaim the thread that was used to process the
> request? Thanks for your help!
>

Depends on the gRPC language you are using.


>
> Jeff
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/CAA-WHu%3DfP%2BFTT5PHXMF7sE3QakXvD5VaHqEf2WYdjm2zWtz95g%40mail.gmail.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hdJfvHP3xb5tLOSotSC4JqKzxiCYYjepx8Gq%3DWprJWVQ%40mail.gmail.com.

Re: [grpc-io] grpc calls on activemq

['Sanjay Pujare' via grpc.io]

Take a look at how gRPC is implemented over http2 at
https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md .

That will give you some idea of how you can "persist" the relevant parts of
an http2 request as an ActiveMQ message to be executed later as a gRPC
call.

On Thu, May 13, 2021 at 5:16 AM Karan Kaira 
wrote:

>
> I am working with ActiveMQ(beginner). I want to put gRPC calls as a
> message on ActiveMQ. As soon as consumer picks a message , the gRPC in the
> message should execute.
>
> gRPC calls take parameters , so I want to understand how to send these
> parameters in the message body along with the method name/identifier , or
> if there is any another way of achieving this which is followed already?
>
> Example :
>
> ```
> someResponse response = someStub.rpcMethodName(parameter); // grpc call
> ```
>
> What I need is to store this statement in some format on activemq without
> calling the grpc now , then in the future when the consumer of activemq
> picks up the message containing this statement it should execute this gRPC
> call.
>
> Thanks.
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/dda22bd6-3f96-4a7e-80b6-24a069744f29n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hNd5PhzW_JxZsvOK4GJCa8YNLMTSXBAP0uVitcQHLwtQ%40mail.gmail.com.

Re: [grpc-io] about grpc's architecture

['Sanjay Pujare' via grpc.io]

Does this help
https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md
?

On Thu, Apr 15, 2021 at 1:58 PM Tao Wang  wrote:

> I started looking into cpp helloworld example (mostly from client side).
> Basically, client creates a channel and associated filter first (at this
> time, the connection is not established) and does a unary RPC.
>
> It seems to be confusing to me that when does client truly connects with
> the server side.
>
> I traced down to
> https://github.com/grpc/grpc/blob/master/src/core/lib/surface/call.cc#L630
> but still can not figure out (1) when the real connection is initialized
> (2) when resolver and load balancer comes into place.
>
> BTW, how does the grpc threading model works generally, it seems that a
> lot operations are done in the main thread by using exec_ctx.
>
> Any suggestion will be appreciated. Thanks!
> On Tuesday, April 13, 2021 at 5:12:29 PM UTC-4 Tao Wang wrote:
>
>> Thanks for the link. The architecture of c core is quite clear. Where do
>> you recommend to start with the source code?
>>
>> On Monday, April 12, 2021 at 6:40:53 PM UTC-4 Lidi Zheng wrote:
>>
>>> Here's a thorough talk about gRPC internals: gRPC Deep Dive – Sree
>>> Kuchibhotla & Jayant Kolhe, Google
>>> https://www.youtube.com/watch?v=S7WIYLcPS1Y
>>>
>>> On Mon, Apr 12, 2021 at 3:29 PM Tao Wang  wrote:
>>>
 Hi,

 I am trying to look into the source code of grpc. Is there any
 suggestion or documentation on gRPC's threading model or network model?

 --
 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 grpc-io+u...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/grpc-io/30946a1c-4a19-4307-9ca0-ebe5ae551ca9n%40googlegroups.com
 
 .

>>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/6c72fb97-418f-442f-8028-47bdd036bdc4n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6jz-8x%3DzkGOfSw8qhU3Oy8ofFtX8QYfNRmnpa5sBw1Ocw%40mail.gmail.com.

Re: [grpc-io] Information regarding the SSL/transport layer error handling in gRPC

['Sanjay Pujare' via grpc.io]

Which language are you going to use gRPC in?

On Wed, Apr 14, 2021 at 6:01 PM Ujjal Raj  wrote:

> Hello Team
> I have recently started using gRPC and have a simple question. Is there a
> way to know the error happening at the transport layer especially incase
> when TLS/SSL is being used ?
> if yes then how those errors  are pushed to the client application ? It is
> really important for the client to know about the error happening at the
> below layer and if interested can take some action on it. This is
> especially required  for server side implementation.
> If possible please let me know or redirect me to any tutorial.
> Thanks in advance
>
> Thanks
> Raj
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/CADGSt1s_N83c%2Bnw-s85nv0jBvtez1zemHN6PoKG6E1_fZHV2TQ%40mail.gmail.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6jU55vPj%3DqKkRNRYcbFyvpXNyAftaA-oApSXufQfueyTA%40mail.gmail.com.

Re: [grpc-io] Sending Firebase auth token over gRPC (Dart)

['Sanjay Pujare' via grpc.io]

Looking at this https://grpc.io/docs/languages/dart/basics/#creating-a-stub
which says:

> You can use CallOptions to set auth credentials (for example, GCE
credentials or JWT credentials) when a service requires them.

Have you looked into using CallOptions?


On Tue, Mar 9, 2021 at 3:19 PM Matt Stagitis  wrote:

> Hi all,
>
> I am working on a Flutter application that allows users to sign in via
> Google and Facebook using Firebase. After signing in, a user get's an auth
> token from Firebase. I'd like to send this auth token alongside each gRPC
> call so the server can authenticate the signed in user.
>
> *Is there a recommended approach for doing so from a Dart gRPC client (the
> Flutter app)?* I've dug around the docs and haven't found much, other
> than manually writing the auth token to the request's metadata (not sure if
> this is the right way to go).
>
> Thanks ahead of time!
>
> - Matt
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/f2919f4c-2cba-4021-8eab-294f7bfd5bc8n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hLBPoK_0uhxMwGpc1Yf75VuGzx_Gk0Asif3TvWkyO%2Bhg%40mail.gmail.com.

Re: [grpc-io] Can we use Rest and gRPC in together in spring-boot/java application

['Sanjay Pujare' via grpc.io]

Envoy is unnecessary if you run the gRPC server on a different port.

On Tue, Mar 9, 2021 at 12:39 AM Russell Wu  wrote:

> I think you can achieve that in many different ways, some options:
> 1. Add a service controller layer that implements the actual business
> logic between grpc/rest interface implementations and your DAO.
> 2. Use envoy to provide a rest proxy in front of grpc service
>
>
> On Tue, Mar 9, 2021 at 4:08 PM Mahesh Kanote 
> wrote:
>
>> Yes, we can do that by running grpc server on different port.
>>
>> Thanks,
>> Mahewj
>>
>> On Tue, Mar 9, 2021, 1:30 PM Pawan Shriwas 
>> wrote:
>>
>>> I am talking about the case where my spring boot application server
>>> which is right now equipped with rest interfaces, I want it to be also
>>> equipped with gRPC interfaces for same service layer so that my same
>>> micro-service support same service interface for rest and gRCP.
>>>
>>> for more understanding i have draw the case below that i need rest and
>>> grcp in my application, let me know if that is feasible.
>>>
>>> [image: Untitled Diagram (1).png]
>>>
>>>
>>> On Monday, March 8, 2021 at 9:55:37 PM UTC+5:30 sanjay...@google.com
>>> wrote:
>>>
 Yes, you can use the gRPC client for talking to gRPC services and a
 REST client for talking to REST services assuming you are talking about
 client side coexistence.

 On Mon, Mar 8, 2021 at 7:26 AM Pawan Shriwas 
 wrote:

> Hi Guys,
>
> I there any way where  we can use Rest and gRPC in together in
> spring-boot/java application.
>
> Thanks in advance.
>
>
> --
> 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 grpc-io+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/7614e847-21bc-4571-9231-c433ac6a1fadn%40googlegroups.com
> 
> .
>
 --
>>> 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 grpc-io+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/651cba87-c998-4c3e-9d0d-db36d41ddbe4n%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> 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 grpc-io+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/grpc-io/CAFgyg%3DAVO26WXTez-ZaWbw70EYx3VThaL199u9mF_geNuyt2Rg%40mail.gmail.com
>> 
>> .
>>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/CAABt8Y_Af1d%3DjbwLLCctkb3zQJzwzV95b4eQA5QgXJzoED1NFA%40mail.gmail.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6jsPUkuUiO_HW1r1mNYeD0RmJtqgSzWhhJ3n1g%3DcQRUOQ%40mail.gmail.com.

Re: [grpc-io] Can we use Rest and gRPC in together in spring-boot/java application

['Sanjay Pujare' via grpc.io]

Yes, you can use the gRPC client for talking to gRPC services and a REST
client for talking to REST services assuming you are talking about client
side coexistence.

On Mon, Mar 8, 2021 at 7:26 AM Pawan Shriwas 
wrote:

> Hi Guys,
>
> I there any way where  we can use Rest and gRPC in together in
> spring-boot/java application.
>
> Thanks in advance.
>
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/7614e847-21bc-4571-9231-c433ac6a1fadn%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6jWAZU3Uyo%3DrJUzVAsBt0_Uz8FQ8X8T_QtO4X5fWMcg1Q%40mail.gmail.com.

Re: [grpc-io] Implementing Authentication Scheme in Python

['Sanjay Pujare' via grpc.io]

Okay so the "method not found" error is unrelated to missing
call-credentials and you fixed it by fixing the proto file I assume.

I thought this doc

might
be very helpful to describe how to plumb the plugin. For how to add
metadata (i.e. the headers in your gRPC call) this
https://github.com/grpc/grpc/tree/master/examples/python/metadata  -
specifically
https://github.com/grpc/grpc/blob/master/examples/python/metadata/metadata_client.py
might be helpful?

On Sun, Feb 28, 2021 at 2:40 PM James Telzrow  wrote:

> I refactored my .proto file to resolve the "Method not found" error. Now,
> this code:
>
> def runFunc():
>  channel = grpc.insecure_channel('192.168.0.69:9998')
>  stub = grpc_pb2_grpc.GetVersionStub(channel)
>  response = stub.GetVersion(grpc_pb2.GetVersionRequest())
>  print(response.version)
>
> gives me the following error:
>
> "grpc_message":"missing 'password' rpc header value","grpc_status":16
>
> I know exactly what the problem is. As you can see in
> PasswordCallCredentials in the working example Java implementation above,
> "password" and passwordValue are being added to the header of each request.
> My code is not doing that, and I am completely at a loss as to how to do so.
>
> Can someone help me?
> On Sunday, February 28, 2021 at 3:55:21 PM UTC-5 James Telzrow wrote:
>
>> If this is the case and that functionality (and/or the functionality to
>> specially authenticate requests as in the Java code above) simply isn't
>> available in the gRPC Python API, might I have to create a sort of
>> "intermediary" in Java, that is a client to my final destination and a
>> server to my Python script, that listens for requests from my Python
>> script, sends the equivalent but properly authenticated request to the
>> server, and then returns back the results?
>>
>> And if you doubt the "Method not found" error is because of missing
>> CallCredentials, what else do you think it may be?
>>
>> On Sunday, February 28, 2021 at 1:14:33 PM UTC-5 sanjay...@google.com
>> wrote:
>>
>>> This one
>>> https://grpc.github.io/grpc/python/_modules/grpc.html#metadata_call_credentials
>>> talks about metadata call credentials which seems to be similar to what the
>>> Java client is doing. Examples of authMetadataPlugin are available at
>>> https://www.programcreek.com/python/example/113599/grpc.AuthMetadataPlugin
>>>
>>> Although I doubt the error "Method not found: GetVersion/GetVersion" is
>>> because of missing CallCredentials.
>>>
>>>
>>>
>>> On Sun, Feb 28, 2021 at 9:35 AM James Telzrow 
>>> wrote:
>>>
 Hello,

 I am continuously getting the following error when making a gRPC call:

 grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that
 terminated with:
 status = StatusCode.UNIMPLEMENTED
 details = "Method not found: GetVersion/GetVersion"
 debug_error_string =
 "{"created":"@1614530914.104036000","description":"Error received from peer
 ipv4:192.168.0.69:9998","file":"src/core/lib/surface/call.cc","file_line":1068,"grpc_message":"Method
 not found: GetVersion/GetVersion","grpc_status":12}"

 I am making the call using this bit of Python code:

 def runFunc():
  channel = grpc.insecure_channel('192.168.0.69:9998')
  stub = grpcBisq_pb2_grpc.GetVersionStub(channel)
  response = stub.GetVersion(grpcBisq_pb2.GetVersionRequest())
  print(response.version)

 However, I know that the server has a GetVersion gRPC service with a
 GetVersion endpoint that takes a GetVersionRequest, since both the client
 and server have the following in their .proto file:

 service GetVersion {
 rpc GetVersion (GetVersionRequest) returns (GetVersionReply) {
 }
 }
 message GetVersionRequest {
 }
 message GetVersionReply {
  string version = 1;
 }

 The server is written in Java (and wasn't written by me) and I wrote my
 client in Python. However, the server has an example client (also written
 in Java) that uses some sort of authentication scheme, and as of now my
 Python client isn't using any type of authentication. I'm guessing this is
 what is causing the server to return the above error. In that Java client,
 the stub is created as follows:

 public final class GrpcStubs {
  public final GetVersionGrpc.GetVersionBlockingStub versionService;
  public GrpcStubs(String apiHost, int apiPort, String apiPassword) {
   CallCredentials credentials = new
 PasswordCallCredentials(apiPassword);
   var channel = ManagedChannelBuilder.forAddress(apiHost,
 apiPort).usePlaintext().build();
   Runtime.getRuntime().addShutdownHook(new Thread(() -> {
try {
 channel.shutdown().awaitTermination(1, SECONDS);

Re: [grpc-io] Implementing Authentication Scheme in Python

['Sanjay Pujare' via grpc.io]

This one
https://grpc.github.io/grpc/python/_modules/grpc.html#metadata_call_credentials
talks about metadata call credentials which seems to be similar to what the
Java client is doing. Examples of authMetadataPlugin are available at
https://www.programcreek.com/python/example/113599/grpc.AuthMetadataPlugin

Although I doubt the error "Method not found: GetVersion/GetVersion" is
because of missing CallCredentials.



On Sun, Feb 28, 2021 at 9:35 AM James Telzrow  wrote:

> Hello,
>
> I am continuously getting the following error when making a gRPC call:
>
> grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated
> with:
> status = StatusCode.UNIMPLEMENTED
> details = "Method not found: GetVersion/GetVersion"
> debug_error_string =
> "{"created":"@1614530914.104036000","description":"Error received from peer
> ipv4:192.168.0.69:9998","file":"src/core/lib/surface/call.cc","file_line":1068,"grpc_message":"Method
> not found: GetVersion/GetVersion","grpc_status":12}"
>
> I am making the call using this bit of Python code:
>
> def runFunc():
>  channel = grpc.insecure_channel('192.168.0.69:9998')
>  stub = grpcBisq_pb2_grpc.GetVersionStub(channel)
>  response = stub.GetVersion(grpcBisq_pb2.GetVersionRequest())
>  print(response.version)
>
> However, I know that the server has a GetVersion gRPC service with a
> GetVersion endpoint that takes a GetVersionRequest, since both the client
> and server have the following in their .proto file:
>
> service GetVersion {
> rpc GetVersion (GetVersionRequest) returns (GetVersionReply) {
> }
> }
> message GetVersionRequest {
> }
> message GetVersionReply {
>  string version = 1;
> }
>
> The server is written in Java (and wasn't written by me) and I wrote my
> client in Python. However, the server has an example client (also written
> in Java) that uses some sort of authentication scheme, and as of now my
> Python client isn't using any type of authentication. I'm guessing this is
> what is causing the server to return the above error. In that Java client,
> the stub is created as follows:
>
> public final class GrpcStubs {
>  public final GetVersionGrpc.GetVersionBlockingStub versionService;
>  public GrpcStubs(String apiHost, int apiPort, String apiPassword) {
>   CallCredentials credentials = new
> PasswordCallCredentials(apiPassword);
>   var channel = ManagedChannelBuilder.forAddress(apiHost,
> apiPort).usePlaintext().build();
>   Runtime.getRuntime().addShutdownHook(new Thread(() -> {
>try {
> channel.shutdown().awaitTermination(1, SECONDS);
>} catch (InterruptedException ex) {
> throw new IllegalStateException(ex);
>}
>   }));
>   this.versionService
> = GetVersionGrpc.newBlockingStub(channel).withCallCredentials(credentials);
>  }
> }
>
> PasswordCallCredentials is defined in PasswordCallCredentials.java as
> follows:
>
> /**
> * Sets the {@value PASSWORD_KEY} rpc call header to a given value.
> */
> class PasswordCallCredentials extends CallCredentials {
>  public static final String PASSWORD_KEY = "password";
>  private final String passwordValue;
>  public PasswordCallCredentials(String passwordValue) {
>   if (passwordValue == null)
>throw new IllegalArgumentException(format("'%s' value must
> not be null", PASSWORD_KEY));
>   this.passwordValue = passwordValue;
>  }
>  @Override
>  public void applyRequestMetadata(RequestInfo requestInfo, Executor
> appExecutor, MetadataApplier metadataApplier) {
>   appExecutor.execute(() -> {
>try {
> var headers = new Metadata();
> var passwordKey = Key.of(PASSWORD_KEY,
> ASCII_STRING_MARSHALLER);
> headers.put(passwordKey, passwordValue);
> metadataApplier.apply(headers);
>} catch (Throwable ex) {
> metadataApplier.fail(UNAUTHENTICATED.withCause(ex));
>}
>});
>  }
>  @Override
>  public void thisUsesUnstableApi() {
>  }
> }
>
> If I understand correctly, PasswordCallCredentials is subclassing
> CallCredentials, and when called, it causes the key-value pair "password:
> {apiPasswordHere}" to be placed in the header of every gRPC request. If my
> understanding is wrong, please correct me.
>
> I have tested the Java client, and it works perfectly.
>
> Unfortunately, even after thoroughly searching through the documentation,
> I do not understand how to implement this in Python. I know I need to
> create a grpc.secure_channel and pass a ChannelCredentials object, but I'm
> not sure how to proceed from there. Can someone help me?
>
> --
> 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 

Re: [grpc-io] Re: (grpc-java) Detecting client network disconnect and connect

['Sanjay Pujare' via grpc.io]

Couple of links for the code snippet examples:

https://stackoverflow.com/questions/63666186/how-do-i-know-if-the-grpc-connection-has-been-lost
https://github.com/grpc/grpc-java/issues/3763#issuecomment-352487188

Hope this helps


On Tue, Feb 2, 2021 at 11:28 PM Sivarama Prasad <
sivaramaprasad1...@gmail.com> wrote:

> Hi Eric,
> Thanks for taking time and providing the document links.
>
> However can I get the code snippet for usage on notifyWhenStateChanged
> using java.
>
> Thanks
> Sivaram
>
> On Wednesday, January 20, 2021 at 5:55:12 PM UTC+5:30 ericgr...@google.com
> wrote:
>
>> I believe that
>> https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannel.html#getState-boolean-
>> and
>> https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannel.html#notifyWhenStateChanged-io.grpc.ConnectivityState-java.lang.Runnable-
>> are the APIs that you are looking for.
>>
>> Thanks,
>>
>> Eric
>>
>> On Tue, Jan 19, 2021 at 10:43 PM Sivarama Prasad 
>> wrote:
>>
>>> Please help in resolving the issue that I am facing.
>>>
>>> On Tuesday, January 19, 2021 at 12:21:28 PM UTC+5:30 Sivarama Prasad
>>> wrote:
>>>
 Greetings,

 I am working on GRPC java assignment.

 Short desc abt requirement:

 multiple client applications and single server.

 Every time client stores the message in Database and upon successful
 storage, pass on the message to grpc server and store the message in server
 database.

 So, Client database and server database has the same set of database
 records.

 Problem stmt:
 When there is a network disconnect, client is unable to connect the
 server and hence there is a mismatch in database records(client vs Server)

 I am looking for a grpc-java flag/status to know disconnect and connect
 events so that I can pic the disconnect timestamp and push all the messages
 to server to be in sync the database records.

 Please provide me code snippet , sample/example to achive this.

 Thanks in advance.
 Sivaram

>>> --
>>> 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 grpc-io+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/2324a65e-10f0-4a51-a942-5a92c80be524n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/fe4d6eb2-f191-434f-ba36-7b78eaec3d08n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6gGPXGaTvvTDnYLDwAEGedWPZzhPvPURbjvr4FwS1PgpA%40mail.gmail.com.

Re: [grpc-io] gRPC java 1.35 release

['Sanjay Pujare' via grpc.io]

The scheduled release date for 1.35.0 is Jan 12, 2021

On Mon, Jan 11, 2021 at 7:33 AM Julien Viet  wrote:

> Hi,
>
> I would like to know if there is an expected release schedule for gRPC
> java 1.35.0 .
>
> regards
>
> Julien
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/b4199f89-8e68-4fb8-8eae-6c52278bf5c7n%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6hhXBXvUPddDd-D3jftg4w7orOE2KFj7AUO8z_RCwNSEQ%40mail.gmail.com.

Re: [grpc-io] Re: gRPC - Response Construction

['Sanjay Pujare' via grpc.io]

You can get all the fields of a protobuf object using getAllFields()

(for
the source object) and then use setField()

on each field on the destination object builder.

On Sun, Jul 5, 2020 at 11:19 PM  wrote:

> But when you say "convert one builder object ... to another builder
> object" do you mean a different type? That ordinarily is not possible.
>
> Yes Different Type. Now we are reading each property from source and
> setting it in destination and building destination Object.
>
> On Monday, 6 July 2020 07:57:58 UTC+5:30, sanjay...@google.com wrote:
>>
>> Copy constructor implies copying object to the same type. You can use
>> toBuilder()
>> 
>>  on
>> the first object to get a builder that enables you to build the second
>> object with the same values.
>>
>> But when you say "convert one builder object ... to another builder
>> object" do you mean a different type? That ordinarily is not possible.
>>
>> On Saturday, July 4, 2020 at 5:11:02 AM UTC-7 viji@gmail.com wrote:
>>
>>>
>>> Recently started using gRPC -Protobuf so the question might be asked
>>> earlier as well. Sorry if im repeating it here.
>>>
>>> I have to convert one protobuf object to another protobuf object in Java.
>>>
>>> Basically response construction. In normal Java world, we can have copy
>>> constructor or BeanUtils copy properties to copy the nested set of objects
>>> to destination. Similar to that Do i have any way to convert one builder
>>> object of a protobuf to another builder object generated from protobuf file.
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "grpc.io" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/grpc-io/ESjCIz_2grc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/c04abc12-90e7-4732-b15e-a43a5f87a663o%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BPad6gq4pgzvEX%3DQ5kT7vWWriRugbyOOisVoAZNbZKn_wFzsQ%40mail.gmail.com.

[grpc-io] Re: Java: All Hedging attempt call the same server endpoint

['Sanjay Pujare' via grpc.io]

David,

Are you saying default should be "round_robin"? In case of round_robin and 
more than one endpoint being available it does behave as you expect.

On Wednesday, November 27, 2019 at 10:20:53 AM UTC-8, David M wrote:
>
> Thanks for the answer! I do not think this is a good design. The main goal 
> for hedging is to execute remote call on a different servers. Running 
> heading calls on the same server is worse that not having hedging at all.
> Is there a plan to redesign it ?
>  
>
> On Wednesday, November 20, 2019 at 4:36:33 PM UTC-8, Penn (Dapeng) Zhang 
> wrote:
>>
>> The retry/hedging attempts will always pick an currently available 
>> endpoint provided by the load balancer. If you are using pick_first load 
>> balancing (which is default), it will always provide the first endpoint if 
>> it's available. If you are using round_robin load balancing, then each 
>> retry/hedging attempts will pick next available endpoint from load 
>> balancer, but if 2 out of 3 endpoints are unreachable, it will always use 
>> the only available one. This is by design.
>>
>>
>> On Thursday, November 14, 2019 at 3:20:24 PM UTC-8, David M wrote:
>>>
>>> I am using Java gRPC version 1.24.1. When debugging some timed out 
>>> requests I found out that sometimes client calls all hedging requests ( 3 
>>> in my case) on the same server endpoint.
>>> NameResolver.Listener.onAddresses() got updated with 3 distinct 
>>> endpoints before first call was made.
>>> Is it a bug in gRPC code ? Even if 2 out of 3 servers were unreachable, 
>>> having all hedging attempts go to a single endpoint is not the best option. 
>>>
>>>
>>> status-code=DEADLINE_EXCEEDED status-description=deadline exceeded after 
>>> 958644ns. [closed=[], open=[[remote_addr=xxx.com/xxx.xxx.xxx.xxx:
>>> 3112], [remote_addr=xxx.com/xxx.xxx.xxx.xxx:3112], [remote_addr=xxx.com
>>> /xxx.xxx.xxx.xxx:3112]]]
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/c304b12a-385e-4234-b2fe-077e6dec3944%40googlegroups.com.

[grpc-io] Re: Support for abstract unix domain sockets for Linux

['Sanjay Pujare' via grpc.io]

Marcus,

4677 is the stale issue and 21278 is your PR (you had them switched). I do 
believe the feature is valuable/useful so your PR is great. 

Regarding your question about adding tests etc hopefully markdroth or 
veblush will answer them in the PR?


On Tuesday, November 26, 2019 at 11:03:38 AM UTC-8, mar...@aporeto.com 
wrote:
>
> Hi there,
>
> To improve a feature that I’m working on for my company, we require 
> support for abstract unix domain sockets. In our initial tests - all using 
> golang grpc servers and clients - it all just worked out of the box by just 
> specifying a URI like `unix:@abstract_socket_name`.
>
> However, trying to use `google_grpc` now from within envoyproxy failed. 
> After a lot of debugging and actually doing some digging, I found out that 
> there is actually no support for abstract unix sockets within the core / 
> C++ implementation of gRPC. There was an issue here which got closed 
> because it got stale: https://github.com/grpc/grpc/pull/21278 
> 
>
> Now I have already done a manual patch of gRPC and a custom compile of 
> envoy to test that I can actually make it work (and it works), however, I’d 
> ideally like to get that merged upstream of course.
>
> So I started to put a PR together here: 
> https://github.com/grpc/grpc/issues/4677
>  
> However, there is a couple of things that I'm not sure about: for example 
> where and how to add tests for it, also, with a bigger project like gRPC, 
> how can I get that PR into the right hands, etc., and also just in general: 
> is that a feature that you actually want to support in the core (imho it's 
> valuable as it is already supported in other implementations which can be 
> confusing).
>
> Cheers
> Marcus
>
>
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/8bd70aa1-1446-4a3f-9bfe-023451e24525%40googlegroups.com.

Re: [grpc-io] Re: Does grpc-java supports cert reload without restarting server?

['Sanjay Pujare' via grpc.io]

No problem. Will you be contributing your code via a PR?

Sanjay


On Tue, Feb 19, 2019 at 10:41 AM Daisy Zhu  wrote:

> Hi,
>
> I haven't verified. For me I think creating a new SslContextBuilder object
> is simpler and straightforward.
>
> -Daisy
>
> On Tuesday, February 19, 2019 at 8:57:22 AM UTC-8, sanjay...@google.com
> wrote:
>>
>> A gentle reminder for Daisy - were you able to verify?
>>
>> On Wednesday, February 13, 2019 at 10:40:50 AM UTC-8,
>> sanjay...@google.com wrote:
>>>
>>> Hi Daisy
>>>
>>> There is an issue on github
>>> https://github.com/grpc/grpc-java/issues/5335 that talks about the same
>>> thing and possibly created by you.
>>>
>>> There is a comment
>>> https://github.com/grpc/grpc-java/issues/5335#issuecomment-462531217
>>> that describes an approach to achieve this. Can you verify if it works for
>>> you?
>>>
>>> On Thursday, February 7, 2019 at 11:14:32 AM UTC-8, Daisy Zhu wrote:

 Thanks for the reply.

 Is this the document  https://grpc.io/blog/loadbalancing on round
 robin load balancer you mentioned? For cert hot rotation which way is
 recommended?

 1. round robin load balancer in client side
 2. implement hot cert reloading in sever side

 If using method 2 are there any potential issues needed to be paid
 attention to?

 Best,
 Daisy

 On Thursday, February 7, 2019 at 11:01:01 AM UTC-8, Carl Mastrangelo
 wrote:
>
> You are correct, Java doesn't support this.   However, if you are
> using the round robin load balancer in your client, you should be able to
> gracefully restart your servers with the new certificate without dropping
> any requests.
>
> On Thursday, February 7, 2019 at 6:52:46 AM UTC-8, Danesh Kuruppu
> wrote:
>>
>> Hi Daisy,
>>
>> Does grpc-java supports cert refresh without restarting server?
>>>
>>
>> AFAIK, this is not supported yet. We need to restart the server.
>> Please correct me if I am wrong.
>>
>> Thanks
>> Danesh
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "grpc.io" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/grpc-io/Yh11G6wrNtA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> grpc-io+unsubscr...@googlegroups.com.
> To post to this group, send email to grpc-io@googlegroups.com.
> 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/c7f2c95d-0a59-4ec7-8e33-d12d1bddc481%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
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/CA%2BPad6ghesJc9%2BVQLW0t0kLBPUhunskORq0yDzj0JdnkHODKTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: gRPC java client side TLS authentication using root.pem file and using username and password.

['Sanjay Pujare' via grpc.io]

Looking further it looks like an error coming from the server. You can see
for yourself by looking at
https://github.com/grpc/grpc-java/blob/master/stub/src/main/java/io/grpc/stub/ClientCalls.java
and tracing the line numbers. At this stage it is best for you to
troubleshoot this yourself. Couple of suggestions I have:

- log/print the request going out on the wire in each case (C++ and Java)
and see what is different.
- see if you can get the logs on the server (some kind of a Vendor router
you mentioned?) and see if those logs reveal anything for the error case


On Wed, Jan 23, 2019 at 1:19 PM kishore.ganipineni via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hi Sanjay,
>
> StackTrace for INVALID_ARGUMENT exception.
>
> [2019-01-23 21:16:50,523 UTC] [INFO ] pool-1-thread-1
> com.verizon.eclipse.client.OpenConfigTelemetryClient - connectivityState in
> connect:: IDLE
>
> io.grpc.StatusRuntimeException: INVALID_ARGUMENT
> at
> io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:233)
> at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:214)
> at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:139)
> at
> .proto_compiled.telemetry.OpenConfigGrpc$OpenConfigBlockingStub.get(OpenConfigGrpc.java:373)
> at
> OpenConfigTelemetryClient.get(OpenConfigTelemetryClient.java:187)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> [2019-01-23 21:16:51,252 UTC] [ERROR] pool-1-thread-1
> OpenConfigTelemetryClient - sre.getTrailers():: Metadata()
> [2019-01-23 21:16:51,252 UTC] [ERROR] pool-1-thread-1
> OpenConfigTelemetryClient - Error Code:: INVALID_ARGUMENT
> [2019-01-23 21:16:51,252 UTC] [ERROR] pool-1-thread-1
> OpenConfigTelemetryClient - Error description:: null
> [2019-01-23 21:16:51,252 UTC] [ERROR] pool-1-thread-1
> OpenConfigTelemetryClient - Error Cause:: null
>
>
>
> On Tuesday, January 22, 2019 at 7:21:51 PM UTC-5, sanjay...@google.com
> wrote:
>>
>> Kishore: I think you should go back to using "username" instead of
>> "userId" or "usernId" and then troubleshooting the code. I also noticed
>> this catch clause in your Java code
>>
>> } catch (Exception e) {
>>
>> metadataApplier.fail(Status.UNAUTHENTICATED.withCause(e));
>> e.printStackTrace();
>> }
>>
>> where your code is generating the UNAUTHENTICATED error and not gRPC
>> layer or the server. That could also be a source of confusion.
>>
>> Looking at
>> https://github.com/grpc/grpc-java/blob/master/core/src/main/java/io/grpc/Metadata.java
>> there are multiple places where it calls checkArgument (which throws the
>> INVALID_ARGUMENT exception) for different reasons. Generate a stack trace
>> again and see where it is coming from.
>>
>>
>> On Tuesday, January 22, 2019 at 1:35:15 PM UTC-8, sanjay...@google.com
>> wrote:
>>>
>>> The real problem seems to be INVALID_ARGUMENT you are getting on the
>>> Java client side. If the server is expecting "username" header that needs
>>> to be sent and not something else. Let me see if I can find something about
>>> INVALID_ARGUMENT on the grpc java code side
>>>
>>> On Tuesday, January 22, 2019 at 12:54:02 PM UTC-8, haigk...@gmail.com
>>> wrote:

 Hi Sanjay,

 I tried first with "username" to copy c++ but got INVALID_ARGUMENT
 exception. When I was searching for some solutions some where I got
 "userid" after using userid instead of username INVALID_ARGUMENT gone and
 getting UNAUTHENTICATED exception.

 Yes I am printing request in Java too, below is the result
 [2019-01-22 20:28:18,574 UTC] [INFO ] pool-1-thread-1
 com.verizon.eclipse.client.OpenConfigTelemetryClient - Path List::
 [element: "/statistics/otm"]

 C++ result:
  Prefix :  --
  AsyncGet(GetRquest) =>:
  Path: "statistics" "otm"


 On Tuesday, January 22, 2019 at 12:36:50 PM UTC-5, Sanjay Pujare wrote:
>
> Hi Kishore,
>
> For encryption TLS (SSL) also works so mTLS is not needed for
> encryption.
>
> In any case the info you have provided is useful although we still
> don't have the root cause. It seems the error occurred on the server side
> (was an ExecutionException) and we can rule out mTLS related issues.
>
> In your C++ snippet you had "printGetRequest();". Can you
> insert a similar print/log 

Fwd: [grpc-io] Re: gRPC java client side TLS authentication using root.pem file and using username and password.

['Sanjay Pujare' via grpc.io]

Hi Kishore,

For encryption TLS (SSL) also works so mTLS is not needed for encryption.

In any case the info you have provided is useful although we still don't
have the root cause. It seems the error occurred on the server side (was an
ExecutionException) and we can rule out mTLS related issues.

In your C++ snippet you had "printGetRequest();". Can you insert a
similar print/log statement in the Java code and just compare the 2
requests going out?

BTW I noticed that
Your C++ code sets "username":

context.AddMetadata("username", userid);

But your Java code has typos:

Metadata.Key usernameKey =
Metadata.Key.of("usernId", Metadata.ASCII_STRING_MARSHALLER);
headers.put(usernameKey, username);

in one place and

Metadata.Key usernameKey =
Metadata.Key.of("userid", Metadata.ASCII_STRING_MARSHALLER);
headers.put(usernameKey, user);

in a different place. Why are you not using "username" here as well?


On Tue, Jan 22, 2019 at 8:47 AM kishore.ganipineni via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hi Sanjay,
>
> More specific details are needed here and you should look them up in the
> Vendor Router documentation to answer the following questions:
>
> - are certificates needed only for establishing (one-way) SSL or mTLS? I
> am assuming it is not mTLS but it is good to confirm. Note that mTLS is
> used to authenticate a client by the server.
>
>   My understanding is for encryption might be. I don't have the
> documentation right now in hand, will get it and check the documentation.
>
> - the credentials are just passed as "username" and "password" headers
> just like your C++ example shows? That should be relatively straightforward
> as shown in the Java auth examples here (
> https://github.com/grpc/grpc-java/blob/master/examples/AUTHENTICATION_EXAMPLE.md
> ).
> I suggest you use that approach - of using ClientInterceptor and adding
> headers - instead of stub.withCallCredentials().
>
> - can you provide the stack trace of UNAUTHENTICATED exception you are
> getting?
>
> I have tried the ClientInterceptor option , still getting the
> UNAUTHENTICATED exception. Below is the stacktrace.
>
> io.grpc.StatusRuntimeException: UNAUTHENTICATED
> at
> io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:233)
> at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:214)
> at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:139)
> at
> telemetry.OpenConfigGrpc$OpenConfigBlockingStub.get(OpenConfigGrpc.java:373)
> at
> OpenConfigTelemetryClient.get(OpenConfigTelemetryClient.java:208)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> [2019-01-22 16:33:27,534 UTC] [ERROR] pool-1-thread-1
> OpenConfigTelemetryClient - Error Code:: UNAUTHENTICATED
> [2019-01-22 16:33:27,534 UTC] [ERROR] pool-1-thread-1
> OpenConfigTelemetryClient - Error description:: null
> [2019-01-22 16:33:27,534 UTC] [ERROR] pool-1-thread-1
> OpenConfigTelemetryClient - Error Cause:: null
>
> *Channel Creation code:*
>
> channel = NettyChannelBuilder.forAddress(ip, port)
> .useTransportSecurity()
> .negotiationType(NegotiationType.TLS)
> .sslContext(sslContext)
> .intercept(interceptor)
> .build();
>
>
> *ClientInterceptor Code:*
>
> public  ClientCall
> interceptCall(MethodDescriptor methodDescriptor, CallOptions
> callOptions, Channel channel) {
> return new ForwardingClientCall.SimpleForwardingClientCall RespT>(channel.newCall(methodDescriptor, callOptions)) {
> @Override
> public void start(Listener responseListener, Metadata headers) {
> //callOptions.withCallCredentials(credentials);
> Metadata.Key usernameKey = Metadata.Key.of("userid",
> Metadata.ASCII_STRING_MARSHALLER);
> headers.put(usernameKey, user);
> Metadata.Key passwordKey = Metadata.Key.of("password",
> Metadata.ASCII_STRING_MARSHALLER);
> headers.put(passwordKey, pass);
> super.start(responseListener, headers);
> }
> };
> }
>
>
>
> On Tuesday, January 15, 2019 at 4:09:39 PM UTC-5, Kishore Ganipineni wrote:
>>
>> SSL/TLS