[grpc-io] gRPC-Java Netty 4.1.111+ compatibility patches 1.65.1, 1.64.2, 1.63.2 Released

['Larry Safran' via grpc.io]

Due to a change in behavior introduced at Netty 4.1.111, an optimization 
that had been done to improve processing of large numbers of small messages 
led to problems.  These 3 versions have disabled that optimization for 
versions of Netty equal to or greater than 4.1.111 allowing for gRPC Java 
to be used with those Netty versions.  

If you are using Netty versions prior to 4.1.111 you will see no change 
from these patches.

Thanks,
  Larry

-- 
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/d704fc58-f6b3-41a9-8edd-5c1e3104e77cn%40googlegroups.com.

Re: [grpc-io] Close a bidirectional RPC stream in gRPC java

['Larry Safran' via grpc.io]

Yes, this is the expected behavior.  When the server sends the completion
it then forgets about the RPC, while the client side has a more ownership
relationship so keeps track of the RPC until it is fully closed.

On Wed, Jul 10, 2024 at 9:09 PM Steven Hu  wrote:

> Hello gRPC community,
>
> I noticed some asymmetry for bidirectional RPC stream closure between RPC
> client and RPC server.
>
>- If RPC stream client sends onCompleted(),  server end will receive
>onCompleted().  It closes the stream on client->server direction. server
>could still send message to client.
>- If RPC stream server sends onCompleted(),  client end will receive
>onCompleted(). *However,  client end could no longer send messages to
>server*. It seems that the entire stream has been closed.
>
> Is this expected?
>
> --
> 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/4c4123fa-2d31-48ef-9417-beb42c3a9adbn%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/CANuT3qX55fOcg-L_BNKCLD5AmYHM5ivC35A8RKWXdEZGLokOLg%40mail.gmail.com.

Re: [grpc-io] Is there a provision in grpc-java to add new services to grpc servers during runtime

['Larry Safran' via grpc.io]

You can run multiple Server instances from the same application to get
dynamic management like that, as long as you use a different port for the
debug services and the critical services.

prodServer = Grpc.newServerBuilderForPort(50051,
InsecureServerCredentials.create())
.addService(new GreeterImpl())
.build()
.start();


  Server startDebugServer() {
  dubugServer = Grpc.newServerBuilderForPort(50052,
InsecureServerCredentials.create())
.addService(AdminInterface.getStandardServices())
.build()
.start();
  return debugServer;
  }

void shutdownDebugServer(Server debugServer) {
  debugServer.shutdownNow();
  debugServer.awaitTermination();
}

Hope that helps,
  Larry

On Tue, Jun 18, 2024 at 10:56 PM Darshan J 
wrote:

> Hi guys,
> I want to add and remove services to the grpc server without bringing down
> other services running.
>
> Usecase: Whenever I need to use grpcurl
>  or grpcdebug
>  for debugging purposes,
> these tools require like ProtoReflectionService,
> AdminInterface.getStandardServices and so on. If my server is already
> running with my critical services. How to add other services and also after
> adding new services will I be able to remove it without bringing down the
> critical services.
>
> Due to some contraints I do not wish to add it along with critical
> services during first-time server bring up only in specific ocassions like
> during debugging I would like to add it and remove when purpose is over.
>
> Thanks and Regards,
> Darshan J Gowda
>
> --
> 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/3e107efd-e7a1-4c53-8099-cea46a44n%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/CANuT3qWKxyLFugcCu7JVNm0SQqV-1DnzGY--B_FENB%2BoECdcHw%40mail.gmail.com.

Re: [grpc-io] Re: 1-2% GRPC traffic gets Dropped at scale With Service Unavailable Error

['Larry Safran' via grpc.io]

That's an over 5 year old version, can you try it with 1.64.0 and see if it
still happens.  Note that there have been a number of security updates over
the intervening years so it would be valuable just from that standpoint to
be on a relatively current version.

Thanks,
  Larry

On Wed, Jun 19, 2024 at 2:07 AM Pawan Kumar Sharma 
wrote:

> Hi Larry,
>
> I am using go1.21.0.
>
> Thanks & Regards,
> Pawan Sharma
>
> On Wed, Jun 19, 2024 at 6:09 AM Larry Safran  wrote:
>
>> Which version of grpc are you using?
>>
>> On Tue, Jun 18, 2024 at 5:34 AM 'Pawan Kumar Sharma' via grpc.io <
>> grpc-io@googlegroups.com> wrote:
>>
>>>
>>> Pawan Kumar Sharma
>>> 6:03 PM (now)
>>> 
>>> 
>>> 
>>> to grpc.io
>>> In Local I am using plain Text for production useTransport security is
>>> used as aws ALB only supports ssl settings.
>>> So just a corrections:
>>> Map customArgs = new HashMap<>();
>>> customArgs.put("channelNumber", String.valueOf(channelNumber));
>>> ManagedChannel channel = ManagedChannelBuilder.forTarget(grpcUrl)
>>> .useTransportSecurity()
>>> .defaultLoadBalancingPolicy("round_robin")
>>> .enableRetry()
>>> .maxRetryAttempts(6)
>>> .defaultServiceConfig(customArgs)
>>> .build();
>>>
>>> Thanks & Regards,
>>> Pawan Sharma
>>>
>>> On Tuesday, June 18, 2024 at 5:41:35 PM UTC+5:30 Pawan Kumar Sharma
>>> wrote:
>>>
 Hi Guys,

 I am seeing 1-2% grpc Traffic gets dropped even after following best
 practices.
 I am using channel polling of size 10-20, best practices suggested in
 for polling is we have a unique channel name and even with retry added
 these numbers did not change.
 For channel creation I using bellow code:
 Map customArgs = new HashMap<>();
 customArgs.put("channelNumber", String.valueOf(channelNumber));
 ManagedChannel channel = ManagedChannelBuilder.forTarget(grpcUrl)
 .usePlaintext()
 .defaultLoadBalancingPolicy("round_robin")
 .enableRetry()
 .maxRetryAttempts(6)
 .defaultServiceConfig(customArgs)
 .build();

 And the Error msg I am getting is:

 RankingServiceSort EXCEPTION : UNAVAILABLE:
 unavailableio.grpc.stub.ClientCalls|toStatusRuntimeException|262
 io.grpc.stub.ClientCalls|getUnchecked|243
 io.grpc.stub.ClientCalls|blockingUnaryCall|156

 proto.RankingServiceGrpc$RankingServiceBlockingStub|sortInventoryData|169
 RankingService.RankingGrpcConnector|GetInventoryRanking|80

 Please help us we are stuck here from 3-4 months, We are using aws grpc
 supported ALB in between and these best practices though helped us in
 reducing DeadLine Acceded issue but service Unavailable cases are not
 getting reduced. Did now found any detailed documentation as well. We are
 having 2 instances for this service and both CPU and memory and network
 bandwidth is not at exhausted, used bellow 5%.

 Thanks & Regards,
 Pawan Sharma

>>>
>>>
>>>
>>>
>>> *::DISCLAIMER::The
>>> contents of this e-mail and any attachments are confidential and intended
>>> for the named recipient(s) only.E-mail transmission is not guaranteed to be
>>> secure or error-free as information could be intercepted, corrupted,lost,
>>> destroyed, arrive late or incomplete, or may contain viruses in
>>> transmission. The e mail and its contents(with or without referred errors)
>>> shall therefore not attach any liability on the originator or redBus.com.
>>> Views or opinions, if any, presented in this email are solely those of the
>>> author and may not necessarily reflect the views or opinions of redBus.com.
>>> Any form of reproduction, dissemination, copying, disclosure,
>>> modification,distribution and / or publication of this message without the
>>> prior written consent of authorized representative of redbus.
>>> com is strictly prohibited. If you have received this
>>> email in error please delete it and notify the sender immediately.Before
>>> opening any email and/or attachments, please check them for viruses and
>>> other defects.*
>>>
>>> --
>>> 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/9e6eb62d-7125-4978-a231-ed625ef462cbn%40googlegroups.com
>>> 
>>> .
>>>
>>
>
>
>
> *::DISCLAIMER::The
> contents of this e-mail and any attachments are confidential and intended
> for the 

Re: [grpc-io] Re: 1-2% GRPC traffic gets Dropped at scale With Service Unavailable Error

['Larry Safran' via grpc.io]

Which version of grpc are you using?

On Tue, Jun 18, 2024 at 5:34 AM 'Pawan Kumar Sharma' via grpc.io <
grpc-io@googlegroups.com> wrote:

>
> Pawan Kumar Sharma
> 6:03 PM (now)
> 
> 
> 
> to grpc.io
> In Local I am using plain Text for production useTransport security is
> used as aws ALB only supports ssl settings.
> So just a corrections:
> Map customArgs = new HashMap<>();
> customArgs.put("channelNumber", String.valueOf(channelNumber));
> ManagedChannel channel = ManagedChannelBuilder.forTarget(grpcUrl)
> .useTransportSecurity()
> .defaultLoadBalancingPolicy("round_robin")
> .enableRetry()
> .maxRetryAttempts(6)
> .defaultServiceConfig(customArgs)
> .build();
>
> Thanks & Regards,
> Pawan Sharma
>
> On Tuesday, June 18, 2024 at 5:41:35 PM UTC+5:30 Pawan Kumar Sharma wrote:
>
>> Hi Guys,
>>
>> I am seeing 1-2% grpc Traffic gets dropped even after following best
>> practices.
>> I am using channel polling of size 10-20, best practices suggested in for
>> polling is we have a unique channel name and even with retry added these
>> numbers did not change.
>> For channel creation I using bellow code:
>> Map customArgs = new HashMap<>();
>> customArgs.put("channelNumber", String.valueOf(channelNumber));
>> ManagedChannel channel = ManagedChannelBuilder.forTarget(grpcUrl)
>> .usePlaintext()
>> .defaultLoadBalancingPolicy("round_robin")
>> .enableRetry()
>> .maxRetryAttempts(6)
>> .defaultServiceConfig(customArgs)
>> .build();
>>
>> And the Error msg I am getting is:
>>
>> RankingServiceSort EXCEPTION : UNAVAILABLE:
>> unavailableio.grpc.stub.ClientCalls|toStatusRuntimeException|262
>> io.grpc.stub.ClientCalls|getUnchecked|243
>> io.grpc.stub.ClientCalls|blockingUnaryCall|156
>> proto.RankingServiceGrpc$RankingServiceBlockingStub|sortInventoryData|169
>> RankingService.RankingGrpcConnector|GetInventoryRanking|80
>>
>> Please help us we are stuck here from 3-4 months, We are using aws grpc
>> supported ALB in between and these best practices though helped us in
>> reducing DeadLine Acceded issue but service Unavailable cases are not
>> getting reduced. Did now found any detailed documentation as well. We are
>> having 2 instances for this service and both CPU and memory and network
>> bandwidth is not at exhausted, used bellow 5%.
>>
>> Thanks & Regards,
>> Pawan Sharma
>>
>
>
>
>
> *::DISCLAIMER::The
> contents of this e-mail and any attachments are confidential and intended
> for the named recipient(s) only.E-mail transmission is not guaranteed to be
> secure or error-free as information could be intercepted, corrupted,lost,
> destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents(with or without referred errors)
> shall therefore not attach any liability on the originator or redBus.com.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the views or opinions of redBus.com.
> Any form of reproduction, dissemination, copying, disclosure,
> modification,distribution and / or publication of this message without the
> prior written consent of authorized representative of redbus.
> com is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately.Before
> opening any email and/or attachments, please check them for viruses and
> other defects.*
>
> --
> 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/9e6eb62d-7125-4978-a231-ed625ef462cbn%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/CANuT3qV%2BaDUEgyr-mCFcHDuTJrsq8mok7hfUc%3D-RQr%2BKYpQpQQ%40mail.gmail.com.

[grpc-io] Re: Urgent: Load/Performance tool for all types of GRPC calls??

['Larry Safran' via grpc.io]

You could try using Postman.  They have been supporting gRPC for a couple 
of years.  https://blog.postman.com/postman-now-supports-grpc/

On Monday, March 25, 2024 at 11:09:28 PM UTC-7 Irfan Hassam wrote:

> Hello,
>
> I have tried to test my grpc server with jmeter plugin jmeter-grpc-request 
> but for server streaming response it was not working.
> Now i am using k6 but for k6 server streaming message i am not able to 
> send my accesstoken. Is there any tool that i can use for grpc load testing 
> or if above can be used. Kindly help.
>
> Thankyou,
> Irfan
>

-- 
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/1ebb16b1-5cfe-46f1-8242-eea20c3a5baan%40googlegroups.com.

Re: [grpc-io] grpc features comparison for various versions

['Larry Safran' via grpc.io]

You can find the release notes in each language's depot on github.  For
example, for Java, at github.com/grpc/grpc-java/releases
You can also use github to get a list of all the changes between releases
such asgithub.com/grpc/grpc-java/compare/v1.62.2...v1.50.3

Most languages are under github.com/grpc.  All wrapped languages are in
github.com/grpc/grpc

-- Larry

On Fri, Apr 26, 2024 at 1:09 PM Nest  wrote:

> Hi,
>
>
>
> I am unable to find a page which describes comparisons between gRPC
> releases.
>
> For e.g., if I wanted to see changes between v1.50 and v.162.
>
>
>
> Can someone point me to the same? Or else do release notes are also fine
> if you can point me to the same.
>
>
>
> 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/53c1902e-eeeb-40aa-ad7c-58f2239a6293n%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/CANuT3qV%3D1ehhtXraKVhbuAa%2Beq-wx-HO4my0_dbwxjXyxsPvgQ%40mail.gmail.com.

Re: [grpc-io] Since which version, gRPC stack started supporting TLS 1.3?

['Larry Safran' via grpc.io]

Hi Shikha,
Which language are you using?

Note, you should be using a recent version, which version are you using?

Thanks,
  Larry

On Wed, Apr 24, 2024 at 2:37 PM Shikha Chowdhary <
shikhachowdhar...@gmail.com> wrote:

> - All working well with TLS 1.2 but intermittently failed when using TLS
> 1.3
>
> --
> 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/325e8f5b-b2ce-4194-a7cb-12e2590a8e65n%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/CANuT3qWdCYV9Hkj_Y4nBkYynyRMVhmyZJBtXEqGPhE8QuLgLqw%40mail.gmail.com.

[grpc-io] gRPC-Java version 1.62

['Larry Safran' via grpc.io]

The v1.62 release  for 
gRPC-Java is now available. 

While the release is technically 1.62.2, that is due to operational issues 
and this is the initial 1.62.x release.

API Changes
   
   - services: Remove io.grpc.services.BinaryLogs, which was deprecated 
   since 2021. io.grpc.protobuf.services.BinaryLogs should be used instead (
   #10832 ).
   - Allow users outside of io.grpc.xds package to create custom xDS 
   resources (#10834 ) (
   6d96e65 
   

   )

New Features
   
   - api:Add ClientTransportFilter. Similarly to ServerTransportFilter, 
   this will provide an observability hook and it allows direct modification 
   of the transport's attributes. (#10646 
   )

Improvements
   
   - java_grpc_library.bzl: Add support for Auto Exec Groups (cb03bd2 
   
).
 
   This is mostly a behind-the-scenes change to adjust to the newer way Bazel 
   operates
   - java_grpc_library.bzl: Support runfiles for protoc and the plugin (
   65a6b3b 
   
).
 
   Neither binary uses runfiles, but the task will be ready if they need to in 
   the future
   - xds: Add EC key support for XdsChannelCredentials/XdsServerCredentials 
   (100d5a5 
   

   )
   - binder:Change log level from WARNING to FINER for expected exception 
   during close with error, to reduce log spamming (#10899 
   ) (7ba0718 
   

   )

Bug Fixes
   
   - xds: Fix a bug in WeightedRoundRobinLoadBalancer policy that could 
   raise NullPointerException and further cause channel panic when picking a 
   subchannel. This bug can only be triggered when connection can not be 
   established and the channel reports TRANSIENT_FAILURE state. (#10868 
   )

Dependencies
   
   - The protoc plugin no longer supports macOS Big Sur (macOS 11). 
   Binaries are now built using Monterey (macOS 12)

Acknowledgements
   
   - @joybestourous 


-- 
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/fdfbcfae-4959-47e7-b7e0-666f8cd53f0cn%40googlegroups.com.

Re: [grpc-io] Re: gRPC Client thread hangs on blocking APIs

['Larry Safran' via grpc.io]

yes, disabling the retry eliminates the problem.

On Mon, Feb 26, 2024 at 10:57 AM tuk  wrote:

> Thanks for replying.
>
> Just confirming for now the workaround is to disable the retry as
> suggested in the linked GitHub issue.
>
> On Monday 26 February 2024 at 23:43:24 UTC+5:30 Larry Safran wrote:
>
>> There was an issue with a test in Google's internal repository, so this
>> fix was temporarily backed out and is now targeted for 1.63.
>>
>> On Mon, Feb 26, 2024 at 9:45 AM 'Yuri Golobokov' via grpc.io <
>> grp...@googlegroups.com> wrote:
>>
>>> Maybe you are hitting this bug:
>>> https://github.com/grpc/grpc-java/issues/10838
>>> It is fixed and backported to 1.59 and later versions.
>>>
>>> On Monday, February 26, 2024 at 7:00:57 AM UTC-8 tuk wrote:
>>>
 I am using gRPC 1.55.1 and observing an issue similar to the one
 discussed in the below GitHub issue

- https://github.com/grpc/grpc-java/issues/9069

 I have set the KeepAlive on both the client and server-side as
 suggested in the above issue

 I am creating the stub like below

 var channel = ManagedChannelBuilder.forAddress(network.getIp(),
 network.getPort())
 .keepAliveTime(130, TimeUnit.SECONDS)
 .maxInboundMessageSize(maxInboundMessageSize)
 .maxInboundMetadataSize(maxInboundMetadataSize)
 .enableRetry()
 .build();

 var stub =
 HelloServiceGrpc.newBlockingStub(channel).withDeadline(Deadline.after(115,
 TimeUnit.SECONDS));
 stub.sayHello();
 stub.sayHello();

 In server side also keepAliveTime is set as suggested in the above
 github issue.

 Grpc.newServerBuilderForPort(port, InsecureServerCredentials.create())
 .addService(new GreeterImpl())
 .keepAliveTime(130, TimeUnit.SECONDS)
 .build()
 .start();

 In my case, client calls server 1 then server 1 acts as a client to
 server 2.

 I am observing that when the deadline is exceeded in server2 the same
 deadline error is coming to server 1 like below which is also coming to
 client. It is working as expected.

 io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: context timed out
 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)


 But on some rare occasions I am observing the client thread hanging
 like the below and not getting the deadline exceeded error

 at jdk.internal.misc.Unsafe.park(java...@17.0.9/Native Method)
 - parking to wait for  <0x000767a53a00> (a
 io.grpc.stub.ClientCalls$ThreadlessExecutor)
 at java.util.concurrent.locks.LockSupport.park(java...@17.0.9
 /LockSupport.java:211)
 at
 io.grpc.stub.ClientCalls$ThreadlessExecutor.waitAndDrain(ClientCalls.java:748)
 at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:157)

 I waited for about 2 hours & it did not recover. The only way to
 recover from this is to restart the client application. It happened 3-4
 times in the last couple of months for us.

 Can someone let me know

1. What I am doing wrong or is there any known issue in the
grpc-java 1.55.1 that I am using?
2. Is there any timeout config I can set on the gRPC client side so
that the client threads do not hang indefinitely?

 --
>>> 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/d2700afd-762e-49ee-a15b-7f7901a6d10cn%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/80d5231c-d509-4c20-824b-34d71ee97f18n%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/CANuT3qX_W8ou3wPw4MFyzdyegrAM8XVV3qXiOnb8ATgiZbW0cQ%40mail.gmail.com.

Re: [grpc-io] Re: gRPC Client thread hangs on blocking APIs

['Larry Safran' via grpc.io]

There was an issue with a test in Google's internal repository, so this fix
was temporarily backed out and is now targeted for 1.63.

On Mon, Feb 26, 2024 at 9:45 AM 'Yuri Golobokov' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Maybe you are hitting this bug:
> https://github.com/grpc/grpc-java/issues/10838
> It is fixed and backported to 1.59 and later versions.
>
> On Monday, February 26, 2024 at 7:00:57 AM UTC-8 tuk wrote:
>
>> I am using gRPC 1.55.1 and observing an issue similar to the one
>> discussed in the below GitHub issue
>>
>>- https://github.com/grpc/grpc-java/issues/9069
>>
>> I have set the KeepAlive on both the client and server-side as suggested
>> in the above issue
>>
>> I am creating the stub like below
>>
>> var channel = ManagedChannelBuilder.forAddress(network.getIp(),
>> network.getPort())
>> .keepAliveTime(130, TimeUnit.SECONDS)
>> .maxInboundMessageSize(maxInboundMessageSize)
>> .maxInboundMetadataSize(maxInboundMetadataSize)
>> .enableRetry()
>> .build();
>>
>> var stub =
>> HelloServiceGrpc.newBlockingStub(channel).withDeadline(Deadline.after(115,
>> TimeUnit.SECONDS));
>> stub.sayHello();
>> stub.sayHello();
>>
>> In server side also keepAliveTime is set as suggested in the above github
>> issue.
>>
>> Grpc.newServerBuilderForPort(port, InsecureServerCredentials.create())
>> .addService(new GreeterImpl())
>> .keepAliveTime(130, TimeUnit.SECONDS)
>> .build()
>> .start();
>>
>> In my case, client calls server 1 then server 1 acts as a client to
>> server 2.
>>
>> I am observing that when the deadline is exceeded in server2 the same
>> deadline error is coming to server 1 like below which is also coming to
>> client. It is working as expected.
>>
>> io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: context timed out
>> 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)
>>
>>
>> But on some rare occasions I am observing the client thread hanging like
>> the below and not getting the deadline exceeded error
>>
>> at jdk.internal.misc.Unsafe.park(java...@17.0.9/Native Method)
>> - parking to wait for  <0x000767a53a00> (a
>> io.grpc.stub.ClientCalls$ThreadlessExecutor)
>> at java.util.concurrent.locks.LockSupport.park(java...@17.0.9
>> /LockSupport.java:211)
>> at
>> io.grpc.stub.ClientCalls$ThreadlessExecutor.waitAndDrain(ClientCalls.java:748)
>> at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:157)
>>
>> I waited for about 2 hours & it did not recover. The only way to recover
>> from this is to restart the client application. It happened 3-4 times in
>> the last couple of months for us.
>>
>> Can someone let me know
>>
>>1. What I am doing wrong or is there any known issue in the grpc-java
>>1.55.1 that I am using?
>>2. Is there any timeout config I can set on the gRPC client side so
>>that the client threads do not hang indefinitely?
>>
>> --
> 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/d2700afd-762e-49ee-a15b-7f7901a6d10cn%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/CANuT3qVFMGFdYXDPxKbTj0ObZ7j392NW13-MEiDo%2BV3kVp5ojQ%40mail.gmail.com.

Re: [grpc-io] GRPC connection socket policy

['Larry Safran' via grpc.io]

As mentioned in the core concepts guide
, the exact
behavior of closing channels is language dependent.  Note that you can have
multiple RPCs simultaneously using the same channel.  As long as a channel
is "active" it will stay connected.  For streaming RPCs, the keepalive
 call option can keep the channel
connected even when there are long breaks between messages.

Hope that helps,
  Larry

On Wed, Feb 21, 2024 at 4:30 PM Александр Сергеев 
wrote:

> Good afternoon!
> Quickly looking through the documentation, I wasn't able to find an answer
> to a question that interested me, so maybe you could help me here.
> I was wondering, how many socket connections are being used when GRPC
> client communicates to GRPC server? Does one GRPC "channel" operate inside
> of one TCP socket or does it reconnect every time user calls another
> procedure?
> I think that understanding this might be important to learn more about
> GRPC performance (since closing and re-opening TLS sockets, for instance,
> might take a lot of time).
> Thank you in advance for your response!
> 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/10df9e08-0f8e-4cbc-b971-cbabd04c502en%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/CANuT3qV3VdzkVRc92mQ0qa1FFWOCi5hd1apnGXkGbbAe%2BYqGcg%40mail.gmail.com.

[grpc-io] Re: Facing issue to use protobuf in dot net core 6

['Larry Safran' via grpc.io]

Using string and int32 instead of *google.protobuf.StringValue*  and 
*google.protobuf.Int32Value* will change *description* and *modified_user* to 
your desired format.

On Wednesday, December 27, 2023 at 10:35:11 PM UTC-8 Utpal Dutta wrote:

> Hello,
> I am using Protobuff with dotnet core 6. I am creating CRUD operation 
> through gRPC communication. In my get response I have some nullable 
> properties (string, datetime).
> Now facing issue when datetime nullable property want to return. Also 
> datetime is returning as a json object. Same for nullable string also. 
> Where as I want the response as normal datetime and string value. Can 
> anyone please help to solve this issue.
>
> My proto file look like below:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *syntax = "proto3";import "google/protobuf/timestamp.proto";import 
> "google/protobuf/wrappers.proto";message GetSiteResponse{ int32 id = 
> 1; string name = 2; google.protobuf.StringValue description = 3; bool 
> deleted = 4; int32 created_user = 5; google.protobuf.Timestamp created_date 
> = 6;  google.protobuf.Int32Value modified_user = 7; 
>  google.protobuf.Timestamp modified_date = 8;}*
>
> *---*
>
> *My response is coming in below format:*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * {"id": 1,"name": "name20",
> "description": {"value": "desc20"},
> "deleted": false,"created_user": 1,"created_date": 
> {"seconds": "1702460720","nanos": 
> 41400},"modified_user": {
> "value": 1},"modified_date": null}*
>
>
> *---*
>
> *But I want my response in below format*
>
>
>
>
>
>
>
>
>
>
>
> * {"id": 1,"name": "name20",
> "description": "desc20","deleted": false,
> "created_user": 1,"created_date": "2023-12-13T09:45:20.414Z",  
>   "modified_user": 1,"modified_date": null}*
>
> *---*
>
>
> *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/b9d77394-8d90-4b5f-9cdd-5b5ba457346dn%40googlegroups.com.

[grpc-io] gRPC-Java v1.60.1 Released

['Larry Safran' via grpc.io]

The v1.60.1 release is now available:


   - util: Fix NPE when there are multiple addresses in an address group 
   for petiole load balancer policies

-- 
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/0cc39ad6-08e5-455d-bff7-064293d4bc28n%40googlegroups.com.

Re: [grpc-io] Avoid gRPC message exceeds maximum size error

['Larry Safran' via grpc.io]

Hi Noam,
  If you set CallOptions.withMaxOutboundMessageSize, then your write will
get a Status.RESOURCE_EXHAUSTED based upon the actual size being sent which
will be present in the description.  You could catch that and then break
your message apart when needed.

I'm not clear how your chunking is helping compared to the chunking that is
done at the network level.  The example size you gave is much smaller than
the 4MB default; have you tried using a larger max size?

Thanks,
  Larry

On Wed, Dec 20, 2023 at 8:32 AM Noam Isachar  wrote:

> I'm using gRPC to send messages from Java to a Python service. Recently I
> started getting larger messages that sometimes exceed the maximum message
> size for gRPC. Increasing that size is not possible for me due to lack of
> resources and timeouts, so I had to implement a chunking mechanism in order
> to split the large messages.
>
> In Java, I check the message size using getSerializedSize() and if it
> exceeds the maximum size, I do the chunking. However, I noticed that the
> value I'm getting from getSerializedSize() is different and much smaller
> than the one shown in the error "gRPC message exceeds maximum size" which
> means that I still send messages that exhaust the resources.
>
> For example, how is it possible that getSerializedSize() returns 75274 and
> the error shows a size of 179651? Both are supposed to show the size in
> bytes. I also tried getting the size using the length of the byte array,
> but it is identical to getSerializedSize().
>
> How can I know the actual size gRPC will get before sending the message so
> I can apply the chunking when I should?
>
> --
> 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/602108bd-15fd-421a-96ad-4f7c52bf4a2en%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/CANuT3qUtEbxo2gTGLa4AW3UJJLdYQg5EWBEeq80WiGjOy%3D%3DqBA%40mail.gmail.com.

Re: [grpc-io] Stream refused by server

['Larry Safran' via grpc.io]

ExperimentalApi means that we reserve the right to break backward
compatibility in the future.  However, we do ensure that they function
correctly.  Generally, this means that they may behave slightly differently
or that ABI compatibility is broken.  If you are okay with recompiling to
upgrade to some future version of grpc-java, then it is okay to use in
production systems.

Thanks,
  Larry

On Tue, Dec 19, 2023 at 12:05 PM Rajan Shah  wrote:

> We already have 3 times GRPC Client retries, I will try out the
> NettyServerBuilder. But the NettyServerBuilder has the ExperimentalApi
> annotation, should we be using this in production systems.
>
> https://grpc.github.io/grpc-java/javadoc/io/grpc/netty/NettyServerBuilder.html#withChildOption(io.netty.channel.ChannelOption,T)
>
> On Mon, Dec 18, 2023 at 1:38 PM Larry Safran  wrote:
>
>> Rajan,
>>   Do you have retries enabled?  That would be your first line of defense.
>>
>> On the server side, giving the server more resources  may help.  You
>> could directly use NettyServerBuilder for more fine grained control through
>> ChannelOptions (using *.withOptions()* method).  Specifically
>> options CONNECT_TIMEOUT_MILLIS and SO_BACKLOG.
>>
>> Hope that helps,
>>   Larry
>>
>> On Mon, Dec 18, 2023 at 11:21 AM Rajan Shah 
>> wrote:
>>
>>> When the load increases on the GRPC Server I am seeing Error 14 on the
>>> GRPC Client. Which essentially says that the stream is refused by the
>>> server.  How can we resolve this as the data is not even seen by the GRPC
>>> Server it is only being printed on the Client logs.
>>>
>>> Is there any buffer which I can increase ?
>>>
>>> Context:
>>>
>>> I have a bidirectional grpc connection using Java 8 with flatbuffers.
>>>
>>> similar to this issue https://github.com/grpc/grpc-node/issues/1969
>>>
>>> Thanks
>>> Rajan
>>>
>>> --
>>> 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/20f7f32b-f42f-4e5a-a96a-c038d69f4617n%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/CANuT3qWH6ztMHvjAABrW8T3tnT-noYy%2Bv87skw54D5sTaXXMng%40mail.gmail.com.

Re: [grpc-io] Stream refused by server

['Larry Safran' via grpc.io]

Rajan,
  Do you have retries enabled?  That would be your first line of defense.

On the server side, giving the server more resources  may help.  You could
directly use NettyServerBuilder for more fine grained control through
ChannelOptions (using *.withOptions()* method).  Specifically
options CONNECT_TIMEOUT_MILLIS and SO_BACKLOG.

Hope that helps,
  Larry

On Mon, Dec 18, 2023 at 11:21 AM Rajan Shah  wrote:

> When the load increases on the GRPC Server I am seeing Error 14 on the
> GRPC Client. Which essentially says that the stream is refused by the
> server.  How can we resolve this as the data is not even seen by the GRPC
> Server it is only being printed on the Client logs.
>
> Is there any buffer which I can increase ?
>
> Context:
>
> I have a bidirectional grpc connection using Java 8 with flatbuffers.
>
> similar to this issue https://github.com/grpc/grpc-node/issues/1969
>
> Thanks
> Rajan
>
> --
> 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/20f7f32b-f42f-4e5a-a96a-c038d69f4617n%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/CANuT3qW_7AzH0r08Xfv1Mvg_CjTuX-O7O1-TwVkRXymGMuTAYw%40mail.gmail.com.

Re: [grpc-io] Best wey to Return data from xml

['Larry Safran' via grpc.io]

Protobuf supports optional fields proto documentation
.  Since one
is a subset of the other, this would work great for you.   If you want to
make it easy to identify the type of product, you can have a field that
represents the type as either a string or an enum.  Protobuf also supports
repeated values and nested types so while the XML may be large, it can be
compressed a lot when sent as a proto.

On Mon, Dec 18, 2023 at 11:21 AM Juan Carlos Parra Morillo <
jc.parr...@gmail.com> wrote:

> I want to develop a grPc service. I already have the input message object
> defined but not the response object.
>
> The issue is that this new grPc service, once it receives a request, makes
> a call to another service that returns an XML like the one I show
>
> more below in the example
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> 
>
> As you can see, the fields of each product may vary. There are more
> products that I do not show in the example that also
>
> They can have more fields within the product tag
>
> I would like to know what is the best way to represent the response object
> for this. I have two options
>
> 1. Through arrangements that represent each product to me. Example
>
> message products{
>
> ACCOUNTS account=1;
>
> LOANS loans=2;
>
> .
>
> }
>
> message ACCOUNT{
>
> String balance=1;
>
> String currency=2;
>
> String product_name=3;
>
> String number=4;
>
> }
>
> message ACCOUNT{
>
> String balance=1;
>
> String currency=2;
>
> String product_name=3;
>
> String number=4;
>
> String payment_date=5;
>
> String quota=6;
>
> }
>
> 2. With a data type that saves a meta-data like google.protobuf.Any
>
> message products{
>
> google.protobuf.Any XML_Products=1;
>
> }
>
> Please guide me on what would be the most optimal way to return the
> message. Option 1 causes me a
>
> a little afraid of the performance it could have since the service must go
> through the response XML
>
> and then identify what type of product it is to add it to the array of its
> corresponding product
>
> and then the service that made the request to the grPc service receives
> the products object as a response
>
> You must also go through it to create a response json. I am also concerned
> about the fact that a client
>
> You can have several products of different types so the products XML can
> become very large.
>
> What is your opinion or if there is a better way to do it please let me
> know...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/7d20aa39-28c9-48ec-84a3-19e69fda6633n%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/CANuT3qXGXhfiZfzVuj7k%2BfEQH-8ooAvV%3Ds8YtZgMFDjCqdmEPg%40mail.gmail.com.

[grpc-io] gRPC-Java v1.58.1 Released

['Larry Safran' via grpc.io]

The v1.58.1 release  is 
now available.


   - xds: PickFirst was not receiving its configuration so it used the 
   default configuration which meant that randomize was ignored.
   

-- 
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/760d8e91-8126-4b5e-978c-94f924fa7d68n%40googlegroups.com.

Re: [grpc-io] Grpc Java server test for ServerInterceptors

['Larry Safran' via grpc.io]

Hi Edu,

Yes, that implementation looks good.  We have an example that does
something similar:
https://github.com/grpc/grpc-java/tree/master/examples/example-oauth

ServerInterceptors are called sequentially by a single thread, so it will
be thread safe.  Additionally, Context objects are immutable.
Context.withValue constructs a new object, so there is no concern about
threads doing concurrent updates.

The example has a unit test using JUnit.  I would recommend also making
very simple client/server classes like in the above example to see it
working end-to-end.

As to documentation, there is no central documentation discussing threads.
We do use the @ThreadSafe annotation (for example on ServerInterceptor).
Anything public (not Experimental or Internal) not so annotated should be
assumed not to be thread safe. If you look through the code, you will see
that much of the task coordination that is done is through the use of
Executor classes.

Thanks,
  Larry

On Tue, Nov 7, 2023 at 12:48 PM Eduwer Camacaro  wrote:

> Hi Grpc team!
> I have a ServerInterceptor instance for my grpc server, it does something
> like this:
>
> @Override
> public  ServerCall.Listener interceptCall(
> ServerCall call, Metadata headers,
> ServerCallHandler next) {
> Context context = Context.current();
>  // more code here
> context = context.withValue(USER_ID, "my-user-id");
> return Contexts.interceptCall(context, call, headers, next);
> }
>
> and in my service method I get access to the userId using smth like this:
>
> USER_ID.get()
>
>
> I have some questions:
> Is this implementation correct?
> Is this thread safe?
> Is there any way to test that implementation?
> Is there any documentation that I can check to understand how Threads are
> handled by the grpc server?
>
> Thanks in advance! :)
>
> Edu-
>
> --
> 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/928b79d2-8b8c-4b0f-bc8f-51a4bc0dcd5an%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/CANuT3qXvWat8gQeT982obEbUVNh-B2EFzyc8dWEeG5Q2i2oJEw%40mail.gmail.com.

Re: [grpc-io] gRPC client fallback from load-balancer to round robin DNS endpoint on LB outage

['Larry Safran' via grpc.io]

Yes, you will need a custom NameResolver.
You could have your NameResolver do one of the following
1)  Extend DnsNameResolver (as is done by the internal GrpcNameResolver)
and override the doResolve method
2)  Directly extend NameResolver and have a field with a DnsNameResolver
created through the DnsNameResolverProvider (which should be gotten from
the registry).

There is already a load balancer that is switching between 2 child load
balancers.  It is experimental and can be specified as
"priority_experimental".  What it does is to use a specific attribute that
must be set by the NameResolver.  Even if you go with your own load
balancer, that would be the best way to differentiate which addresses
should be used for which child.  If you want to use it as an example, it is
https://github.com/grpc/grpc-java/blob/master/xds/src/main/java/io/grpc/xds/PriorityLoadBalancer.java



On Mon, Nov 6, 2023 at 1:53 PM Krishna Sai Veera Reddy <
krishnasaiveerareddy...@gmail.com> wrote:

> Hey Larry,
>
> Thank you for your response! Are there any examples out in the wild on how
> to do this? Also the part that is confusing me is the name resolution. Do
> we have to add a custom name resolution policy as well so that we get both
> the LB and round robin IP addresses in `acceptResolvedAddresses
> `
> method in the LB policy?
>
> On Friday, November 3, 2023 at 12:50:20 PM UTC-7 Larry Safran wrote:
>
>> This is a perfect scenario for a custom LB policy.  Since LB policies
>> form a tree, you could easily have your policy delegate to either a
>> PickFirst or RoundRobin policy depending on whether or not the LB is up.
>> Just have your policy define a ForwardingLoadbalanceHelper whose
>> updateBalancingState passes the picker from the oppropriate downstream
>> policy.
>>
>> On Fri, Nov 3, 2023 at 12:29 PM Krishna Sai Veera Reddy <
>> krishnasaiv...@gmail.com> wrote:
>>
>>> Hello All,
>>>
>>> I am working on a gRPC client that connects to a gRPC service fronted by
>>> an LB but would like the client to automatically fallback to using
>>> round-robin DNS to directly connect to the backend servers when the LB goes
>>> down. How do I go about this? Would I need to implement my own custom LB
>>> policy? Any help is appreciated and 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/df8f4a85-5020-4c68-bb94-cbea67d7c75an%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/2e7b95aa-cd66-40f5-bf41-0484fa12892cn%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/CANuT3qWv7zkt-VJX34HrR2YT0p4dwUcytWj5H%3DM1UicDS7gTyg%40mail.gmail.com.

Re: [grpc-io] gRPC client fallback from load-balancer to round robin DNS endpoint on LB outage

['Larry Safran' via grpc.io]

This is a perfect scenario for a custom LB policy.  Since LB policies form
a tree, you could easily have your policy delegate to either a PickFirst or
RoundRobin policy depending on whether or not the LB is up.  Just have your
policy define a ForwardingLoadbalanceHelper whose updateBalancingState
passes the picker from the oppropriate downstream policy.

On Fri, Nov 3, 2023 at 12:29 PM Krishna Sai Veera Reddy <
krishnasaiveerareddy...@gmail.com> wrote:

> Hello All,
>
> I am working on a gRPC client that connects to a gRPC service fronted by
> an LB but would like the client to automatically fallback to using
> round-robin DNS to directly connect to the backend servers when the LB goes
> down. How do I go about this? Would I need to implement my own custom LB
> policy? Any help is appreciated and 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/df8f4a85-5020-4c68-bb94-cbea67d7c75an%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/CANuT3qXT1s%3DPZmL8K9vaVMthqebFJ0vD0TSJVeNHFEv1LQeDbw%40mail.gmail.com.

[grpc-io] Re: gRPC Community Meetup and Office Hours tomorrow Oct 24 @ 2:40PM PDT

['Larry Safran' via grpc.io]

The start time is actually 2:40 rather than 2 PM.

On Monday, October 23, 2023 at 10:37:38 AM UTC-7 Larry Safran wrote:

> Our monthly community meetup and office hours is coming up.
>
> For this meeting, we will have a presentation by Sanjay Pujare. Sanjay is 
> an engineer in the gRPC team at Google and has been working on gRPC for 
> almost 5 years. He has been involved in proxyless gRPC service mesh, Istio, 
> service mesh security, gRPC observability, gateway APIs for service meshes 
> (also known as the GAMMA initiative) and stateful session affinity for gRPC 
> based proxyless service mesh.
>
> The talk's topic is:
> Exploring stateful session affinity in proxyless gRPC.
>
> Sanjay will talk about stateful session affinity in proxyless gRPC. He 
> will cover the background of stateful session affinity, the use-case, its 
> design and the current implementation status.
>
> Office Hours questions can be registered at: 
> https://forms.gle/xCwNaKmjS9C3GGpz8
>
> You can signup and present  at 
> future meetups.
>
> We will stream the meeting on Google Meet 
> https://meet.google.com/gkt-qgru-uom
>
>

-- 
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/44e6f3b5-b680-48c0-b330-1b929710b7ccn%40googlegroups.com.

[grpc-io] gRPC Community Meetup and Office Hours tomorrow Oct 24 @ 2PM PDT

['Larry Safran' via grpc.io]

Our monthly community meetup and office hours is coming up.

For this meeting, we will have a presentation by Sanjay Pujare. Sanjay is 
an engineer in the gRPC team at Google and has been working on gRPC for 
almost 5 years. He has been involved in proxyless gRPC service mesh, Istio, 
service mesh security, gRPC observability, gateway APIs for service meshes 
(also known as the GAMMA initiative) and stateful session affinity for gRPC 
based proxyless service mesh.

The talk's topic is:
Exploring stateful session affinity in proxyless gRPC.

Sanjay will talk about stateful session affinity in proxyless gRPC. He will 
cover the background of stateful session affinity, the use-case, its design 
and the current implementation status.

Office Hours questions can be registered at: 
https://forms.gle/xCwNaKmjS9C3GGpz8

You can signup and present  at future 
meetups.

We will stream the meeting on Google Meet 
https://meet.google.com/gkt-qgru-uom

-- 
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/8c4d8b82-3c09-48fb-a14a-d5b05475a372n%40googlegroups.com.

Re: [grpc-io] JWT authentication and authorization in a gRPC (JAVA).

['Larry Safran' via grpc.io]

Check out the example at:
https://github.com/grpc/grpc-java/tree/master/examples/example-jwt-auth


On Wed, Sep 20, 2023 at 2:42 AM Ayush swar  wrote:

> "I'm interested in learning how to implement JWT (JSON Web Token)
> authentication and authorization in a gRPC microservices architecture using
> Java. Can anyone provide guidance, resources, or examples to help me get
> started with this?"
>
> --
> 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/6023b1bc-1d58-4e83-a6b4-ca1a3177f193n%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/CANuT3qX1UHvZoTvnpw0jVJ1Gudq6c0_uwTjkjWoehObsOXDzNA%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?

['Larry Safran' via grpc.io]

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 <
grpc-io@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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/8f2a15b8-1541-422e-ad66-9a5778e53882n%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/CANuT3qXXzcTGFiAFPniyfES84VGKtL4BWcnXK_YB4Lss1N17ig%40mail.gmail.com.

Re: [grpc-io] NCDFE on io.grpc.InternalGlobalInterceptors after updating 1.48.0 -> 1.57.2

['Larry Safran' via grpc.io]

You need to add a dependency on grpc-api (or make sure that you have the
1.57.2 version of it).

On Fri, Aug 18, 2023 at 7:31 AM 'Mike Yawn' via grpc.io <
grpc-io@googlegroups.com> wrote:

> I have a demo program that shows building microservices with Hazelcast +
> gRPC that works fine using gRPC 1.48.0.
>
> My build system advised that due to CVEs I should upgrade, so I moved to
> 1.57.2.  Modules upgraded are grpc-netty-shaded (this is the one where the
> CVE was reported) as well as grpc-stub, grpc-protobuf, and protobuf-java
> (which was upgraded from 3.21.1 to 3.21.7).
>
> After the upgrade, the server startup fails with the following stack trace:
> Exception in thread "main" java.lang.NoClassDefFoundError:
> io/grpc/InternalGlobalInterceptors
> at
> io.grpc.internal.ServerImplBuilder.getTracerFactories(ServerImplBuilder.java:252)
> at io.grpc.internal.ServerImplBuilder.build(ServerImplBuilder.java:243)
> at
> io.grpc.internal.AbstractServerImplBuilder.build(AbstractServerImplBuilder.java:217)
> at org.example.grpc.GrpcServer.(GrpcServer.java:42)
> at
> org.hazelcast.msfdemo.invsvc.service.InventoryService.main(InventoryService.java:118)
> Caused by: java.lang.ClassNotFoundException:
> io.grpc.InternalGlobalInterceptors
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:606)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:168)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> ... 5 more
>
> The server startup code is:
>
> server = Grpc.newServerBuilderForPort(port, InsecureServerCredentials.
> create())
> .executor(Executors.newFixedThreadPool(16))
> .addService(service)
> .build();
>
> Any idea what I need to change to resolve this?
>
> Thanks!
> Mike
>
>
> This message contains confidential information and is intended only for
> the individuals named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. E-mail transmission cannot be
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
> The sender therefore does not accept liability for any errors or omissions
> in the contents of this message, which arise as a result of e-mail
> transmission. If verification is required, please request a hard-copy
> version. -Hazelcast
>
> --
> 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/57071bff-d83a-4240-8d50-9fab9b18b355n%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/CANuT3qV8fXmtKxfvkL_dxDJ%3DiZ5xvG966OOdMqQsihJbe7GE-g%40mail.gmail.com.

[grpc-io] August 22 gRPC Meetup update

['Larry Safran' via grpc.io]

Please checkout the Meetup  
on August 22 from 2:40 - 3:30. Welcome to the relaunched gRPC Community 
Meetup, now with Office Hours. We will begin the meeting with a short 
presentation and then move on to Office Hours where we can answer 
questions, help people get unstuck or discuss features and ideas. We have 
an exciting speaker for this meeting. Rajiv Singh is a Software Engineer at 
A.P. Moller - Maersk. Rajiv is a Polymath with a strong belief in 
continuous and intuitive learning. Rajiv was fortunate enough to work on 
the gRPC-Gateway project during the Google Season of Docs 2020 program and 
has created projects utilizing Go, gRPC, and gRPC-Gateway. The talk's topic 
is: Exploring the Power of gRPC-Gateway for Writing RESTful Services To 
begin the talk, he will provide an overview of the advantages and 
disadvantages of both gRPC and REST. From there, he will delve into the 
topic of gRPC-Gateway, discussing its purpose, usage, and problem-solving 
capabilities. Finally, he will showcase how to create a basic Hello World 
REST service using gRPC-Gateway. Office Hours questions can be registered 
at: https://forms.gle/xCwNaKmjS9C3GGpz8 You can signup and present <
https://forms.gle/xCwNaKmjS9C3GGpz8> at future meetups. We will stream the 
meeting on Google Meet https://meet.google.com/gkt-qgru-uom Looking forward 
to seeing everyone there, Larry

-- 
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/4d7823ef-bacc-4598-8105-82a97bb41bd6n%40googlegroups.com.

[grpc-io] gRPC-Java v1.57.0 Released

['Larry Safran' via grpc.io]

The v1.57.0 release  
is now available.

*API Changes*


   - Use fully qualified java.lang.String in all cases in generated code. 
   This fixes compilation if a protobuf message is named “String”.
   - Stabilize two io.grpc.Status methods (asRuntimeException & 
   trailersFromThrowable)
   - Stabilize io.grpc.ManagedChannelBuilder.useTransportSecurity (#10244 
   )
   - Stabilize io.grpc.util.MutableHandlerRegistry (#10348 
   )

*Behavior Changes*


   - xds: Handle loops and duplicates in xds Aggregate clusters
   - core: Change delay for hedging retry after a non-fatal error to be 0 
   to match the gRFC (A6 
   ).
   - api: CheckedForwardingClientCall now passes trailers from the caught 
   exception
   - xds: require EDS service name in CDS resources with an xdstp name
   - xds: Use Rule order instead of RuleChain
   - Wrap other name resolver types in a RetryingNameResolver . Previously, 
   if authority was not overridden, then some name resolvers (such as grpclb) 
   had no retry.
   - xds: Environment variable "GRPC_XDS_EXPERIMENTAL_SECURITY_SUPPORT" is 
   no longer respected, so xDS security cannot be disabled any more (#10243 
   )
   - context, api: Package io.grpc is now consolidated into a single 
   artifact grpc-api by moving classes from grpc-context to grpc-api. 
   grpc-context now has a dependency on grpc-api (but excludes other 
   dependencies of grpc-api) so any application previously using only 
   grpc-context will now also bring in grpc-api. This fixes #3522 
    which was the major 
   issue preventing support of Java modules. We are not done fixing support, 
   as some artifacts need to be split and Automatic-Module-Name needs to be 
   added. The next release is likely to be more stable for modules.

*New Features*


   - binder: Add UserHandle and BinderChannelCredentials to support 
   cross-user communication (#10197 
   )
   - xds,orca: LRS named metrics support

*Improvements*


   - core: Resolve isAndroid only once on class loading. This can improve 
   channel creation performance on Android.
   - xds: Pick a subchannel with new static stride scheduler in 
   WeightedRoundRobinLoadBalancer

*Bug Fixes*


   - xds: Fix the server sending a GOAWAY when an LDS update with no 
   changes other than ordering is received.
   - netty: Fix NPE when a header with errors is received with 
   endStream=true. This was causing logs to be filled with errors when health 
   checkers didn’t specify a content type.
   - okhttp: Fix the Socket data race when shutdown/closed during 
   connecting that was causing a significant delay

*Dependencies*


   - Upgraded Netty to 4.1.93-Final
   - Update guava dependency to 32.0.1 to address CVE-2023-2976 
   

*Acknowledgements*


   - Benjamin Peterson
   - Masakuni Oishi
   - Philip K. Warren
   - Stephane Landelle

-- 
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/35d414c7-f647-450d-9b3a-e49411d103dan%40googlegroups.com.

[grpc-io] gRPC Meetup and office hours tomorrow (7/18)

['Larry Safran' via grpc.io]

Reminder that the first of the monthly meetup and office hours is scheduled 
for tomorrow from 2:30 - 3:30 PDT.

https://www.meetup.com/grpcio/events/294239754/

We will be using Google Meet.

Google Meet joining info
Video call link: https://meet.google.com/gkt-qgru-uom
Or dial: ‪(US) +1 541-834-1403‬ PIN: ‪831 608 479‬#
More phone numbers: https://tel.meet/gkt-qgru-uom?pin=4464054634143

Look forward to seeing many of you there

-- 
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/30257108-e82a-4610-bad7-f3a9ca9eb5d5n%40googlegroups.com.

[grpc-io] Re: Talk gRPC meetup

['Larry Safran' via grpc.io]

We have the first of the new meetups scheduled for July 18th at 2:30 PM PDT 
and monthly after that.

Anyone who is interested in giving a presentation should fill out the form 
at  https://forms.gle/YvW8rMuawGuw7Hcp8.

Thanks,
  Larry

On Wednesday, May 17, 2023 at 2:30:27 PM UTC-7 Larry Safran wrote:

> Hi Rajiv,
>   I am the right contact for this.  We're currently in the process of 
> revamping the community meetups (which is why there has been a short break).
> I really appreciate you offering to present and will get in touch with you 
> directly  once we are ready.
>
> Thanks,
>   Larry
>
> On Friday, May 5, 2023 at 2:45:33 PM UTC-7 Rajiv Singh wrote:
>
>> Hello,
>>
>> I am interested in presenting a demo or sharing slides on the background 
>> architecture of gRPC during the monthly gRPC meetups. My presentation will 
>> focus on "Exploring the Power of gRPC-Gateway for Writing REST Services." 
>> Could you please let me know whom I should contact to proceed with this 
>> request?
>>
>> Thank you.
>>
>> *Regards,*
>>
>> *Rajiv Ranjan Singh*
>>
>> *Portfolio ** | **GitHub 
>> ** | **LinkedIn 
>> ** | **Twitter 
>> *
>>
>

-- 
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/78c32549-4af4-4980-b4ef-532150d6acbbn%40googlegroups.com.

[grpc-io] Community Meetups and Office Hours

['Larry Safran' via grpc.io]

We are having our first "Community Meetup and Office Hours" event on July 
18th from 2:30 - 3:30 PDT.  Meetings will begin with a short presentation 
and then move into office hours where individual questions, suggestions or 
assistance will be available.  We will continue to have these at monthly 
intervals.  

*You can find more information at https://www.meetup.com/grpcio/ 
*

If you are interested in giving a presentation, please sign up at: 
https://forms.gle/YvW8rMuawGuw7Hcp8 

If you would like something to be addressed during office hours you can 
sign up at https://forms.gle/xCwNaKmjS9C3GGpz8.  Time permitting, we will 
also take drop in questions.

-- 
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/00fd4d98-ebda-45c8-b617-4982c248f9a5n%40googlegroups.com.

[grpc-io] Re: Talk gRPC meetup

['Larry Safran' via grpc.io]

Hi Rajiv,
  I am the right contact for this.  We're currently in the process of 
revamping the community meetups (which is why there has been a short break).
I really appreciate you offering to present and will get in touch with you 
directly  once we are ready.

Thanks,
  Larry

On Friday, May 5, 2023 at 2:45:33 PM UTC-7 Rajiv Singh wrote:

> Hello,
>
> I am interested in presenting a demo or sharing slides on the background 
> architecture of gRPC during the monthly gRPC meetups. My presentation will 
> focus on "Exploring the Power of gRPC-Gateway for Writing REST Services." 
> Could you please let me know whom I should contact to proceed with this 
> request?
>
> Thank you.
>
> *Regards,*
>
> *Rajiv Ranjan Singh*
>
> *Portfolio ** | **GitHub 
> ** | **LinkedIn 
> ** | **Twitter 
> *
>

-- 
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/0058293a-a6af-463c-8661-d4221933a794n%40googlegroups.com.

Re: [grpc-io] Re: relaying grpc calls

['Larry Safran' via grpc.io]

Instead of looking for it in Eric's personal repo, you can now find it in 
the master 
repository:  
https://github.com/grpc/grpc-java/blob/master/examples/src/main/java/io/grpc/examples/grpcproxy/GrpcProxy.java

On Sunday, May 7, 2023 at 6:50:04 PM UTC-7 Hakim Kahlouche wrote:

> @Eric: I tried to access the service-agnostic grpc proxy link below, but I 
> am getting 404 (not found):
> example service-agnostic gRPC proxy in Java 
> 
>
> Please let me know if there is a new link for it.
>
> Thanks
>
> On Tuesday, 22 January 2019 at 17:30:09 UTC-5 Eric Anderson wrote:
>
>> I wasn't saying "relay_request" was a "thing". I just used the 
>> terminology because you used the terminology.
>>
>> Glad the service-agnostic proxy looks good. I would encourage you to 
>> consider having a single port and choosing the service-agnostic proxy for 
>> only certain services; it removes the client from having to know what goes 
>> where.
>>
>> On Tue, Jan 15, 2019 at 11:51 PM  wrote:
>>
>>> @Eric, I did not find any mention of relay_request in the documentation. 
>>> However, I *loved* the service-agnostic proxy. 
>>> While reading the code it dawned on me that I can run an instance of 
>>> this proxy on L, and the client will simply send to port X to get to L, and 
>>> to port Y to get to R.
>>> I'm going to give this a try.
>>>
>>> Thanks a lot!
>>> Dan
>>>
>>> On Wednesday, January 16, 2019 at 9:13:17 AM UTC+2, dan.b...@huawei.com 
>>> wrote:

 That is half correct ;-)  in my scenario L is also a service provider, 
 but it is also a proxy for requests I need to send to R. 
 I was not aware of relay_request. I'll definitely check it out, as well 
 as your service-agnostic example.

 Thanks,
 Dan


 On Tuesday, January 15, 2019 at 5:57:43 PM UTC+2, Eric Anderson wrote:
>
> It sounds like L is just a proxy in that case. You use the 
> relay_request if that feels natural to you. You can also do "L7 load 
> balancing" by relaying requests at the HTTP/2 or gRPC level. I have made 
> an example 
> service-agnostic gRPC proxy in Java 
> .
>  
> My example proxies everything, but it is possible to also proxy only 
> services or methods. I think you can do semi-similar things in other 
> languages, although the difficulty may vary.
>
> On Mon, Jan 14, 2019 at 11:40 AM 'Carl Mastrangelo' via grpc.io <
> grp...@googlegroups.com> wrote:
>
>> Yes, this is possible.  You'll need to implement some unpacking 
>> scheme on L, but it can then forward the raw bytes of the request.   
>> Note 
>> that if you are  using Proto, you may not be able to use all the 
>> generated 
>> stub code.   If C, L, and R all know about the same message types, then 
>> you 
>> can use the proto stubs.
>>
>> Note also that the headers will need to be captured from C->L, and 
>> the response trailers from R->L.If you wanted this to be "delayed" 
>> in 
>> any way, it may get more tricky.  
>>
>> On Sunday, January 13, 2019 at 12:52:29 AM UTC-8, dan.b...@huawei.com 
>> wrote:
>>>
>>> Consider a grpc client C, and servers L & R (local & remote). 
>>> Servers L & R are connected. Client C can reach only server L.
>>>
>>> Client C needs to send a request to server R. 
>>>
>>> Can I create a "relay_request" message that server L will support, 
>>> where the body is the request to send to server R? (also dealing with 
>>> relaying the reply)
>>>
>>> Is there anything better I can do for such a scenario?
>>>
>>> Thanks,
>>> Dan
>>>
>> -- 
>> 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 post to this group, send email to grp...@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/fc766ee0-a9b7-46f2-bbd5-024c1fba3e1a%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+u...@googlegroups.com.
>>> To post to this group, send email to grp...@googlegroups.com.
>>> Visit this group at 

[grpc-io] gRPC-Java 1.54.1 Released

['Larry Safran' via grpc.io]

The v1.54.1 release  
is now available

*Bug Fixes*

   - core: Fix NPE race during hedging (#9853 
   ), fixing a Netty buffer 
   memory leak for cancelled RPCs


*Behavior Changes*

   - observability: Remove monitored resource detection for logging (#10026 
   )


*API stabilizations*

   - Stabilize GcpObservability (#10027 
   )

-- 
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/36feefdf-eaff-4b92-9e66-86634f876be4n%40googlegroups.com.

[grpc-io] Re: Followup question: Java Manual Flow Control

['Larry Safran' via grpc.io]

You are correct that this is basically doing the "normal" thing.  However, 
with the manual flow control you are explicitly controlling when it starts 
looking for messages rather than having that process trigger when a new 
message arrives.  This could be useful if you had time consuming 
initializations or were waiting for some event to happen before accepting 
messages.

On Saturday, March 4, 2023 at 1:51:36 PM UTC-8 Nathaniel Jones wrote:

> Hello,
>
> I'm following up on my questions here 
>  with another, 
> more specific question on the manual flow control example code 
> 
>  (any 
> feedback on my recent questions appreciated as well).
>
> My understanding of the example code is:
> 1. The client is sending the names to the server and respecting outbound 
> flow control with this condition 
> 
>  + 
> using its ready handler.
> 2. The server disables auto flow control 
> ,
>  
> which means that it won't process an onNext message (from the client) until 
> it calls request(1).
> 3. The server's ready handler then ensures the outbound direction (to 
> client) has capacity 
> 
>  before 
> it "primes the pump" by calling request(1) (and it later only ever calls 
> request(1) when there's outbound capacity). This use of manual flow control 
> is providing the invariant that "if the server processes an onNext, we know 
> there is capacity to send the ACK message to the client [without excess 
> buffering]." If the server *didn't* drop into manual flow control mode, 
> and simply processed onNext automatically when a message came in, it runs 
> the risk of its outbound onReady to be false, and then it's stuck with a 
> message that it can't ACK back to client safely (e.g. case where client 
> sends many messages to server quickly, but client can't receive them as 
> quickly).
>
> If that's all correct, my question is around the manual flow control in 
> the client code - the client drops into manual mode here 
> .
>  
> Its onNext 
> 
>  
> is very simple - print the message, and then call request(1). Is it fair to 
> say that the client's usage of manual flow control is simply 
> re-implementing "normal" behavior? The server code is doing what it needs 
> to do to make sure it's responding to the client 1 message at a time, so 
> wouldn't the overall example be the same if the client didn't use manual 
> flow control, and simply logged out the server message in its onNext?
>
> Thanks again!
>

-- 
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/d1fac687-49b9-485a-8734-022b49717063n%40googlegroups.com.

[grpc-io] gRPC-Java v1.51.1 Released

['Larry Safran' via grpc.io]

The 1.51.1 release  
is now available

Bug Fixes
   
   - xds: Fix ConcurrentModificationException in PriorityLoadBalancer. (
   #9744 )

-- 
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/29577f7a-37e9-4dcf-a068-36f8b58cfe42n%40googlegroups.com.