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

['Eric Anderson' via grpc.io]

grpc-netty in this release is compatible with Netty 4.1.111; it fixes the
incompatibility that caused data corruption. grpc-netty-shaded is still
using Netty 4.1.100.
New Features

   - New module grpc-gcp-csm-observability (df8cfe9
   

   )

Improvements

   - api: Add ClientStreamTracer.inboundHeaders(Metadata) (960012d
   
).
   This is the same as the existing inboundHeaders(), but is provided the
   Metadata
   - api: Fix various typos in the documentation (#11144
   ) (6ec744f
   

   )
   - core: When queuing RPCs, don’t request picks from the LB twice (8844cf7
   
).
   This could be viewed as a small performance optimization, but mainly
   reduces the amount of race-handling code
   - util: Improve AdvancedTlsX509KeyManager’s documentation, verification,
   and testing. (#11139 ) (
   781b4c4
   
)
   This change shows @ExperimentalApi being removed, but it was re-added in
   3c97245
   

before
   the release
   - examples: Fix broken command in reflection readme (#11131
   ) (c31dbf4
   

   )
   - binder: Add a connection timeout (#11255
   ) (791f894
   

   )

Bug fixes

   - core: Exit idle mode when delayed transport is in use (fea577c
   
).
   This was a long-standing race that could cause RPCs to hang, but was very
   unlikely to be hit. Avoiding the double-picking (8844cf7
   
)
   made the race more visible
   - netty: Fix Netty composite buffer merging to be compatible with Netty
   4.1.111 (#11294 ) (0fea7dd
   
).
   The previous behavior easily caused data corruption
   - okhttp: Workaround SSLSocket not noticing socket is closed (a28357e
   
).
   Previously, shutting down when a new connection was being established could
   result in the server never becoming terminated
   - inprocess: Fix listener race if transport is shutdown while starting (
   e4e7f3a
   
).
   This issue was unlikely to be hit outside of specialized tests
   - services: restore //services:binarylog bazel target (#11292
   ) (d57f271
   
).
   This fixes a regression introduced in 1.62.2
   - binder: Wait for all server transports to terminate before returning
   the security policy executor to the object pool (#11240
   ) (34ee600
   

   )
   - binder: Reject further SETUP_TRANSPORT requests post-BinderServer
   shutdown (#11260 ) (1670e97
   

   )
   - bazel: Include missing com_google_protobuf_javalite in MODULE.bazel (
   #11147 ) (f995c12
   

   )

Thanks to

@hakusai22 
@firov 
@mateusazis 
@Mir3605 
@niloc132 

-- 
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%2B4M1oOzWgJ%2BO6yU_Ud--0B31e-23Ybjw%2BdXQ48q%3D71Pg9chfA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRPC-Java and Netty 4.1.111 possible corruption

['Eric Anderson' via grpc.io]

Users of grpc-java should avoid upgrading to Netty 4.1.111 (released two
days ago), as it appears there is corruption. The issue is being tracked in
https://github.com/grpc/grpc-java/issues/11284

Little is known now, but best to delay the upgrade until more is known.

-- 
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%2B4M1oPyOgLfgkH%3DSuJ5oENd6vJvcLj5u1gdfkka%3DCMmVBOAtQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Error with building io.grpc.ManagedChannelRegistry

['Eric Anderson' via grpc.io]

The problem here is maven-assembly-plugin breaks SPI "services," because by
default it fails to combine some magic files together. This causes the dns
name resolver to not be found, and can prevent some transports and load
balancers also to not be found.

You need to configure it to use the metaInf-services handler. See
https://stackoverflow.com/a/49689041/4690866 (you can ignore the
metaInf-spring and plexus parts).

On Wed, May 22, 2024 at 9:03 AM 'Akash Sinha' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hello Everyone,
>
> I am trying to build a JAVA based gRPC client that tries to communicate
> with Python based gRPC server. I am getting the following exception when I
> run the code from terminal using the JAR file.
>
> Exception in thread "main"
> io.grpc.ManagedChannelRegistry$ProviderNotFoundException:
> io.grpc.netty.shaded.io.grpc.netty.NettyChannelProvider: does not support 1
> or more of [class
> io.grpc.netty.shaded.io.netty.channel.unix.DomainSocketAddress]
>
> at
> io.grpc.ManagedChannelRegistry.newChannelBuilder(ManagedChannelRegistry.java:204)
>
> at
> io.grpc.ManagedChannelRegistry.newChannelBuilder(ManagedChannelRegistry.java:155)
>
> at io.grpc.Grpc.newChannelBuilder(Grpc.java:101)
>
> The error happens while executing the following code:
> String target = "localhost:"+port;
>
> ManagedChannel channel = Grpc.newChannelBuilder(target,
> InsecureChannelCredentials.create()).build();
>
> However, the code runs fine when running the main class from the IDE. I
> have created the fat jar file using maven. Following is my pom.xml file.
>
> 
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
>
> org.example
> DummyEnv
> 1.0-SNAPSHOT
> 
> 
> io.grpc
> grpc-netty-shaded
> 1.63.0
> runtime
> 
> 
> io.grpc
> grpc-protobuf
> 1.63.0
> 
> 
> io.grpc
> grpc-stub
> 1.63.0
> 
>  
> org.apache.tomcat
> annotations-api
> 6.0.53
> provided
> 
>
>
> 
> 
> 21
> 21
> UTF-8
> 
>
> 
> 
> 
> kr.motd.maven
> os-maven-plugin
> 1.7.1
> 
> 
> 
> 
> org.xolstice.maven.plugins
> protobuf-maven-plugin
> 0.6.1
> 
>  >com.google.protobuf:protoc:3.25.1:exe:${os.detected.classifier} protocArtifact>
> grpc-java
>  >io.grpc:protoc-gen-grpc-java:1.63.0:exe:${os.detected.classifier} pluginArtifact>
> 
> 
> 
> 
> compile
> compile-custom
> 
> 
> 
> 
>
> 
> org.apache.maven.plugins
> maven-assembly-plugin
> 3.7.1
> 
> 
> jar-with-dependencies
> 
> 
> 
> 
> assemble-all
> package
> 
> single
> 
> 
> 
> 
> 
> 
> 
>
> Can someone please help me in debugging this issue?
>
> 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/4ab9aa81-5fb5-4176-91eb-298ee6e55dbcn%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%2B4M1oOqWp-8UB9_Yq74CSst1tvaS%2BoqN1bDrjCrJWcY6qsC2w%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] gRPC 1.55 Throughput Drop when Client Send Rate Increase

['Eric Anderson' via grpc.io]

On Sun, May 12, 2024 at 11:03 AM Yunhao Bai  wrote:

> When we are performing performance test and try to test the throughput for
> the gRPC server, we find there is a very strange behavior: When we increase
> the rate for unary RPC call to the gRPC server (e.g., from 15k rps to 50
> rps), we see a performance drop after some peak point.
>

I'm surprised that you are surprised. I thought it was well known that when
you over-saturate a server performance eventually decreases. Although that
looks pretty dramatic (not that I can read the image).

After our investigate, we find that there are many "default-executor"
> threads occupying CPU when there is a performance drop, and when there is
> no such phenomenon, everything goes fine. I also post the CPU utils when
> there is a performance drop and not with client rps equaling 50k.
>

Are you using grpc-java? "default-executor" definitely sounds like Java,
but you mention event engine later. Event engine is only for the C-based
implementation.

Assuming you are using grpc-java, specifying executor() on the server (and
channels) to a thread pool you manage can yield more performance. The
default executor is a basic unbounded Executors.newCachedThreadPool(). If
you know your maximum concurrency needs, limiting the maximum number of
threads can improve performance (either via ThreadPoolExecutor or
newFixedThreadPool()). Also, some workloads see benefit in using
ForkJoinPool (which is a fixed-sized thread pool).

If your application is mostly asynchronous, then choosing the number of
threads based on number of cores makes sense, somewhere between a bit less
than the number of cores to 2x. If you have a lot of blocking, then you'll
just have to experiment.

-- 
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%2B4M1oOL4jjJd-siQzWromo6W8Ver3b41A0YrqbP%3D6GcdDZ2Tg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] What is the suggested way to use onError on StreamObserver?

['Eric Anderson' via grpc.io]

On Sat, Apr 13, 2024 at 9:23 AM Debraj  wrote:

> I did not quite understand the statement - "*It will respond
> with Status.UNKNOWN and interceptors might get confused"* .
>
> Let's say I do not have the try - catch in the purge() method and I have
> a ServerInterceptor like below.
>

If you really want to throw and for it to be propagated, use
TransmitStatusRuntimeExceptionInterceptor
.
It has to be carefully placed in the interceptor chain to work well. But we
generally discourage using it because it can make understanding errors
difficult.

  handleException(ex);
>   throw ex;
>

This calls call.close() *and* throws an exception. That very well might be
racy. If you handle the exception (by calling close), don't re-throw the
exception. gRPC ignores the exception's contents and always uses UNKNOWN
when processing it.

If the HttpServer is not available then from gRPC2 server
Status.UNAVAILABLE error
> is thrown with some Metadata as shown below. But we are observing that
> sometimes the Metadata is not coming to gRPC1. It does not happen always.
>

If you get UNAVAILABLE without the Metadata you expect, then that was
probably a failure between gRPC1 → gRPC2. If the problem is caused by
throwing an exception, you'd see UNKNOWN instead. In either case, the
status description tells you a lot about what is going on, so if you want
us to tell you why something is happening, you need to give us the full
status.

-- 
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%2B4M1oPWRfK5M%2BUEWcUGFesedht%2B0UEg8EzDV0Vx5tSA7ww6hQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] GRPC client getting error while connecting to service UNAVAILABLE

['Eric Anderson' via grpc.io]

+grpc-io

error:UNAVAILABLE isn't a format that grpc-java uses. This may be your own
logging. You'll need to find it and include more information from the
Status. In particular, status.getDescription() and sometimes getCause()
have useful information.


On Sat, Apr 20, 2024 at 2:03 AM shobhit agarwal 
wrote:

> I am getting this error only:
> error:UNAVAILABLE
>
>
>
> On Sat, Apr 20, 2024 at 2:09 AM Eric Anderson  wrote:
>
>> On Thu, Apr 18, 2024 at 1:28 PM shobhit agarwal 
>> wrote:
>>
>>> suddenly it started failing with error:UNAVAILABLE while service was up
>>> and running
>>>
>> What was the error message?
>>
>

-- 
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%2B4M1oOr3JaKKccU9FiDq575aYpzsBmeeP8SMqOa4u2nWUedPA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] [grpc-Java] Query regarding ping deadline exceeded

['Eric Anderson' via grpc.io]

On Fri, Apr 12, 2024 at 11:53 AM R Chinmay  wrote:

> In both cases we receive a generic log with status DEADLINE_EXCEEDED.


I see "[grpc-Java]" in the email subject. Are you actually using grpc-java?
gRPC Java provides a lot of information in the string part of the status.


> 1. Can you provide code reference where client calls ping to server and
> waits for the ack?


Why are you talking about pings?

4. We saw that some of the calls receive `waiting_for_connection` in the
> description of the deadline exceeded exception on client side. Is it due to
> the ping call timing out or the method call timing out?
>

waiting_for_connection is part of the additional details that grpc-java
provides. To tell you what is happening, we need that debug information.

waiting_for_connection means the load balancer hadn't selected a connection
for the RPC. So that means the RPC was never sent. This is commonly caused
by slow DNS or connection establishment, or the server being unavailable.
waiting_for_connection is temporary; after a while the connection attempt
will fail and RPCs will fail, or the connection attempt succeeds and RPCs
are sent to a server.

-- 
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%2B4M1oPVN3_RsCq%2BUhYaYyNkTe1iy8bvjxtxKC11dF%3D2utQoNQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] GRPC client getting error while connecting to service UNAVAILABLE

['Eric Anderson' via grpc.io]

On Thu, Apr 18, 2024 at 1:28 PM shobhit agarwal 
wrote:

> suddenly it started failing with error:UNAVAILABLE while service was up
> and running
>
What was the error message?

-- 
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%2B4M1oP0Paw7cmCK7jXAKC7uqEFc10xVHcecZokUGpZpe2v3BQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] gRPC-Java Netty server handling of CONTINUATION frames

['Eric Anderson' via grpc.io]

Netty (and by extension gRPC Netty) is not affected.

On Thu, Apr 11, 2024 at 1:56 PM jamesne...@gmail.com <
jamesnether...@gmail.com> wrote:

> Hi,
>
> Given the recent news around vulnerabilities in the handling of of HTTP/2
> CONTINUATION frames:
>
>
> https://www.linkedin.com/pulse/understanding-continuation-flood-new-http2-protocol-baek--qmcwc
>
> I was wondering whether the gRPC-Java Netty based server could be
> affected? If so, is there any way to mitigate the problem?
>
> --
> James
>
> --
> 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/28994aea-a4cb-40ef-bf1a-2b7376541658n%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%2B4M1oPsQ6WUfiG3cT7Nv9s7SzBdOJ0h%3D96gJum%3D6-ct15brcw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] What is the suggested way to use onError on StreamObserver?

['Eric Anderson' via grpc.io]

If validator.validate() and service.purge() can throw, then you want a
try-catch. You must call onCompleted() or onError() on the observer for the
RPC to complete (and thus release its memory). gRPC does have some handling
for exceptions thrown by the service method, but it is a worst-case backup.
It will respond with Status.UNKNOWN and interceptors might get confused.

If you are very concerned, you can catch exceptions from onNext(). In
general code tends to assume onNext() won't throw (or rather, won't throw
randomly; it will totally throw if you use it incorrectly, like calling it
after onCompleted()). So that's why the Hello World example server doesn't
have a try-catch.

On Thu, Apr 11, 2024 at 1:55 PM Debraj  wrote:

> If I have a code like below on a Java-based gRPC service
>
>  @Override
>   public void purge(
>   final PurgeRequest request, final StreamObserver
> responseObserver) {
>   validator.validate(request);
>   responseObserver.onNext(service.purge(request));
>   responseObserver.onCompleted();
>   }
>
> Is it recommended that I catch the exception and call onError() like below
> or it is not recommended? Is there any advantage of one approach over the
> other?
>
>  @Override
>   public void purge(
>   final PurgeRequest request, final StreamObserver
> responseObserver) {
> try {
>   validator.validate(request);
>   responseObserver.onNext(gdprService.purge(request));
>   responseObserver.onCompleted();
> } catch (final Exception e) {
>   log.error("Failed to purge {}", request, e);
>   responseObserver.onError(e);
> }
>   }
>
>
> --
> 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/985e6aee-2de0-4ca4-b99e-f17e61297cc5n%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%2B4M1oPa2ieyMp%2BSW%3DwtjH4Kuuw1vxmxVEKiLRYr2JROzUNwHw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Channel Management from server side

['Eric Anderson' via grpc.io]

On Wed, Mar 27, 2024 at 7:15 AM Darshan J Gowda 
wrote:

> Question:
>
We discussed some on Gitter.
https://app.gitter.im/#/room/#grpc_grpc:gitter.im/$h_WHhXb5S4tREY8Z12CS5VXwaoot6ELcnn51vtW2LmE


>
>1.
>
>Is there a way for server to end a channel of a particular client if
>it wishes using grpc-java. I came across Interceptors where client info
>like Ip address can be accessed by server using interceptors.. in the same
>way can we use client channel context and interceptors to achieve
>particular channel of a particular client closing in grpc-java
>
> The server APIs don't allow shutting down a particular connection.


>1.
>
>Im aware of server.shutdown(). when its invoked on server side, it
>will close all the channels doesn't it ?
>
> It begins the shutdown process on connections. The client's channels will
reconnect.


>1.
>
>Is the above understanding (3rd point) correct? where does sub
>channels come into picture among channels, RPCs(streams) here. Are
>subchannels and streams same ?
>
> Channel: virtual connection to a service. May have 0 or many connections

Subchannel: semi-virtual connection to an address. May have 0 or many TCP
connections. It will have at most one connection for new RPCs, but may have
many old connections if the server sent GOAWAY but the RPCs on those
connections haven't completed.

Stream: an RPC on a specific TCP connection. The RPC will fail if the TCP
connection dies.

-- 
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%2B4M1oPi3JfpHTdwKX49QaoLXV4W693inbi%3D-_gkwgEPfgsxEQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Versioning: New features for existing RPCs

['Eric Anderson' via grpc.io]

Other options in no particular order:

   1. Have a repeated extensions field of type Any. An unknown message type
   should cause the server to fail the RPC. This is nicer than (b) because you
   can't forget to change the version when expecting a new feature, and it
   allows servers to implement subsets of features
   2. You could do something specialized for certain cases. For the search
   case, maybe you want to add a new query filter. That sort of thing could be
   handled by having a map filters or Struct filters. The
   server can fail if it doesn't understand a key. Assuming new filters is the
   most common change to the RPC, that could reduce the number of times you
   need to use one of the more annoying versioning approaches. You might not
   even need anything extra; for example if you already use a FieldMask for
   specifying which response fields you want set, then the server can fail if
   it doesn't know one of the requested fields. To avoid similar limitations
   to (a), you could use two FieldMasks, one for optional and one for required
   3. The server responds with its version in the response proto, or sets
   some field when it supports a feature. This approach would let the RPC
   complete, and then have the client verify the response. This could be like
   a revered (b), or the server response could include extra fields that need
   to be set based on the request fields. For example, let's say you add a
   "include_column_X" in the request, then that missing from the results would
   tell you the server is incompatible
  1. If more than one RPC is involved, the server can set a field in
  the first RPC that then can influence the client in later RPCs. For
  example, let's say the server supports deletes, then in a "get"
or "create"
  method it could set bool delete_allowed to true in the response. This
  is essentially the same as (4), but can feel cleaner in some circumstances
   4. Use a separate versioning service or method. Basically, instead of
   negotiating every RPC, you could have the client talk to the server once
   and get a list of versions or features. The client would verify that the
   server supports what it wants and then uses the other services/methods
   without additional checking
   5. Old-school bitfield/enum/feature-name set. This is basically the same
   as (b), but instead of a single version you have multiple dimensions that
   the server supports and the server checks it supports all the set
   bits/enum/feature-name values


On Mon, Mar 11, 2024 at 6:46 PM Brett Lawson  wrote:

> Hey everyone,
>
> I'm trying to understand what the best practices are around versioning for
> GRPC.  There have been a number of strategies employed in the world of
> RESTful APIs (like versioning headers), and protobuf's are typically argued
> as being cross-compatible as long as you make changes in a reasonable set
> of ways.  I'm however struggling to understand how it would be possible to
> allow cross-version compatibility when it comes to new features being added
> to existing RPCs whilst still dealing with older servers.
>
> For instance, if I have an RPC method that permits searching a data-set,
> and I later want to add a field which allows you to search with a higher
> degree of data consistency.  If a newer client were to send this field, a
> potentially older server might ignore this and not apply the new semantics,
> leading to the results being silently incorrect.
>
> I see a couple of mechanism that could solve this, namely:
> a. Have servers reject fields they do not understand.  This seems like a
> bad choice since it precludes other kinds of non-breaking changes.
> b. Use some form versioning header such that using the new fields requires
> you to advertise being a 'new client' and old servers would reject those
> requests.  This seems like unneccessary overhead.
> c. Add a new major version of the service (ie: adding my_service.v2 in
> addition to  my_service.v1).  This seems frustrating to deal with, since
> you have to duplicate the entire surface area of the API simply to iterate
> on a specific method.
> d. Add versions to individual RPCs (ie: adding MyQueryV2() in addition to
> MyQuery()).  I don't really see any examples of this 'in the wild' though,
> and seems like a messy solution.
>
> None of these solutions seem great or particularly often used, so I'm
> hoping there might be some beautiful and elegant solution I'm missing :)
>
> Thanks, Brett
>
> --
> 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/bec19f82-553c-462b-b84d-e48b0f03e47bn%40googlegroups.com
> 

Re: [grpc-io] URGENT: Sending async response over grpc

['Eric Anderson' via grpc.io]

+grpc-io, so Go folks can answer

On Tue, Mar 19, 2024 at 9:05 PM Abhijeet Tiwari 
wrote:

> Hey, thanks a lot for the response!
>
> My server is actually written in golang.
> I also wanted to know that I'll have to use a combination of for loop with
> some time.Sleep() maybe to keep the server streaming rpc alive. I can't
> return the rpc function in case I want to use this connection later. Am I
> correct?
> So let's say there are multiple connections tomorrow at the same point of
> time, which means this for loop and time.Sleep() will keep holding up
> goroutines until we send the response through rpc and return. Will that
> affect the server performance or go routines are light and this will be
> handled easily.
> My whole concern is around is there any method to keep a server streaming
> rpc alive without using a for loop? Or that has to be there to keep the
> connection alive.
>
> On Tue, 19 Mar 2024 at 22:54, Eric Anderson  wrote:
>
>> On Wed, Mar 13, 2024 at 1:11 PM Abhijeet Tiwari 
>> wrote:
>>
>>> 1) let's say a java based client that has opened a server streaming rpc
>>> 2) after this, we are to receive some info through a webhook on our
>>> server, but it might take some time
>>> 3) we have to send this info received over webhook to the java based
>>> client over the server streaming rpc
>>>
>>
>> You keep mentioning the Java client. What language is your server?
>>
>> 4) my question is, is there a way i can store the info of that stream and
>>> then invoke stream.Send() when i receive the info over webhook
>>>
>> 5) also, there might be 3 different servers(with a load balancer), so the
>>> rpc could be opened over 1st, but the webhook hit would have occured on
>>> 3rd, so even if i store this stream object on a global, let's say redis
>>> cache, will I be able to establish a connection to the client from the 3rd
>>> server?
>>>
>>
>> The stream is not a data object. It can't be serialized and stored in a
>> DB. It is only useful on the server that has the object. You can't
>> establish a new connection to the client; you can only use the existing one.
>>
>> Instead of storing the stream in Redis, you could generate a unique key
>> and store the stream in a map on the server that received the stream. Then
>> store (server id, stream key) in Redis. When the webhook fires, forward
>> the information to the appropriate server and have that server send back to
>> the client.
>>
>

-- 
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%2B4M1oOrXVaj8MyqXohOCE9RU7a3rhimqrmi-Gr5VGv1%2BEg_xg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] who else is looking for an active (discord) community?

['Eric Anderson' via grpc.io]

The "Unofficial gRPC Community" Discord server from the last discussion
 was
essentially a failed experiment. People joined, but there was not a
*single* discussion.
Gitter actually has some activity, so it isn't dead but rather pretty
quiet. People ask plenty of questions, but only a few times over its life
did users answer each other's questions. GitHub discussions aren't enabled
on most repos; I enabled them last week(?) for grpc-java. It is something
that we were going to experiment with, but mostly as an alternative to
issues and the mailing list.

Part of the trouble is Germany and California have quite the timezone
difference, so like the complaint "people show up in 12h interval" in that
last thread is just saying "people aren't in my timezone." I definitely
agree that is the case, but there's not much those of us in California can
do about it.

On Mon, Mar 18, 2024 at 7:53 PM ji-podhead 
wrote:

> theres no channel on discord. gitter and git-discussion are dead.
> i dont have any slack invites.
> k8s groups have no grpc sub.
> maybe we should start a server on our own?
> love from germany:
> ji
>
> --
> 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/1c4be26b-9c37-40b8-b965-01eeaffccf8dn%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%2B4M1oM7C5nmr034%2BchK-N6TaJgetKe3uUQQS6vv8_BarTuPCA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] URGENT: Sending async response over grpc

['Eric Anderson' via grpc.io]

On Wed, Mar 13, 2024 at 1:11 PM Abhijeet Tiwari 
wrote:

> 1) let's say a java based client that has opened a server streaming rpc
> 2) after this, we are to receive some info through a webhook on our
> server, but it might take some time
> 3) we have to send this info received over webhook to the java based
> client over the server streaming rpc
>

You keep mentioning the Java client. What language is your server?

4) my question is, is there a way i can store the info of that stream and
> then invoke stream.Send() when i receive the info over webhook
>
5) also, there might be 3 different servers(with a load balancer), so the
> rpc could be opened over 1st, but the webhook hit would have occured on
> 3rd, so even if i store this stream object on a global, let's say redis
> cache, will I be able to establish a connection to the client from the 3rd
> server?
>

The stream is not a data object. It can't be serialized and stored in a DB.
It is only useful on the server that has the object. You can't establish a
new connection to the client; you can only use the existing one.

Instead of storing the stream in Redis, you could generate a unique key and
store the stream in a map on the server that received the stream. Then
store (server id, stream key) in Redis. When the webhook fires, forward the
information to the appropriate server and have that server send back to the
client.

-- 
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%2B4M1oOhETx8swxab3wqDqFVUi9_mdOttin%2BNMhsJVLO8xPn0w%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] GRPC_ARG_HTTP2_MAX_PING_STRIKES in Java

['Eric Anderson' via grpc.io]

Yeah, app_requested looks part of normal server.shutdown() flow. But it
probably isn't the true cause of the error. What is probably happening is
the RPC isn't completing in time and then you call server.shutdownNow(),
which closes the connection. That connection closure is what actually
causes the error.

When the connection closes there's not too much error information
available. The client ends up saving the earlier GOAWAY (from shutdown())
in hopes it is related to the connection closure and sheds light on
debugging.

On Wed, Feb 7, 2024 at 2:50 PM James M  wrote:

> Hi Eric,
>
> I am not positive that I need it.  I am trying to run some experiments to
> debug a race condition I am encountering in one of my unit tests.  The unit
> test is around asserting graceful shutdown of grpc servers (that requests
> were accepted and complete within the awaitTerminate timeout).
>
> The exact error I receive is "  io.grpc.StatusRuntimeException:
> UNAVAILABLE: Connection closed after GOAWAY. HTTP/2 error code: NO_ERROR,
> debug data: app_requested".
>
> As far as I can tell, this error results from the close method of the
> Netty Server Handler being called without a Graceful Shutdown set.  There
> is nothing specifically wrong with that, except that I cant figure out why.
>
> Any tips are appreciated.
>
> Thanks,
> James M.
>
> On Tuesday, February 6, 2024 at 4:17:35 PM UTC-8 Eric Anderson wrote:
>
>> Java does not have a setting for adjusting the maximum ping strikes. Why
>> do you need to adjust it? Typically adjusting it higher doesn't change
>> whether the connection would get killed. It just delays it a little bit.
>>
>> On Wed, Jan 31, 2024 at 2:52 PM James M  wrote:
>>
>>> Hi,
>>>
>>> In Java, is there a way to override the grpc default value for
>>> GRPC_ARG_HTTP2_MAX_PING_STRIKES?
>>>
>>> I do not see a method exposed to do this in the ServerBuilder?
>>>
>>> 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+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/2a422e07-f676-45e3-9d41-5a56121876c9n%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/acfc61d7-1bec-45ca-8936-3f21159c5306n%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%2B4M1oP7e4%3DJ1qLUG58wprBzpUntxtpNK6ywnv40Uy0EimOstg%40mail.gmail.com.

Re: [grpc-io] Re: [gRPC-Java] Degradation with larger number of Repeated elements

['Eric Anderson' via grpc.io]

I've not forgotten about your issue.

It is likely not grpc-java related, so I've been trying to find some time
to make a Java client and show it doesn't have the same change in
performance.

On Tue, Feb 20, 2024 at 7:22 AM Asha M.J  wrote:

> Could someone please help here?
>
> On Friday, February 16, 2024 at 4:28:44 AM UTC+5:30 Asha M.J wrote:
>
>> Hi,
>> I am comparing gRPC vs REST performance for responses with multiple
>> repeated elements. i am seeing the performance of gRPC is better with
>> lesser number of children, but degrades with increasing number of repeated
>> elements.
>> I have already created a issue here -
>> https://github.com/grpc/grpc-java/issues/10891
>> Please refer the above issue for client-server setup and more details.
>> Could you please help me 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/fa561184-d1e9-434b-bf1c-70c98dd967d4n%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%2B4M1oMUxo6VqdqTw8Pf8EsdrgZj9OQ-deA6KY6QKznbgHeaXA%40mail.gmail.com.

Re: [grpc-io] GRPC_ARG_HTTP2_MAX_PING_STRIKES in Java

['Eric Anderson' via grpc.io]

Java does not have a setting for adjusting the maximum ping strikes. Why do
you need to adjust it? Typically adjusting it higher doesn't change whether
the connection would get killed. It just delays it a little bit.

On Wed, Jan 31, 2024 at 2:52 PM James M  wrote:

> Hi,
>
> In Java, is there a way to override the grpc default value for
> GRPC_ARG_HTTP2_MAX_PING_STRIKES?
>
> I do not see a method exposed to do this in the ServerBuilder?
>
> 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/2a422e07-f676-45e3-9d41-5a56121876c9n%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%2B4M1oPNJh__TiL%2BAtiChKreJ4O%3DJCttoL-5Tzx8OvMAHboxNw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] TCP connections per channel

['Eric Anderson' via grpc.io]

On Wed, Jan 17, 2024 at 12:50 PM Kumaran Loganathan <
kumaranloganatha...@gmail.com> wrote:

> How many TCP connections does a channel create and manage provided the DNS
> resolution of the server resolves to one ip address?


Technically, this is a decision that the client-side LB policy makes.
However, none of our policies currently create more than one connection per
IP to send *new* RPCs. If you use long-lived RPCs, there could be old TCP
connections with those old RPCs on them, but those connections will close
when the RPCs complete.

The default LB policy is pick_first, which only has one "active" TCP
connection independent of the number of IP addresses. round_robin has one
active connection per IP.

-- 
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%2B4M1oMuzbFhkM5D3Ffq%3Dtvx%2BccirFFyGa4urOgs3qVfXpn-Mw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRPC-Java 1.60.0 Released

['Eric Anderson' via grpc.io]

The v1.60.0 release 
is now available.

API Changes

   - api: Stabilize ForwardingServerBuilder, ForwardingChannelBuilder2, and
   ForwardingChannelBuilder. Note that ForwardingChannelBuilder is
   stabilized (no changes will be made to it), but immediately deprecated in
   favor of ForwardingChannelBuilder2. (#10586
   )
   - api: Deprecate ForwardingChannelBuilder.delegate(). De facto this
   deprecates the class itself, since all classes extending
   ForwardingChannelBuilder implement the delegate() method. See javadoc
   for details (#10587 )
   - api: Changed recently-introduced LoadBalancer.acceptResolvedAddresses() to
   return Status instead of boolean (#10636
   ). This is part of
   continued work to align the LB API cross-language and API stabilization
   - stub: Deprecate StreamObservers (#10654
   )
   - alts: AltsChannelBuilder now extends ForwardingChannelBuilder2 (#10587
   )
   - protobuf: Stabilize ProtoUtils.metadataMarshaller() (#10628
   )
   - protobuf-lite: ProtoLiteUtils experimental comment (#10627
   )

Behavior Changes

   - core: ManagedChannels now check the address types provided by the
   nameResolver (for the given target) with the address types supported by the
   channel transport and generate an error in case of mismatch. That
   dramatically improves the error message when an issue occurs
   - core: When a server stream is closed due to user's code (an uncaught
   exception in halfClosed, messagesAvailable, onReady callback of a
   ServerStream's listener), the Status.UNKNOWN returned to the client will
   have Application error processing RPC description. Previously the
   description was empty. This is helpful to differentiate between server
   errors originated in user application, gRPC library, or even those injected
   by a proxy. (#10643 )
   - xds: Log ORCA UNIMPLEMENTED error to subchannel logger. This removes
   them from the normal application logs, reducing log spam

Improvements

   - Change the underlying implementations of RingHash, RoundRobin,
   WeightedRoundRobin and LeastRequest load balancers to utilize the pick
   first load balancer rather than directly manage subchannels. This should
   only be noticeable if it introduced a bug
   - core: Avoid flushing headers when the server returns a single response
   (#9314 ). This is a
   performance optimization to reduce the number of packets for non-streaming
   responses
   - util: Make grpc-core an implementation dependency. This will prevent
   the io.grpc.internal classes in grpc-core from being visible during
   compilation when depending on just grpc-util
   - netty: Implement Http2Headers.isEmpty(). This fixes compatibility with
   Netty 4.1.101.Final.
   - netty: Add NettyServerBuilder.maxRstFramesPerWindow(). This can be
   used to limit impact of Rapid Reset
   - netty: Disable huffman coding in headers (#10563
   ). Huffman coding provides
   modest compression for relatively high CPU usage, especially within a data
   center. Rely just on the HPACK static and dynamic tables for compression,
   for higher performance. This only impacts header values 512 bytes or
   longer, as Netty already disabled Huffman for smaller values
   - alts: Improve handshake failure error message by propagating original
   exception (#10644 )

Bug Fixes

   - util: Remove shutdown subchannels from OD tracking (#10683
   ). This could have caused
   a memory leak on a long-lived channel. But we don’t think it could be
   triggered with our built-in load balancing policies.

Dependencies

   - Bump Netty to 4.1.100.Final

Acknowledgements

@anthonyjpratti 
@fedorka 
@jpd236 
@mateusazis 
@pkoenig10 
@yannickepstein 
@amirhadadi 

-- 
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%2B4M1oP39E82MCdGEM2tPdXjpzP2q5r5a0Q_M%3DHt48neBCxAxg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

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

['Eric Anderson' via grpc.io]

The v1.59.1 release 
is now available.


   - netty: Implement Http2Headers.isEmpty(). This fixes compatibility with
   Netty 4.1.101.Final.
   - netty: Add NettyServerBuilder.maxRstFramesPerWindow(). This can be
   used to limit impact of Rapid Reset
   - xds: Log ORCA UNIMPLEMENTED error to subchannel logger. This removes
   them from the normal application logs, reducing log spam

-- 
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%2B4M1oM2PXS3s0K4_B2Q%2BQZn2rHp0Ag3Fs5W0cdRRFWOnNWsFA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Grpc - Java server side streaming handling backpressure

['Eric Anderson' via grpc.io]

On Thu, Nov 16, 2023 at 2:44 PM Vivek Shindhe 
wrote:

> But this leads to a thread block situation, while the main thread is
> waiting to restart again the "onReadyHandler" is never invoke which blocks
> the publishing to the stream.


Seems you already have an understanding of the situation. Yes, the
callbacks are not considered thread-safe, so the onReady() can't be called
until the previous callback returns. Remove the polling sleep and return is
the encouraged solution. You could also keep the sleep and do polling on
isReady(), at the cost of latency.

-- 
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%2B4M1oOZzSEfp%2BwpchKq_sWpdgg_yNdFYn83_S9agNKXdpRV0A%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

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

['Eric Anderson' via grpc.io]

On Mon, Nov 27, 2023 at 3:02 PM John Wilson  wrote:

> Is this implementation correct?
>

Looks fine.

Is this thread safe?
>

Context is immutable (although the values could be mutable, but then you'd
be responsible for synchronization). And the "current" Context is stored in
a ThreadLocal. So, yes, it is thread-safe.

Is there any way to test that implementation?
>

The way to give you the most confidence would be using in-process
transport, like other tests. In your test case you'd make a test service
implementation that does USER_ID.get(), and then send it an RPC. You may
find grpc-testing-proto (io.grpc.testing.protobuf) useful, as it has a
simple service you can implement for testing. That will use multiple
callbacks (within the stub) and give you the highest confidence.

It'd also be possible to test the interceptor "bare" by implementing a
ServerCallHandler. io.grpc.testing.TestMethodDescriptors.voidMethod() is
available as a MethodDescriptor. ServerCall could be a ForwardingServerCall
whose delegate() throws, and then you override any methods your test needs.
That may give you less confidence in your understanding of
Contexts.interceptCall().

Is there any documentation that I can check to understand how Threads are
> handled by the grpc server?
>

There's some docs on ServerCall.Listener. Basically, there's multiple
callbacks, and they won't be called concurrently but may be called from
different threads. So if you set a ThreadLocal in one, you may not see it
in the next. Contexts.interceptCall sets the ThreadLocal, calls the
callback, and then unsets the ThreadLocal before returning.

-- 
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%2B4M1oORkBi6gRh-gjqwGeK8k7huWRmM1iH6xY-m6nsi909m-w%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Switching from direct executor to threaded executor after rate limiting

['Eric Anderson' via grpc.io]

On Tue, Nov 14, 2023 at 11:44 AM Krishna Sai Veera Reddy <
krishnasaiveerareddy...@gmail.com> wrote:

> >Is there a problem with running it on another thread?
> This basic rate limiter just increments/decrements a counter and nothing
> more so it seems wasteful to use a thread to do this.
>

"wasteful." It isn't generally wasteful as the same thread will be used to
process the request. It isn't "waste" as much as "what level of rejection
rate does my server need to support" and whether doing the processing in
another thread is able to satisfy that need. Doing the processing in
another thread isn't very expensive, depending on your baseline for cost:
it is a few atomic writes and some latency.

The request will be deserialized before calling the interceptor, which can
be considerable CPU. To delay that until after your interceptor,
use ServerInterceptors.useInputStreamMessages().

For such cases how do we switch executors? Even if it isn't recommended I
> would love to know how this can be done theoretically. Thank you for your
> response!
>

To just use an interceptor: To have the application code run in a
different thread than the interceptor, you'd need to wrap all the
ServerCall.Listener methods and schedule them on your own executor. You
need to make sure the callbacks don't execute concurrently, so probably
would use Guava's MoreExecutors.newSequentialExecutor(Executor).

To use ServerCallExecutorSupplier with an interceptor: it's a bit tricky.
You could make a ServerCallExecutorSupplier that detects if the rate limit
is already exceeded and returns a direct executor. Then the interceptor
detects it is running in the direct executor and fails the RPC.

On Tuesday, November 14, 2023 at 10:24:53 AM UTC-8 Eric Anderson wrote:
>
>> On Wed, Nov 8, 2023 at 9:46 AM Krishna Sai Veera Reddy <
>> krishnasaiv...@gmail.com> wrote:
>>
>>> I am implementing a gRPC service and have a use-case where I need to
>>> rate limit RPC calls but would like the rate limiting server interceptor to
>>> run directly on the network thread as it is non-blocking(Using direct
>>> executor).
>>>
>>
>> Is there a problem with running it on another thread? Even for
>> fully-async workloads we would discourage using direct executor as it can
>> significantly impact latencies.
>>
> --
> 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/8d96019c-584c-4497-bcb7-821ee48b6b39n%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%2B4M1oMMkOVgrfW3G3dy%2BB_ug%2BONnEd5MoQP3isp6TJDJgoesA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Switching from direct executor to threaded executor after rate limiting

['Eric Anderson' via grpc.io]

On Wed, Nov 8, 2023 at 9:46 AM Krishna Sai Veera Reddy <
krishnasaiveerareddy...@gmail.com> wrote:

> I am implementing a gRPC service and have a use-case where I need to rate
> limit RPC calls but would like the rate limiting server interceptor to run
> directly on the network thread as it is non-blocking(Using direct executor).
>

Is there a problem with running it on another thread? Even for fully-async
workloads we would discourage using direct executor as it can significantly
impact latencies.

-- 
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%2B4M1oOOZGKX8QBf4s0Ui%2BqmWEq7XPUZ5uZzny0Ku_3wz2tREQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Interrupted exception when using blocking call with stubs reuse

['Eric Anderson' via grpc.io]

gRPC does not interrupt threads. So if you are seeing thread interruption,
that is triggered by your code. Also, without the full exception, there's
not much to go on (and interruption is generally hard to figure out even
with the full exception).

Stubs and channels are thread-safe, so you don't need to use stubPool,
unless you were purposefully reducing the overall concurrency. You should
also generally share channels across RPCs. Stubs are cheap, but the channel
is expensive.

On Thu, Nov 9, 2023 at 1:54 PM Dinesh Adwani  wrote:

> I have grpc implemnetaion in java where i am using a blocking stubs
> i am using those stubs from pool and
> interestingly when load increases i see interrupted exception
>
>
> My requirement is to reuse channel and stubs
>
> What is correct way to reuse channel and stubs ?
>
>
>
>
>
> public ComputeVariableServiceGrpc.ComputeVariableServiceBlockingStub
> getOrCreateStub() {
> ComputeVariableServiceGrpc.ComputeVariableServiceBlockingStub stub
> = null;
> try {
> stub =
> stubPool.poll(grpcProperties.getClient().getClientPoolTimeoutInMillis(),
> TimeUnit.MILLISECONDS);
> if (isNull(stub) || isChannelClosed((ManagedChannel)
> stub.getChannel())) {
> log.debug("Stub not available in queue or connection was
> closed,  creating one...");
> stub =
> ComputeVariableServiceGrpc.newBlockingStub(newManagedChannel());
> }
>
> }
> catch (InterruptedException e) {
> log.error("Error while waiting for stub from pool: [{}],
> [{}]", e.getCause(), e.getMessage());
> }
> return stub;
> }
>
>
> public ComputeVariablesResult computeVariable(String payload, String
> typeId) {
> ComputeVariableServiceGrpc.ComputeVariableServiceBlockingStub
> computeVariableServiceBlockingStub = getOrCreateStub();//poll from stub pool
> CdsComputeVariablesResult response =
> CdsComputeVariablesResult.newBuilder().build();
>
> try {
> Request request =
> CdsComputeVariablesRequest.newBuilder().setTypeId(typeId).setPayload(payload).build();
>
> return
> computeVariableServiceBlockingStub.computeVariables(request);
> }
> }
> catch (StatusRuntimeException statusRuntimeException) {
> if (statusRuntimeException.getCause() != null) {
> log.error("Error while computing variables, error cause
> and message is:  [{}] [{}]", statusRuntimeException.getCause(),
> statusRuntimeException.getStatus().getDescription());
> }
> else {
> log.error("Error while computing variables, error message
> is:  [{}]", statusRuntimeException.getStatus().getDescription());
> }
> }
> finally {
> log.debug("Stub returned to queue");
> releaseStub(computeVariableServiceBlockingStub);//release to
> pool
> }
> log.debug("ComputeVariableResult with typeId: [{}] is  [{}] ",
> typeId, response);
> return response;
> }
>
> public void
> releaseStub(ComputeVariableServiceGrpc.ComputeVariableServiceBlockingStub
> computeVariableServiceBlockingStub) {
> boolean added = stubPool.offer(computeVariableServiceBlockingStub);
> if (!added) {
> log.info("Failed to add stub to the pool, remaining capacity
> is:  [{}]", stubPool.remainingCapacity());
> }
> }
>
> public void destroy() {
> stubPool.forEach(stub -> {
> if (nonNull(stub.getChannel())) {
> ((ManagedChannel) stub.getChannel()).shutdown();
> }
> });
> stubPool.clear();
> }
> }
>
> --
> 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/0c3ab2f1-72ae-4705-ba91-9ec11af10d20n%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%2B4M1oOH0X5sHk-%2Bo7j%3D%2BVUdZngFXYaRFjt9X7SKHac_f66PLg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Re: How to look up server?

['Eric Anderson' via grpc.io]

IServiceManager looks to be only for Binder, so it doesn't make sense to
use it with a plain HTTP/2. You'd need to know the port the server is
running on for that. But your high-level goals are unclear. So you'd have
to give more background on your use-case for me to give a better reply, as
you may need a substantially different approach.

On Fri, Sep 22, 2023 at 4:38 AM 'Mark Brophy' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hi Srini, can you say more about your use case?
>
> Are you planning to use a regular network/http transport, or is this about
> the binder-based transport (i.e. io.grpc.binder.*)?
>
> MarkB
>
> On Thursday, 31 August 2023 at 11:23:18 UTC+2 Srinivas Naik wrote:
>
>> Hi,
>> I am new to gRPC and analyzing this as an alternative for IBinder in
>> Android.
>> In Android a client can look up for server using
>> IServiceManager.getService("service_name"); How to do this using gRPC?
>> How can clients look up for service from a service manager like in
>> Android?
>>
>> Thanks
>> Srini
>>
> --
> 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/6579ea0a-897c-42db-bf55-095c0be6eeaan%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%2B4M1oPM%2BOi%3DR4bKeJWhJVZkWA_r5oCodE26Duw%3DL-bmyKPu%3Dw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Java 8 / Java 11 support timeline in gRPC?

['Eric Anderson' via grpc.io]

Yeah... It's been hard to have clear messaging here, because we've been
trying to figure it out. The messaging is mostly avoiding over-promising,
but where "in practice" fits in is still murky.

gRFC P5 says we could have "dropped" Java 8 already. That's obviously not
happened. v1.57.0 did have the oops for Java 8, but that was an accident
due to tooling dropping Java 8 support. That "oops" was pretty useful as
many Java 8 users noticed very soon after the release, which is a strong
demonstrator of interest. Upstream Java 11 becomes security-only support at
the end of the month, and I'm already seeing tooling drop it, so we're
probably going to have to use Java 17 for release builds soon (still with
support for Java 8).

"dropped" is not the right word. Even after we drop Java 8 from master,
we'd keep a branch alive for it. And as long as people remain interested in
it we can have fixes and releases. Given the community discussions I've
heard, I don't think interest in Java 8 will die before Temurin's Nov 2026
(currently promised) support ends. Google at least looks like it would
remain interested

to
that point (Sept vs Nov is basically the same at this distance).

The thing I don't know is at which point Java 8 is dropped from master, and
stops seeing new features. Earlier this year I knew "we'd wait at least
until September," so that Java 8 and 11 would share a branch. But now that
we're here in September... ??? Probably sometime between 6 months from now
and 2026...

On Thu, Aug 31, 2023 at 1:44 PM 'Dane Pitkin' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hello,
>
> Has there been any discussion or decision on how long Java 8 and Java 11
> will be supported in gRPC? This closed issue[1] suggests support for both
> will be dropped in September 2023 when Java 21 is released, but I'm not
> sure if this is still planned.
>
> Thanks!
>
> [1] https://github.com/grpc/grpc-java/issues/9386
>
> --
> 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/4f853273-0f4d-40c1-9035-67bca9c4b877n%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%2B4M1oOgzQ1qF%3DicOMurv1uAvnxq5O2Ho0TZNVprz%2BMTZ259%2BA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] gRPC netty NoRouteToHostException

['Eric Anderson' via grpc.io]

It is unlikely this is related to overloading the backends, unless some
monitoring system thinks the backends are broken and reboots/replaces them.
This is a network error, where packets can't be sent from your client to
the server. For example, if someone unplugged a network cable, this is the
sort of error you'd get. It could also mean internet/WAN connectivity has
been lost.

On Sat, Aug 26, 2023 at 11:20 AM Bhuvi Viji  wrote:

> Before I get this exception almost 4Million request processed without any
> issues and it's suddenly throwing error later after sometime it works fine.
>
> On Sat, 26 Aug, 2023, 9:42 pm Bhuvi Viji,  wrote:
>
>> Hi - This is issue is re-occurring even when there are no deployments on
>> the upstream servers.
>>
>> My gRPC service is a unary service , Batch application calls my gRPC
>> service using blocking stub.
>>
>> My gRPC service intern calls two different gRPC services to retrieve the
>> data (upstream gRPC service 1) and do some calculation using the data
>> retrieved((upstream gRPC service 2)
>>
>> Since it runs in batch mode, earlier My gRPC service was not able to
>> limit the request that it gets, and it went to unhealthy status so as per
>> the suggestion #10164  from
>> this ticket, Have implemented netflix concurrency limiter at my gRPC
>> service so it allows the request based on the system capacity and for the
>> rest of the other request it throws Server limit reached error.
>>
>> Upstream services that my GRPC calls has also has limitation so it can
>> handle a subset of request what i get mygRPC service can handle. To apply
>> backoff on the client calls from my application have used same netflix
>> client concurrency limiter. Even after having proper concurrency limiting ,
>> I'm getting the NoRouteToHostException. I understand this is something due
>> to overloading the service , is that understanding right or what else are
>> the possibility of getting into this exception?
>>
>> Caused by:
>> io.grpc.netty.shaded.io.netty.channel.AbstractChannel$AnnotatedNoRouteToHostException:
>> No route to host: applicationALB/*.*.*.*:443
>> Caused by: java.net.NoRouteToHostException: No route to host
>> at java.base/sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
>> at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
>> at
>> io.grpc.netty.shaded.io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:330)
>> at
>> io.grpc.netty.shaded.io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334)
>> at
>> io.grpc.netty.shaded.io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:707)
>> at
>> io.grpc.netty.shaded.io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
>> at
>> io.grpc.netty.shaded.io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
>> at
>> io.grpc.netty.shaded.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>> at
>> io.grpc.netty.shaded.io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>> 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(Unknown Source)
>>
>> On Thursday, 17 August 2023 at 16:09:50 UTC+5:30 Bhuvi Viji wrote:
>>
>>> Thanks Eric. Will check this option
>>>
>>> On Monday, 14 August 2023 at 21:57:14 UTC+5:30 Eric Anderson wrote:
>>>
 You get that exception because all backends failed to be connected to.
 I expect this is a server deployment-approach problem. Does the service do
 a rolling restart?

 The only thing the client can do to avoid the error is use
 stub.withWaitForReady(). But that implies you care more about reliability
 than latency. I'd consider using it for this purpose to be a hack.

 On Fri, Aug 11, 2023 at 7:48 AM Bhuvi Viji  wrote:

> My application calls a gRPC service(application B) using blocking stub
> to fulfill the request. End to End flow works fine without any issues.
>
> If there are any deployments in the gRPC service (application B) which
> my application consumes we get into NoRouteToHostException. We are trying
> the request only after the successful deployment of Service B. I 
> understand
> the channel is interrupted and it needs time to recreate the connections
> and re-establish. Is there any recommendation for get ridding of this kind
> of exception during the upstream servers deployments/new pod creation?
>
> Caused by:
> io.grpc.netty.shaded.io.netty.channel.AbstractChannel$AnnotatedNoRouteToHostException:
> No route to host: ***.com/Ipaddr:443
>
> --
> You received this message because you are subscribed to the Google
> 

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?

['Eric Anderson' via grpc.io]

This was also discussed on Stack Overflow
.
I filed https://github.com/grpc/grpc-java/issues/10517 for the delayed
transition to CONNECTING. It won't change performance any, though.

On Fri, Aug 25, 2023 at 9:55 AM 'Sanjay Pujare' via grpc.io <
grpc-io@googlegroups.com> wrote:

> 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 <
> grpc-io@googlegroups.com> 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
>>>
>>> ```
>>> 

Re: [grpc-io] gRPC netty NoRouteToHostException

['Eric Anderson' via grpc.io]

You get that exception because all backends failed to be connected to. I
expect this is a server deployment-approach problem. Does the service do a
rolling restart?

The only thing the client can do to avoid the error is use
stub.withWaitForReady(). But that implies you care more about reliability
than latency. I'd consider using it for this purpose to be a hack.

On Fri, Aug 11, 2023 at 7:48 AM Bhuvi Viji  wrote:

> My application calls a gRPC service(application B) using blocking stub to
> fulfill the request. End to End flow works fine without any issues.
>
> If there are any deployments in the gRPC service (application B) which my
> application consumes we get into NoRouteToHostException. We are trying the
> request only after the successful deployment of Service B. I understand the
> channel is interrupted and it needs time to recreate the connections and
> re-establish. Is there any recommendation for get ridding of this kind of
> exception during the upstream servers deployments/new pod creation?
>
> Caused by:
> io.grpc.netty.shaded.io.netty.channel.AbstractChannel$AnnotatedNoRouteToHostException:
> No route to host: ***.com/Ipaddr:443
>
> --
> 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/398ac163-8a7f-470b-8edb-df79014cd423n%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%2B4M1oNixHJ%3DqJ%2BduK1prGrDxO773q6cv8ZSM5ju3wqGG-KzZQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

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

['Eric Anderson' via grpc.io]

The v1.57.1 release 
is now available.
Bug fixes

   - Fix compatibility with Java 8. This fixes the NoSuchMethodError for
   ByteBuffer methods present in 1.57.0 (#10441
   )
   - xds: Remove debug assert in WeightedRoundRobinLoadBalancer. The assert
   was to detect breakages in the static stride algorithm causing too much
   looping. However, with multithreading it is possible to trigger even in
   legitimate scenarios (#10437
   )

-- 
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%2B4M1oPtr9Xxwn8T8hyapDLJoW%2BBuUvFSgxsAcx85ad41m6tiA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] using native java 11 alpn with gprc-java?

['Eric Anderson' via grpc.io]

TL;DR: you can use gRPC fine without native dependencies, but you might see
lesser performance.

OpenJDK backported the "Java 9 ALPN API" to Java 8, so you don't need
netty-tcnative at all for ALPN. We still use it because it provides a large
performance impact on Java 8, and it may provide some extra performance on
Java 11. AES GCM was previously pretty poorly optimized. But if you are
running somewhere netty-tcnative isn't supported, things are okay
especially on Java 11+.

The other part of netty-tcnative is "are you using a good/secure TLS
stack?" Earlier in gRPC's life Java was obviously pretty far behind the
wider TLS ecosystem. Boringssl was simply a good idea, independent of
performance. That seems to have changed though, and IIRC a surprising
amount of stuff has even gotten backported to Java 8 (vs what happened with
Java 7).

So we would probably look into dropping netty-tcnative from
grpc-netty-shaded after we drop Java 8.

Beyond netty-tcnative, there's netty-native-epoll/kqueue. These provide
performance via things like edge-triggered epoll, and helpful things like
TCP_USER_TIMEOUT (which could be argued is for performance). gRPC works
without them, but they do provide benefits even on Java 21. We're using
them for unix domain sockets today, as well; we've not played with the Java
16 API yet.

On Tue, Jul 11, 2023 at 2:32 AM Elhanan Maayan  wrote:

> hi.. i saw that java 9 + includes native alpn support, does this mean we
> no longer need to use outside native depedncies like boringSSL or
> conscrypt?
> i could never figure that out properly
>
> --
> 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/d22918a5-bcbc-4220-bb44-d942a45f2908n%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%2B4M1oNFiXzmWeydOsEzbPFzDHskZXnzMxcLXfStLsY7Q_F7yg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] Re: GRPC Server Reflection

['Eric Anderson' via grpc.io]

What language are you using? Why would the gRPC server reflection have any 
dependency injection?

On Saturday, July 1, 2023 at 9:43:05 AM UTC-7 chand...@codeprism.in wrote:

> What could be causing the issue where dependency injection is not properly 
> initializing when invoking rpc call using the gRPC server reflection 
> endpoint, while it works fine with the regular gRPC port service?
>

-- 
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/36c61486-a44d-4f70-9cbc-7b0f05b958den%40googlegroups.com.

Re: [grpc-io] Client-Side xDS Not Handling Removed Endpoints

['Eric Anderson' via grpc.io]

There's a 15 minute timer for localities. See gRFC A56 Priority LB Policy
.
Which localities are provided by control planes can be unstable, so old
localities are preserved for a while in case the control plane changes its
mind.

On Thu, May 18, 2023 at 6:52 AM Lawrence Finn  wrote:

> Hi all.
>
> I've been playing with xDS client side and noticed an odd occurrence
> handling a massive scale-down on the server side.  If an entire locality of
> an endpoint disappears, the gRPC client does not remove any of the hosts
> from the lb.  I've seen issues on both the golang client and java client.
> For example, if us-east-1c disappears, the client side keeps trying to
> connect to it.
> 2023/05/17 23:56:24 INFO: [xds] [xds-client 0xc00083cdc0] ADS response
> received: {
>   "versionInfo": "2023-05-17T22:41:11Z/3164",
>   "resources": [
> {
>   "@type": "
> type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignment",
>   "clusterName": "outbound|6565||myservice.svc.cluster.local",
>   "endpoints": [
> {
>   "locality": {
> "region": "us-east-1",
> "zone": "us-east-1c"
>   }
>
> Then I remove 1a
> 2023/05/17 23:58:32 INFO: Resource with name:
> outbound|6565||myservice.svc.cluster.local, type:
> *endpointv3.ClusterLoadAssignment, contains: {
>   "clusterName": "outbound|6565||myservice.svc.cluster.local",
>   "endpoints": [
> {
>   "locality": {
> "region": "us-east-1",
> "zone": "us-east-1a"
>   },
>
> I then see a lot of
>
> 2023/05/18 00:01:43 INFO: [xds] [weighted-target-lb 0xc000eac660] Balancer
> state update from locality {"region":"us-east-1","zone":"us-east-1c"}, new
> state: {ConnectivityState:TRANSIENT_FAILURE Picker:0xc0005439c0}
> 2023/05/18 00:01:44 WARNING: [core] [Channel #1 SubChannel #12] grpc:
> addrConn.createTransport failed to connect to {
>   "Addr": "IP_HERE:6565",
>   "ServerName": "myservice.svc.cluster.local:6565",
>   "Attributes": {},
>   "BalancerAttributes": {},
>   "Type": 0,
>   "Metadata": null
> }. Err: connection error: desc = "transport: error while dialing: dial tcp
> IP_HERE:6565: i/o timeout"
> 2023/05/18 00:01:44 INFO: [core] [Channel #1 SubChannel #12] Subchannel
> Connectivity change to TRANSIENT_FAILURE
> 2023/05/18 00:01:44 INFO: [balancer] base.baseBalancer: handle SubConn
> state change: 0xc0007d0020, TRANSIENT_FAILURE
> 2023/05/18 00:01:44 INFO: [xds] [weighted-target-lb 0xc000eac660] Balancer
> state update from locality {"region":"us-east-1","zone":"us-east-1c"}, new
> state: {ConnectivityState:TRANSIENT_FAILURE Picker:0xc00076efc0}
>
> --
> 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/975fb1ba-66e8-4a7e-86d5-956d071097c2n%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%2B4M1oOxNgt9yOq6gv7NJUsR4stgCKu%3D4FmtsC_7wrYNJkP7vQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] gRPC client side request throttling

['Eric Anderson' via grpc.io]

This has been responded to at https://github.com/grpc/grpc-java/issues/10164

On Thu, May 11, 2023 at 8:05 AM Bhuvi Viji  wrote:

> Hi,
>
> Currently  we are doing some performance testing with our gRPC based
> server and client apps and below are the Observations with the test results
> and Need feedback on this.
>
> 1.Even if the upstream gRPC service is up and running, client gets
> "Unreachable error" at times - what is the exact reason. We have configured
> retries to resolve the issue. But would like to understand what is
> happening behind it.
>
> 2. We configured have configured semaphore object to throttle request in
> client side even with Semaphore count of 10 , still seeing retries, its
> same as without having the semaphore object so would like to know the
> client side connection queueing feature where we can limit the connections
> on the channel instead of using a separate variables.
>
> --
> 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/b3108a0b-85ff-4db0-8624-305622143d33n%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%2B4M1oPzcH7asg%2BkNrx6OCz26zXcuVV3fOVAQcKUDPfZ%3DThLGg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRPC Java v1.55.1 Released

['Eric Anderson' via grpc.io]

The v1.55.1 release 
is now available.

The 1.55.0 release failed. There were no artifacts published for it.
API Changes

   - services: Rename MetricRecorder.setQps/clearQps to setQpsMetric/
   clearQpsMetric (#10031 )

Behavior Changes

   - gcp-observability: Remove monitored resource detection for logging (
   #10020 ). The cloud
   libraries will fill in these details instead
   - protoc-gen-grpc-java: binaries for Linux ARM and PPC are now built
   using Ubuntu 18.04. They will no longer work on Ubuntu 16.04 and Debian 9

New Features

   - api: Stabilize the frequently used compression APIs (#9942
   ):
   CallOptions.withCompression, CallOptions.getCompressor,
   AbstractStub.withCompression, ServerCall.setCompression,
   ServerCall.setMessageCompression
   - api: Stabilize Detachable and HasByteBuffer
   - gcp-observability: Stabilize GcpObservability (#10024
   ). The GcpObservability
   API provides a simple way to export logging, tracing, and metrics to Google
   Cloud Operations. See the Google Cloud blog post
   

   .
   - census: Add new tracer annotation to indicate the time when name
   resolution completed for those RPCs that experienced name resolution delay,
   or the time when picking subchannel completed for those RPCs that
   experienced picking subchannel delay. (#10014
   , #10044
   )
   - protoc-gen-grpc-java: binary for s390x is now published (#9455
   ). The glibc version used
   is available in Ubuntu 20.04, Debian 11, and CentOS 9 and later
   - authz: Added FileWatcherAuthorizationServerInterceptor (#9775
   )
   - services: Added
   OrcaMetricReportingServerInterceptor.create(MetricRecorder) which adds
   common metrics per-RPC (#9902
   )
   - android: Add UdsChannelBuilder for using LocalSocket an Android (#8418
   )
   - alts: Observe the GRPC_ALTS_MAX_CONCURRENT_HANDSHAKES environment
   variable user to adjust the max number of concurrent ALTS handshakes (
   #10016 )
   - binder: Expose client identity via PeerUid and PeerUids (#9952
   )
   - binder: Add BindServiceFlags.setAllowActivityStarts() for
   BIND_ALLOW_ACTIVITY_STARTS added in Android U (#10008
   )

Bug Fixes

   - core: Fix NPE race during hedging (#10007
   ), fixing a Netty buffer
   memory leak for cancelled RPCs
   - core: Allow transparent retries after a retry attempt and the
   configured max retries was 1 (#10066
   )
   - okhttp: properly implement OkHttpServerBuilder.maxConnectionAgeGrace()
(#9968 )
   - xds: Enable federation support. See gRFC A47
   
   - xds: Enable Weighted Round Robin LB policy support. See gRFC A58
   

   - xds: Avoid ClassCastException if the control plane changes the
   top-level policy (#10091 ).
   This is expected to be unlikely, but is possible
   - xds: Fix java.util.NoSuchElementException:
   SecurityProtocolNegotiators$ClientSdsHandler#0 (#10118
   ). This error did not
   cause any problems, other than unnecessary logging
   - xds: Avoid using the default locale for case insensitive path matching
   (#10148 )
   - googleapis: Enable ignore_resource_deletion for google-c2p: resolver’s
   default xds bootstrap (#10121
   )
   - rls: Refresh name resolution on rejected addresses (#10032
   )

New Examples

   - Keepalive (#9956 )
   - Cancellation (#9962 )
   - Deadline (#9958 )
   - Using waitForReady (#9960 
   )
   - Client and Server sharing (#9969
   )
   - Reflection (#9955 )
   - Doing debug (#9957 

Re: [grpc-io] gRPC message validation question

['Eric Anderson' via grpc.io]

On Thu, May 4, 2023 at 7:29 AM Brad Post  wrote:

> Okay thanks, but then what is the recommended way of "defending" bad
> requests.
>

Ignore this case and just validate requests like you normally would if it
were the proper type.

You can use this as a reminder that if you persist client-created messages
in a DB, you very well may want to strip unknown fields. But that is not
specific to this case.

I can pass this to my function above because the *street* field is aligned
> with the *GetAddressInfoRequest* but there is no validation from the rpc
> call that it was called with the correct message.
>

"can". It should be exceedingly rare to happen by accident. The most likely
case of it happening by accident (other than you changed your schema in an
incompatible way) is if you and another team at your company chose the same
service name and method name in the same package. And if you did that,
because of naming conventions, you probably would have both chosen the same
request/response names!

If you are concerned about attacks, then you couldn't trust the type sent
by the client anyway.

As both messages have *required* fields I could check the size of the
> message against what's expected, but that doesn't help me when fields are
> *optional.*
>

Then you will already have validation that the two fields are present, and
maybe things like zip code follows an expected format. Do those
validations. "Wrong message" is really just "invalid message of the right
type."

Note that this line of thinking applies equally to messages that are fields
in other messages. Protobuf does not include the types of child messages.
Neither does JSON.

-- 
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%2B4M1oNqGXjKHeBuUZfCiP_m9601T%3DsP5zp2RkXfHCiYMXTbDQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] gRPC message validation question

['Eric Anderson' via grpc.io]

No, there is no validation. The type arguments are implicit given the
method, and there's no communication that would tell you that there is a
mis-match. The only time you'd need such a thing is if you change the
request/response message in the proto, so "don't do that." Instead, create
a new function with the new signature that you want.

On Mon, May 1, 2023 at 7:30 AM Brad Post  wrote:

> Is there a built in validator to ensure that the message passed to a
> method is the correct one?
>
> For example:
>
> *message GetAddressInfoRequest {*
> *string street = 1;*
> *string zip = 2;*
> *};*
>
>
> *rpc get_address_info(GetAddressInfoRequest) returns (GetAddressResult);*
>
> I would like the function (get_address_info) to throw an exception/error
> if the signature for the incoming message doesn't match the
> *GetAddressInfoRequest* signature.
>
> Thanks.
>
> Brad
>
> --
> 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/92d1edcd-6ef4-4a98-a415-34d2256a72d1n%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%2B4M1oPUf64%3DSvFO3zHRSdA2MqyZvFf%2BHJd1N9ydgTP-AGxC-Q%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] how to make a grpc call using http2

['Eric Anderson' via grpc.io]

I took a look at this with Java server, and it actually works without
issue. So, yeah, I think any issue you experienced was the server trying to
decode the JSON message as a protobuf.

To test this with Java, you can use the HelloJsonServer. Add
createStartScripts('io.grpc.examples.advanced.HelloJsonServer') to
examples/build.gradle, ./gradlew installDist, then
run ./build/install/examples/bin/hello-json-server . I see a nice {
"message": "Hello niko" } reply.

If you run ./build/install/examples/bin/hello-world-server as the server
instead, then you get an error 2 (UNKNOWN) because of the decoding
exception you can see in the logs on server-side.

The +proto vs +json isn't entirely a thing. It was in the wire format but
completely unused, until grpc-go added it *thinking* the other languages
supported it. The only thing most languages do is strip off anything after
the +.

On Tue, Apr 18, 2023 at 11:41 AM Nikos Skalis 
wrote:

> I just noticed (see above the verbose output from curl) the grpc server
> replies with content-type *application/grpc* instead of
> *application/grpc+json* like the client requested, is that expected? is
> this why the deserialisation fails?
>
> On Tuesday, April 18, 2023 at 4:07:52 PM UTC+2 Nikos Skalis wrote:
>
>> Thank you for looking at it, but what do you mean exactly? How would you
>> write the below differently?
>>
>> # json_data = '{"name": "niko"}'
>> # compressed_flag = 00
>> # message_length = 0010
>> # message_binary = 7b226e616d65223a20226e696b6f227d
>> echo -n '107b226e616d65223a20226e696b6f227d' | xxd -r -p -
>> frame.bin
>>
>>
>> On Tuesday, April 18, 2023 at 4:03:03 PM UTC+2 Craig Tiller wrote:
>>
>> Looks like you've got the http headers in place but are missing the five
>> byte message header from grpc in your data stream
>>
>> On Tue, Apr 18, 2023, 6:48 AM Nikos Skalis  wrote:
>>
>> Hi,
>>
>> I am trying to make a gRPC call based on a HTTP2 client to work like it
>> is described here: 
>> *https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md
>> *
>>
>> I am using an official example of a gRPC server: 
>> *https://grpc.io/docs/languages/python/quickstart/
>> *
>>
>> Based on *grpcurl*:
>>
>>
>> *% grpcurl -import-path ../../protos -proto helloworld.proto -plaintext
>> -d '{"name": "niko"}' -H 'Content-Type: application/grpc+json'
>> localhost:50051 helloworld.Greeter/SayHello*{
>>   "message": "Hello, niko!"
>> }
>>
>> Based on *nghttp*:
>>
>> # json_data = '{"name": "niko"}'
>> # compressed_flag = 00
>> # message_length = 0010
>> # message_binary = 7b226e616d65223a20226e696b6f227d
>> echo -n '107b226e616d65223a20226e696b6f227d' | xxd -r -p -
>> frame.bin
>>
>>
>> *% nghttp  -H ":method: POST" -H "Content-Type: application/grpc+json" -H
>> "TE: trailers" --data=frame.bin
>> http://localhost:50051/helloworld.Greeter/SayHello
>>  --verbose*
>> [  0.004] Connected
>> [  0.004] recv SETTINGS frame 
>>   (niv=4)
>>   [SETTINGS_INITIAL_WINDOW_SIZE(0x04):4194304]
>>   [SETTINGS_MAX_FRAME_SIZE(0x05):4194304]
>>   [SETTINGS_MAX_HEADER_LIST_SIZE(0x06):8192]
>>   [UNKNOWN(0xfe03):1]
>> [  0.004] recv WINDOW_UPDATE frame 
>>   (window_size_increment=4128769)
>> [  0.004] send SETTINGS frame 
>>   (niv=2)
>>   [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100]
>>   [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535]
>> [  0.004] send SETTINGS frame 
>>   ; ACK
>>   (niv=0)
>> [  0.004] send PRIORITY frame 
>>   (dep_stream_id=0, weight=201, exclusive=0)
>> [  0.004] send PRIORITY frame 
>>   (dep_stream_id=0, weight=101, exclusive=0)
>> [  0.004] send PRIORITY frame 
>>   (dep_stream_id=0, weight=1, exclusive=0)
>> [  0.004] send PRIORITY frame 
>>   (dep_stream_id=7, weight=1, exclusive=0)
>> [  0.004] send PRIORITY frame 
>>   (dep_stream_id=3, weight=1, exclusive=0)
>> [  0.004] send HEADERS frame 
>>   ; END_HEADERS | PRIORITY
>>   (padlen=0, dep_stream_id=11, weight=16, exclusive=0)
>>   ; Open new stream
>>   :method: POST
>>   :path: /helloworld.Greeter/SayHello
>>   :scheme: http
>>   :authority: localhost:50051
>>   accept: */*
>>   accept-encoding: gzip, deflate
>>   user-agent: nghttp2/1.52.0
>>   content-length: 21
>>   content-type: application/grpc+json
>>   te: trailers
>> [  0.004] send DATA frame 
>>   ; END_STREAM
>> [  0.005] recv SETTINGS frame 
>>   ; ACK
>>   (niv=0)
>> [  0.005] recv WINDOW_UPDATE frame 
>>   (window_size_increment=21)
>> [  0.005] recv PING frame 
>>   (opaque_data=)
>> [  0.005] send PING frame 
>>   ; ACK
>>   (opaque_data=)
>> [  

[grpc-io] gRPC-Java 1.50.3 Released

['Eric Anderson' via grpc.io]

The v1.50.3 release 
is now available.

Bug Fixes

   - core: Free unused MessageProducer in RetriableStream (#9853
   ), fixing a Netty buffer
   memory leak for cancelled RPCs

-- 
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%2B4M1oNXRqhu8xcPQPrAVwjmdCyLgGEWvJBDBtxYdahv-mcZxg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] io.grpc.internal.ManagedChannelImpl$NameResolverListener handleErrorInSyncContext

['Eric Anderson' via grpc.io]

> java.net.UnknownHostException: Host sconosciuto (voloOK)

The host name does not exist. Check the spelling, search path, or which DNS
server your machine is configured to use. You can use `ping` to check if
DNS resolution is working as you expect.

On Wed, Mar 22, 2023 at 7:41 AM VALENTINA FERRO 
wrote:

> Hi,
> I have this problem
> io.grpc.internal.ManagedChannelImpl$NameResolverListener
> handleErrorInSyncContext:
>
> mar 22, 2023 3:27:48 PM
> io.grpc.internal.ManagedChannelImpl$NameResolverListener
> handleErrorInSyncContext
> WARNING: [Channel<1>: (voloOK:50051)] Failed to resolve name.
> status=Status{code=UNAVAILABLE, description=Unable to resolve host voloOK,
> cause=java.lang.RuntimeException: java.net.UnknownHostException: Host
> sconosciuto (voloOK)
> at
> io.grpc.internal.DnsNameResolver.resolveAddresses(DnsNameResolver.java:223)
> at io.grpc.internal.DnsNameResolver.doResolve(DnsNameResolver.java:282)
> at io.grpc.internal.DnsNameResolver$Resolve.run(DnsNameResolver.java:318)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.net.UnknownHostException: Host sconosciuto (voloOK)
> at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at
> java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:52)
> at
> java.base/java.net.InetAddress$PlatformResolver.lookupByName(InetAddress.java:1048)
> at
> java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1648)
> at
> java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:997)
> at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1638)
> at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1504)
> at
> io.grpc.internal.DnsNameResolver$JdkAddressResolver.resolveAddress(DnsNameResolver.java:631)
> at
> io.grpc.internal.DnsNameResolver.resolveAddresses(DnsNameResolver.java:219)
> ... 5 more
> }
> Exception in thread "AWT-EventQueue-0" io.grpc.StatusRuntimeException:
> UNAVAILABLE: Unable to resolve host voloOK
> at io.grpc.Status.asRuntimeException(Status.java:539)
> at
> io.grpc.stub.ClientCalls$BlockingResponseStream.hasNext(ClientCalls.java:662)
> at clientGrpc.Client.promozioni(Client.java:245)
> at
> observer_mediator.observer.Controller_Director.notificaWidget(Controller_Director.java:331)
> at
> observer_mediator.mediator.ConcreteWidgetClass.notifica(ConcreteWidgetClass.java:28)
> at
> observer_mediator.mediator.ConcreteWidgetClass$2.mouseClicked(ConcreteWidgetClass.java:56)
> at java.desktop/java.awt.Component.processMouseEvent(Component.java:6619)
> at
> java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3398)
> at java.desktop/java.awt.Component.processEvent(Component.java:6381)
> at java.desktop/java.awt.Container.processEvent(Container.java:2266)
> at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4991)
> at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2324)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4823)
> at
> java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4948)
> at
> java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4584)
> at
> java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4516)
> at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2310)
> at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2780)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4823)
> at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:775)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
> at
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
> at
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:97)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:747)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
> at
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
> at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:744)
> at
> java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
> at
> java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
> at
> java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
> at
> 

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

['Eric Anderson' via grpc.io]

gRPC's security model is generally the same as in HTTP. A streaming RPC is
simply one HTTP exchange, where the HTTP request and HTTP response can
overlap in time. Since you've used HTTP for a while, I'll note that gRPC
does not support OAuth HMACs nor "authenticate on first request" like NTLM.


> 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?
>

If you are using TLS, then it provides that guarantee. If you are using
insecure channel credentials, then you'd only be trusting your datacenter
network.

On Mon, Mar 20, 2023 at 7:03 AM Eric Robins  wrote:

> This is why web-based applications have session tokens/cookies, web
> services always authenticate or use tokens like JWTs, etc, where those
> credentials are protected cryptographically via TLS or other
> encryption/signing schemes.


Right, there's the two parts: bearer tokens and TLS. That same model can be
applied to gRPC. The commonly chosen security options for gRPC are 1)
OAuth/JWT with TLS and 2) mTLS.

The channel (stateful connection in this case - not to be confused with a
> gRPC channel) alone is only considered adequate if it *binds* the client
> to the server, which can be achieved via TLS but only if the server
> associates the TLS session with the client. Many web servers don't do this.


gRPC does not support this. It interacts poorly with load balancing. In
gRPC, if you want to authenticate only once per connection, use mTLS.

I'll note that a bearer token sent each RPC generally isn't a performance
concern in gRPC. HTTP/2 can avoid resending the full token value in each
request (via compression) and if the server has a cache, then there would
be little per-RPC overhead.

-- 
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%2B4M1oP49M9WqLBokLFN9a1eDVk_BhxHtWe3-vRejO%3D0MKEqhQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] grpc vs rest benchmark

['Eric Anderson' via grpc.io]

I hate to sound like a broken record, but without the code, there's little
I can do. I don't know what you are benchmarking, so I can't explain the
results.

I'm glad to hear that using a fixed thread pool helped, although I don't
know what the previous code was doing (whether you were using the default
or had a different executor). I will say that 100 threads is probably
excessive. A good starting point for non-blocking services is ½-2 times the
number of cores, depending on what else is going on. In your case, you're
sharing the single machine between client and server which makes it all the
harder to tune. I suggest running the client and server on different
machines.

I'm not familiar with how the jmeter or the grpc plugin handle channels. If
it is using a single channel, then you will be limited to approximately a
core of throughput. For load tests, you generally would use multiple
channels to increase the number of connections. Sometimes that is needed in
practice in real clients, but more often each server has many clients and
each client has a separate channel/connection so clients don't need to use
multiple.

For reference, do look at our public benchmark dashboard
. "Unary secure throughput
QPS (8 core client to 8 core server)" may be similar to what you are trying
to do here, and it gets 171 Kqps. See
https://grpc.io/docs/guides/benchmarking/ for a description of what the
tests are doing to put the numbers in perspective.

On Sun, Feb 26, 2023 at 11:52 PM shobhit agarwal 
wrote:

> Hi Eric,
>
> After adding threadpool size to 100, now I am getting throughput 1.6k
> req/sec,but same with rest (Get method) it's 2.7k req/sec.
>
> my client is jmeter and client and server is on same machine.
>
>  Do I need to set channelType also for better performance.
>
> Below is my code:
>
> @Bean
>
> GrpcServerConfigurer grpcServerConfigurer() {
>
> return builder -> {
>
> ((NettyServerBuilder) builder)
>
> .executor(Executors.newFixedThreadPool(100));
>
> };
>
> }
>
>
> @GrpcService
>
> public class MyGrpcService extends SquareRpcGrpc.SquareRpcImplBase {
>
> @Override
>
> public void findSquareUnary(Input request, StreamObserver
> responseObserver) {
>
> int number = request.getNumber();
>
> responseObserver.onNext(
>
> Output.newBuilder().setNumber(number).setResult(number * number).build()
>
> );
>
> responseObserver.onCompleted();
>
> }
>
>
> On Thursday, 23 February 2023 at 23:05:41 UTC+5:30 Eric Anderson wrote:
>
>> Oops. Failed to cc the mailing list.
>>
>> There was a reply to this saying the JVM was warm. I maintained that
>> without the actual benchmark code it is hard to diagnose.
>>
>> -- Forwarded message -
>> From: Eric Anderson 
>> Date: Tue, Feb 21, 2023 at 9:08 AM
>> Subject: Re: [grpc-io] grpc vs rest benchmark
>> To: shobhit agarwal 
>>
>>
>> 100 ms is much too high. You have probably not warmed up the JVM. See
>> https://stackoverflow.com/a/47662646/4690866
>>
>> Without a reproducible benchmark and information on where you're running
>> it, this isn't very interesting/relevant. It's just far too easy to make a
>> useless benchmark and 200 qps is too far from expected numbers without an
>> easy reproduction and machine details. "Running on Windows" is an important
>> detail, but it's nowhere near enough information to understand what the
>> results mean.
>>
>> (Benchmarks are perfect measurements, but it is hard to figure out what
>> they are measuring.)
>>
>> On Thu, Feb 16, 2023 at 6:02 AM shobhit agarwal 
>> wrote:
>>
>>> Thanks for replying,
>>> I am using the code from below article:
>>>
>>> https://www.techgeeknext.com/spring-boot/spring-boot-grpc-example#google_vignette
>>>
>>> It's spring boot application.
>>> Even for single request grpc is response time is 100 ms and REST is
>>> taking 12 ms only.
>>>
>> --
> 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/1cc1f02b-722d-4b4e-babe-443da624632an%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%2B4M1oNaXe6RtQ3ZQQ1NV%2BY2UA%3DtcaysmTG6iYcU9WNnUj1yag%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Routing a grpc server to a url without port with Apache

['Eric Anderson' via grpc.io]

Right, that's what I was discussing. You can't generally configure gRPC
clients to use a path prefix. I'd suggest routing by service name, but some
people route by Content-Type (which is technically wrong from an HTTP
perspective, but doesn't generally hurt much and is very easy).

On Fri, Feb 24, 2023 at 5:05 PM Adam Beer  wrote:

> All good! I understand the package.Service/Method structure but what Im
> trying to do is set the url portition before the service path. I dont want
> someone to have to use example.com:5051/package.Service/Method, I want
> example.com/rpc/package.Service/Method. Im hosting a REST and RPC api on
> the same server. REST has traffic routed to /api through the grpc-gateway
> service but I have no idea how to do this for grpc. Idealy id like to have
> both API's flow through the same url minus but I dont know if this is
> possible.
>
> On Thursday, 23 February 2023 at 11:27:34 UTC-5 Eric Anderson wrote:
>
>> (Sorry for the moderation delay here. The spam detection kicked in; false
>> positives are pretty rare so it isn't checked super regularly. I approved
>> just one of the duplicate emails.)
>>
>> The problem here is probably the "/rpc". gRPC doesn't use the /rpc
>> prefix. It uses /package.Service/Method, so you'd route based on which
>> services you want sent to the backend. gRPC implementations generally don't
>> support path prefixes, so you couldn't tell the client to prepend /rpc to
>> the path for the request.
>>
>> On Thu, Feb 23, 2023 at 8:21 AM Adam Beer  wrote:
>>
>>> I am trying to route my gRPC server to a url with a specific path on an
>>> Apache 2 server but am getting DNS resolving errors on my client when I try
>>> to connect. I would like to host my gRPC server behind example.com/rpc
>>> and my Apache config looks like this:
>>>
>>> Protocols h2 http/1.1
>>> ProxyPass /rpc h2://127.0.0.1:5051
>>> ProxyPassReverse /rpc https://127.0.0.1:5051
>>>
>>> Im using the grpc package on Node. My server is being bound to the 5051
>>> port with the following:
>>>
>>> server.bind("0.0.0.0:5051", grpc.ServerCredentials.createInsecure());
>>> server.start();
>>>
>>> --
>>> 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/0efe7a2f-5285-4b40-a6ef-e2f2a6a95ffdn%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/9b4e3f25-11a8-4f87-ac6b-9256e9e78644n%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%2B4M1oNeK406hc13sV6cM-7S_C5bxrdzNLb0dMvVbNRT0HuGKw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Fwd: [grpc-io] grpc vs rest benchmark

['Eric Anderson' via grpc.io]

Oops. Failed to cc the mailing list.

There was a reply to this saying the JVM was warm. I maintained that
without the actual benchmark code it is hard to diagnose.

-- Forwarded message -
From: Eric Anderson 
Date: Tue, Feb 21, 2023 at 9:08 AM
Subject: Re: [grpc-io] grpc vs rest benchmark
To: shobhit agarwal 


100 ms is much too high. You have probably not warmed up the JVM. See
https://stackoverflow.com/a/47662646/4690866

Without a reproducible benchmark and information on where you're running
it, this isn't very interesting/relevant. It's just far too easy to make a
useless benchmark and 200 qps is too far from expected numbers without an
easy reproduction and machine details. "Running on Windows" is an important
detail, but it's nowhere near enough information to understand what the
results mean.

(Benchmarks are perfect measurements, but it is hard to figure out what
they are measuring.)

On Thu, Feb 16, 2023 at 6:02 AM shobhit agarwal 
wrote:

> Thanks for replying,
> I am using the code from below article:
>
> https://www.techgeeknext.com/spring-boot/spring-boot-grpc-example#google_vignette
>
> It's spring boot application.
> Even for single request grpc is response time is 100 ms and REST is taking
> 12 ms only.
>

-- 
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%2B4M1oNZqXZAVFiC2fsJQ2N4Tov9SMb0ty6HqNb5CoDRbopQtQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Routing a grpc server to a url without port with Apache

['Eric Anderson' via grpc.io]

(Sorry for the moderation delay here. The spam detection kicked in; false
positives are pretty rare so it isn't checked super regularly. I approved
just one of the duplicate emails.)

The problem here is probably the "/rpc". gRPC doesn't use the /rpc prefix.
It uses /package.Service/Method, so you'd route based on which services you
want sent to the backend. gRPC implementations generally don't support path
prefixes, so you couldn't tell the client to prepend /rpc to the path for
the request.

On Thu, Feb 23, 2023 at 8:21 AM Adam Beer  wrote:

> I am trying to route my gRPC server to a url with a specific path on an
> Apache 2 server but am getting DNS resolving errors on my client when I try
> to connect. I would like to host my gRPC server behind example.com/rpc
> and my Apache config looks like this:
>
> Protocols h2 http/1.1
> ProxyPass /rpc h2://127.0.0.1:5051
> ProxyPassReverse /rpc https://127.0.0.1:5051
>
> Im using the grpc package on Node. My server is being bound to the 5051
> port with the following:
>
> server.bind("0.0.0.0:5051", grpc.ServerCredentials.createInsecure());
> server.start();
>
> --
> 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/0efe7a2f-5285-4b40-a6ef-e2f2a6a95ffdn%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%2B4M1oNgCpP1wrPfyLfy1CjMztDv6S3XKE7rTXQnbEkeP1E1fg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRPC-Java 1.45.3

['Eric Anderson' via grpc.io]

The v1.45.3 release 
is now available.

This release is unrelated to the recent xDS bug release fixes that impacted
1.51 and 1.52.

Bug Fixes

   - core: Fix retry causing memory leak for canceled RPCs. (#9360
   )

-- 
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%2B4M1oOiKVM8mt76AEAN5UZxk9kgw%3DLyrRE14gsK-67e0Vyo%3Dg%40mail.gmail.com.

[grpc-io] Re: grpc-java xDS regression in 1.51.0, 1.51.1, 1.52.0

['Eric Anderson' via grpc.io]

grpc-java 1.51.3 and 1.52.1 are released which have the fix for this issue.
If you use the latest patch release of any grpc minor version, then there
is no longer risk of being impacted (earlier versions were before the bug,
and later versions now have patch releases with the fix).

On Wed, Jan 11, 2023 at 3:07 PM Eric Anderson  wrote:

> We have discovered a regression in grpc-xds starting with 1.51.0 where
> resources might stop receiving updates. The trigger could happen hours or
> days after the binary had started. xDS users should avoid 1.51.0, 1.51.1,
> and 1.52.0. We suggest using 1.50.x until patch releases with the fix are
> available.
>
> The bug should generally not cause resources to be missing, but instead
> out-of-date. This most easily impacts EDS, which would cause backend IP
> addresses to become stale. But config changes in general might not be seen
> by grpc-xds.
>
> See https://github.com/grpc/grpc-java/pull/9809 to track the fix.
>

-- 
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%2B4M1oM264j9L3rG0ynZRPHxdjunzCTE4KiDA%3DGgaHD0c0NcNA%40mail.gmail.com.

[grpc-io] grpc-java xDS regression in 1.51.0, 1.51.1, 1.52.0

['Eric Anderson' via grpc.io]

We have discovered a regression in grpc-xds starting with 1.51.0 where
resources might stop receiving updates. The trigger could happen hours or
days after the binary had started. xDS users should avoid 1.51.0, 1.51.1,
and 1.52.0. We suggest using 1.50.x until patch releases with the fix are
available.

The bug should generally not cause resources to be missing, but instead
out-of-date. This most easily impacts EDS, which would cause backend IP
addresses to become stale. But config changes in general might not be seen
by grpc-xds.

See https://github.com/grpc/grpc-java/pull/9809 to track the fix.

-- 
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%2B4M1oOZZ-Q5uULHhMyY8Bk_dTcfhpXOKsB4RLLYzRsYybQ9rQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRPC-Java 1.50.0 released

['Eric Anderson' via grpc.io]

The v1.50.0 release 
in now available.

New Features

   - okhttp: Added connection management features to okhttp server,
   including maxConnectionIdle(), permitKeepAliveTime(), and
   permitKeepAliveWithoutCalls() (#9494
   , #9544
   )
   - binder: Add SecurityPolicies for checking device owner/profile owner (
   #9428 )

API Changes

   - api: Add LoadBalancer.acceptResolvedAddresses() (#9498
   ). The method is like
   handleResolvedAddresses() but returns a boolean of whether the addresses
   and configuration were accepted. Not accepting the update triggers the
   NameResolver to retry after a delay. We are not yet encouraging migration
   to this method, as there is still a second future API change
   - core: add CallOptions to CallCredentials.RequestInfo (#9538
   )

Bug Fixes

   - auth: Fix AppEngine failing while retrieving access token when
   instantiating a blocking stub using AppEngineCredentials (#9504
   )
   - core: Ensure that context cancellationCause is set (#9501
   )
   - core: Update outlier detection max ejection logic to allow exceeding
   the limit by one, to match Envoy. (#9489
   , #9492
   )
   - core: outlier detection to honor min host request volume (#9490
   )
   - xds: ringhash policy in TRANSIENT_FAILURE should not attempt
   connecting when already in connecting (#9535
   ). With workloads where
   most requests have the same hash, ring hash should behave more like
   pick-first of slowly trying backends

Dependencies

   - netty: upgrade netty from 4.1.77.Final to 4.1.79.Final and tcnative
   from 2.0.53 to 2.0.54 (#9451
   )

Acknowledgements

@cpovirk 
@prateek-0 
@sai-sunder-s 

-- 
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%2B4M1oP%2Bs33cwJY2p0oWMuXPmGgcaxVLpgsCT3Sn%3DzTzmDbGPg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRPC-Java 1.41.3 Released

['Eric Anderson' via grpc.io]

The v1.41.3 release 
is now available.

Dependencies

   - Bump protobuf to 3.19.6

-- 
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%2B4M1oNx9sbdqc-%2BEGGfSyCAYpE%2BwP4gmyZADcL9pcbXqnAsLQ%40mail.gmail.com.

[grpc-io] gRPC-Java 1.36.3 Released

['Eric Anderson' via grpc.io]

The v1.36.3 release 
is now available.

Dependencies

   - Bump protobuf to 3.16.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/CA%2B4M1oM849Ge9UAMR10OH8W2bXSgneVhGYuZqov7tXbStS7%3DFw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] Protobuf Java DoS CVE-2022-3171

['Eric Anderson' via grpc.io]

Protobuf versions prior to 3.21.7 suffer from CVE-2022-3171
.
Notably, the fix requires regenerating code, so make sure your protoc
version is upgraded and you verify important dependencies have rebuilt
their generated code. See their advisory for the fixed versions of protobuf.

gRPC 1.48.2 and 1.49.2 regenerate protobuf code that gRPC publishes, like
those in grpc-services. You are encouraged to upgrade. Patch releases for
1.36 and 1.41-1.47 are upcoming.

-- 
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%2B4M1oP94RmYSoVi_kajDHwAzwaEMPchBJBdnf1aCdCtZRBjSw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] breaking functionality with netty-handler upgrade | 5.0.0.Alpha2

['Eric Anderson' via grpc.io]

On Tue, Aug 30, 2022 at 12:28 AM vivek Baranwal 
wrote:

> I have upgraded netty-handler jar version recently from 4.1.77.Final
> to 5.0.0.Alpha2 but looks like my GRPC call is getting failed in between
> because of this upgrade.
>

You can't upgrade gRPC to Netty 5. The netty namespace is different.
There's also lots of things we know would need to be fixed. The only way
you could have done so is if you used the very-old-and-dead Netty 5 from
2015.

Dead and useless. Was replaced with Netty 4.1:
io.netty:netty-codec:5.0.0.Alpha2

New and interesting, but you should use alpha 4:
io.netty:netty*5*-codec:5.0.0.Alpha2

tried to access method io.netty.handler.logging.LogLevel.toInternalLevel


See the "io.netty" package? That is the dead Netty 5 from 2015. The new
Netty 5 has "io.netty5" package.

-- 
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%2B4M1oNVjpYdgFtt-Lc9DfsSQ%2BX7Aiuh_Ap6T9XNRDmzRViVrA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] extracting master-key for wireshark using JsseProvider

['Eric Anderson' via grpc.io]

On Mon, Aug 29, 2022 at 9:39 AM Eric Anderson  wrote:

> You can use `-Dio.netty.transport.noNative=true` or
> `-Dio.grpc.netty.shaded.io.netty.transport.noNative=true` to disable
> loading tcnative, depending on whether you are using grpc-netty or
> grpc-netty-shaded, respectively.
>

Oops. That's for Epoll/Kqueue transports. For tcnative you need
`-Dio.netty.handler.ssl.noOpenSsl=true` or
`-Dio.grpc.netty.shaded.io.netty.handler.ssl.noOpenSsl=true`.

-- 
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%2B4M1oNDJ2cmp33i7xfMTzAFbHf4neLW-picFFkfBs1QcYo0gg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] extracting master-key for wireshark using JsseProvider

['Eric Anderson' via grpc.io]

On Fri, Aug 26, 2022 at 6:00 AM Elhanan Maayan  wrote:

> if i understand correctly if i wish to extract the master key for
> wireshark sniffing
> i need to use this:
> GrpcSslContexts.configure(sslContextBuilder, Security.getProvider
> ("SunJSSE"));
>

FYI, there was a PR  to
support master key logging for other providers, but it was reverted
.

are there any major differences between using the default provider  vs
> using SunJSSE?
> performance? security ?
> is there a way to configure the provider externally via system property?
>

The default provider isn't a java.security.Provider. The default is a
SslProvider enum value (a configure() overload
)
of OPENSSL
.
It uses netty-tcnative which can use openssl, boringssl, and libressl. The
build we recommend is boringssl-based (and this is included in
grpc-netty-shaded). So the implementation is quite different. However, for
users on Java 11+, using SunJSSE should be fine. SunJSSE was unusable in
Java 7 and had poor AES GCM performance in Java 8. I suspect Java 11
performance is close enough that many users wouldn't notice a difference.

You can use `-Dio.netty.transport.noNative=true` or
`-Dio.grpc.netty.shaded.io.netty.transport.noNative=true` to disable
loading tcnative, depending on whether you are using grpc-netty or
grpc-netty-shaded, respectively.

-- 
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%2B4M1oMLdwMdSJfiK%2BKMEagPnnGuPGeELvA9_ZJT0STdr6m4QQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Help understand DNS resolution between client and Nginx Ingress

['Eric Anderson' via grpc.io]

On Sun, Aug 21, 2022 at 10:32 AM Staniel Yao  wrote:

> I think it's because the MAX_CONNECTION_AGE is only affecting the
> connection between Nginx and backend and doesn't affect the client
> connection to Nginx itself. Am I right on this?
>

Correct. The necessary configuration would be in nginx.

I also try to tune some Nginx config map value such as keep-alive
> 
> but it's also not helping.
>

I'd expect keep-alive or keep-alive-requests to help. Maybe you are using
an older version of nginx before they got rid of the http2-specific
configuration?

So in summary, I would like to get some suggestion to understand:
> 1: Why my client switch DNS every other *83* mins? It seems a weird magic
> number as I can not find anything related.
>

I have to imagine that is related to nginx cycling the connection after 10k
requests. Multiply 83 minutes by an estimated queries per minute and maybe
it will make more sense.

-- 
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%2B4M1oMs-6R2_%2BZNwxe7PfxnLu8W5kLjLyi6YJTk6N3p8bJf1w%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Cache response in ServerInterceptor

['Eric Anderson' via grpc.io]

>
> at
> com.alibaba.csp.sentinel.adapter.grpc.SentinelGrpcServerInterceptor$1.close(SentinelGrpcServerInterceptor.java:77)
> ~[sentinel-grpc-adapter-1.7.1.jar:?]
> at
> com.opay.ccp.proxy.interceptor.IdempotentInterceptors.interceptCall(IdempotentInterceptors.java:71)
> ~[classes/:?]
>

That seems likely to be the "call.close(Status.OK,new Metadata());" line.
Since the interceptors are running in interceptCall, that means gRPC hasn't
seen any exception at this point yet.

Based on the stacktrace, I suggest you to look through
SentinelGrpcServerInterceptor, MetricCollectingServerInterceptor, and
GrpcRequestScope for bugs that would call close() twice.

On Tue, Jul 26, 2022 at 12:41 AM jinxiang lang 
wrote:

> Yeah, of course ，The client's response is like this:
>
> {
>   "error": "2 UNKNOWN: "
> }
>
>
> complete stack trace information ：
>
> 2022-07-26 15:31:51.470 ERROR -
> io.grpc.internal.SerializingExecutor.run[SerializingExecutor.java:136]--
> Exception while executing runnable
> io.grpc.internal.ServerImpl$ServerTransportListenerImpl$1HandleServerCall@6d61cdda
> java.lang.IllegalStateException: java.lang.IllegalStateException: call
> already closed
> at
> io.grpc.internal.ServerImpl$ServerTransportListenerImpl$1HandleServerCall.runInternal(ServerImpl.java:619)
> ~[grpc-core-1.48.0.jar:1.48.0]
> at
> io.grpc.internal.ServerImpl$ServerTransportListenerImpl$1HandleServerCall.runInContext(ServerImpl.java:603)
> ~[grpc-core-1.48.0.jar:1.48.0]
> at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
> ~[grpc-core-1.48.0.jar:1.48.0]
> at
> io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:133)
> [grpc-core-1.48.0.jar:1.48.0]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_231]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_231]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_231]
> Caused by: java.lang.IllegalStateException: call already closed
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:507)
> ~[guava-26.0-jre.jar:?]
> at
> io.grpc.internal.ServerCallImpl.closeInternal(ServerCallImpl.java:218)
> ~[grpc-core-1.48.0.jar:1.48.0]
> at io.grpc.internal.ServerCallImpl.close(ServerCallImpl.java:211)
> ~[grpc-core-1.48.0.jar:1.48.0]
> at
> io.grpc.PartialForwardingServerCall.close(PartialForwardingServerCall.java:48)
> ~[grpc-api-1.48.0.jar:1.48.0]
> at io.grpc.ForwardingServerCall.close(ForwardingServerCall.java:22)
> ~[grpc-api-1.48.0.jar:1.48.0]
> at
> io.grpc.ForwardingServerCall$SimpleForwardingServerCall.close(ForwardingServerCall.java:39)
> ~[grpc-api-1.48.0.jar:1.48.0]
> at
> net.devh.boot.grpc.server.metric.MetricCollectingServerCall.close(MetricCollectingServerCall.java:60)
> ~[grpc-server-spring-boot-autoconfigure-2.13.1.RELEASE.jar:2.13.1.RELEASE]
> at
> io.grpc.PartialForwardingServerCall.close(PartialForwardingServerCall.java:48)
> ~[grpc-api-1.48.0.jar:1.48.0]
> at io.grpc.ForwardingServerCall.close(ForwardingServerCall.java:22)
> ~[grpc-api-1.48.0.jar:1.48.0]
> at
> io.grpc.ForwardingServerCall$SimpleForwardingServerCall.close(ForwardingServerCall.java:39)
> ~[grpc-api-1.48.0.jar:1.48.0]
> at
> com.alibaba.csp.sentinel.adapter.grpc.SentinelGrpcServerInterceptor$1.close(SentinelGrpcServerInterceptor.java:77)
> ~[sentinel-grpc-adapter-1.7.1.jar:?]
> at
> com.opay.ccp.proxy.interceptor.IdempotentInterceptors.interceptCall(IdempotentInterceptors.java:71)
> ~[classes/:?]
> at
> io.grpc.ServerInterceptors$InterceptCallHandler.startCall(ServerInterceptors.java:244)
> ~[grpc-api-1.48.0.jar:1.48.0]
> at
> com.alibaba.csp.sentinel.adapter.grpc.SentinelGrpcServerInterceptor.interceptCall(SentinelGrpcServerInterceptor.java:64)
> ~[sentinel-grpc-adapter-1.7.1.jar:?]
> at
> io.grpc.ServerInterceptors$InterceptCallHandler.startCall(ServerInterceptors.java:244)
> ~[grpc-api-1.48.0.jar:1.48.0]
> at
> net.devh.boot.grpc.server.metric.MetricCollectingServerInterceptor.interceptCall(MetricCollectingServerInterceptor.java:144)
> ~[grpc-server-spring-boot-autoconfigure-2.13.1.RELEASE.jar:2.13.1.RELEASE]
> at
> io.grpc.ServerInterceptors$InterceptCallHandler.startCall(ServerInterceptors.java:244)
> ~[grpc-api-1.48.0.jar:1.48.0]
> at io.grpc.Contexts.interceptCall(Contexts.java:52)
> ~[grpc-api-1.48.0.jar:1.48.0]
> at
> net.devh.boot.grpc.server.scope.GrpcRequestScope.interceptCall(GrpcRequestScope.java:75)
> ~[grpc-server-spring-boot-autoconfigure-2.13.1.RELEASE.jar:2.13.1.RELEASE]
> at
> io.grpc.ServerInterceptors$InterceptCallHandler.startCall(ServerInterceptors.java:244)
> ~[grpc-api-1.48.0.jar:1.48.0]
> at
> io.grpc.internal.ServerImpl$ServerTransportListenerImpl.startWrappedCall(ServerImpl.java:703)
> ~[grpc-core-1.48.0.jar:1.48.0]
> at
> io.grpc.internal.ServerImpl$ServerTransportListenerImpl.access$2200(ServerImpl.java:406)
> 

Re: [grpc-io] Cache response in ServerInterceptor

['Eric Anderson' via grpc.io]

That interceptor looks fine. Note that the issue could be in a different
interceptor.

On Fri, Jul 22, 2022 at 7:03 PM jinxiang lang 
wrote:

> java.lang.IllegalStateException: java.lang.IllegalStateException: call
> already closed
> ...
> Caused by: java.lang.IllegalStateException: call already closed
>

The second stack trace here that you didn't include is the stack I'd need
to see. I expect it is the interceptor line "call.close(Status.OK,new
Metadata());". If it is anything other than that, then it'd be helpful to
see.

I have a new discovery, which may occur in serialization and
> deserialization, and an exception occurs, causing the problem to report an
> error ”call already closed“


Yeah, I see a flow that could cause that if the message couldn't be
serialized. What error does the client see?

-- 
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%2B4M1oMTJCyVGccfroCwT_VsmSYV5FOQJ7JafO9c%2BgxCOM6a2Q%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Guaranteed in-order delivery of streamed messages?

['Eric Anderson' via grpc.io]

gRPC guarantees that when you receive a message on the stream you have
received all previous messages on that stream. Messages can be lost in
cases you wouldn't be surprised, like if you get an error.

On Mon, Jul 25, 2022 at 2:41 PM Davor Cubranic 
wrote:

> The core concepts document states " gRPC guarantees message ordering
> within an individual RPC call". Does it also guarantee delivery of all
> messages in the stream? E.g., in an API for large data upload, say *"*rpc
> PutData(stream DataChunk)", should streamed messages include a field to
> help detect if any of them is missing?
>
> Thank you,
>
> Davor
>
>
>
> *Confidentiality Notice: This communication contains information which is
> confidential and may also be legally privileged.  If you are not the
> intended recipient(s), you are hereby notified that any disclosure,
> copying, distribution, or use of this communication is strictly
> prohibited.  If you have received this communication in error, please
> notify the sender and promptly delete from your system the entirety of the
> communication and any copies thereof.  *
>
> --
> 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/7d38e034-ed19-4d31-9feb-c42167f11ff3n%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%2B4M1oOwkv6atWzz94mq%2Bi-fUoJT-aEqHSopsoGOrCda7pZ6cA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRFC A54: Restrict Control-Plane Status Codes

['Eric Anderson' via grpc.io]

This is the discussion thread for https://github.com/grpc/proposal/pull/314

Abstract:
The gRPC control plane has no need to use many of the status codes yet
communicates with external services whose status codes may accidentally be
copied to the data plane. This gRFC restricts the allowed status codes the
control plane can use when failing an RPC, as a safeguard against bugs.

-- 
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%2B4M1oMN80qv0311r%2BmETfZDm3RV%3D8dtXzCrhkkV8ofdKmLp1Q%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] gRPC java: what is the best practice to overcome the setter challenge

['Eric Anderson' via grpc.io]

On Thu, Jul 7, 2022 at 5:30 AM Vahab Jabrayilov 
wrote:

> Since, they don't have any setters associated with them I cannot use those
> classes in my main logic;
>

"Can't" is a bit strong. You could use the immutable objects in your logic,
but I'd agree that produces a very different code structure. Immutable
objects can have nice benefits when multi-threading.

hence I keep my version of custom implementation for main logic and use
> gRPC generated one for communication;
>

That is a common approach, but for the different reason of allowing your
application internals to be a bit different from the messages used for
communication. For example, if you want to add a "processed" bit to a
message as part of a (theoretical) optimization, then you'd have to expose
that to your users with your current design.

My question is "Is there any way to overcome having redundant classes ? How
> can I use the gRPC generated ones in my implementation such that I will be
> able to mutate them?"
>

You can use the builders as mutable objects, but only briefly. I think once
you build a message (a copy) to use with gRPC it takes another copy to make
its children mutable again. I think people just use the immutable objects
or make their own classes.

-- 
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%2B4M1oPo6gRFYKpnJ1Ws5vjpp%2BOOxdLrK%3D0Vj%2BW9MTPoQTCwCw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Cache response in ServerInterceptor

['Eric Anderson' via grpc.io]

If it is just based on the metadata token (which is suspicious), then just
respond in-line:

String token = headers.get(CLIENT_HEADER_KEY);
RespT resp = (RespT) select(token);
if (resp != null) {
  call.sendHeaders(new Metadata());
  call.sendMessage(resp);
  call.close(Status.OK, new Metadata());
  return;
}
// proceed with next.startCall() to save responses into the cache.

On Thu, Jul 21, 2022 at 6:49 AM jinxiang lang 
wrote:

> Hi
>
> I am trying to build an ldempotentInterceptors, I want to save a token in
> the header, save the token and response in the first gRPC call, and query
> the response through the token in the second call, and return directly.
>
>
> My searches have come across:
>
>
> https://gist.githubusercontent.com/marcellanz/b10b77a8cf4c71a30904afae8aa33960/raw/de94f9176d856508c0ffcf3a9985e14015da9704/useInputStreamMessages.java
>
> https://github.com/grpc/grpc-java/issues/1712
>
> https://engineering.kabu.com/entry/2021/03/31/162401
>
> https://groups.google.com/g/grpc-io/c/_osH2D6L9Ck/m/FdvqQgkRDgAJ
>
>
> I don't know what to do, hope can get help
>
> Am I missing something obvious?
>
> PS. A big thank you to all the maintainers
>
> public class IdempotentInterceptors implements ServerInterceptor {
>
> private static final Metadata.Key CLIENT_HEADER_KEY =
> Metadata.Key.of("token", Metadata.ASCII_STRING_MARSHALLER);
>
> @Override
> public  ServerCall.Listener
> interceptCall(ServerCall call, Metadata headers,
> ServerCallHandler next) {
>
> String token = headers.get(CLIENT_HEADER_KEY);
> MethodDescriptor methodDescriptor =
> call.getMethodDescriptor();
> String serviceName = methodDescriptor.getServiceName();
> String bareMethodName = methodDescriptor.getBareMethodName();
> log.info("1、header received from client token: {}, serviceName:
> {}, bareMethodName: {}", token, serviceName, bareMethodName);
> ServerCall wrapperCall =
> new ForwardingServerCall.SimpleForwardingServerCall RespT>(call) {
>
>
> @Override
> public void sendMessage(RespT response)
> save(token, response);
> super.sendMessage(response);
> }
>
> };
>
> ServerCall.Listener listener = next.startCall(wrapperCall,
> headers);
> return new
> ForwardingServerCallListener.SimpleForwardingServerCallListener(listener)
> {
>
>
>
> @Override
> public void onMessage(ReqT request) {
> RespT response = null;
> if (token != null) {
> response = (RespT) select(token);
> }
> if (response != null) {
> //
>
>
> } else {
> super.onMessage(request);
> }
> }
>
> };
> }
>
> }
>
>
>
> --
> 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/878a29fd-71c3-4356-a69a-3a87d6864be6n%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%2B4M1oMONAzpg%3DftvFVnYAib8hY9uYwtysmV26CL4strCB4vvw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] gRPC Java: snapshots

['Eric Anderson' via grpc.io]

v1.48.0 was scheduled for last week, but there were some testing delays
that delayed it to this week. The build will likely happen today or
tomorrow with the announcement the day after. There's some evidence
 of the release process
in-progress.

On Mon, Jul 18, 2022 at 11:27 PM Паша Варченко  wrote:

> Hello again!
>
> When can we expect release 1.48.0? Can't wait to go to production =)
>
> среда, 29 июня 2022 г. в 09:50:34 UTC+3, Паша Варченко:
>
>> Thank you very much! I found 1.48.0-SNAPSHOT in
>> https://oss.sonatype.org/content/repositories/snapshots/
>>
>> вторник, 28 июня 2022 г. в 19:07:51 UTC+3, Eric Anderson:
>>
>>> I assume you are wanting to test the Netty upgrade. I don't recall if
>>> the version we upgraded to has the linker fix. In any case, I've published
>>> a snapshot build to
>>> https://oss.sonatype.org/content/repositories/snapshots/
>>>
>>> On Tue, Jun 28, 2022 at 6:44 AM Паша Варченко  wrote:
>>>
 I'm looking for a snapshot version of grpc-java to test fix of
 https://github.com/grpc/grpc-java/issues/8751.
 Where I can find it? https://oss.sonatype.org/ does not have needed
 snapshot...

 --
 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/09cc323e-d437-4876-bb9c-8cfaf058029dn%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/b102c9c9-bd86-4e2e-ba9d-f6791ac47e3dn%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%2B4M1oNb66n1u-8mcX1a5b9v-tLdVAoU%2BO%3D%3D9qd1aehaqOa%3DFw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] gRPC Java: snapshots

['Eric Anderson' via grpc.io]

I assume you are wanting to test the Netty upgrade. I don't recall if the
version we upgraded to has the linker fix. In any case, I've published a
snapshot build to https://oss.sonatype.org/content/repositories/snapshots/

On Tue, Jun 28, 2022 at 6:44 AM Паша Варченко  wrote:

> I'm looking for a snapshot version of grpc-java to test fix of
> https://github.com/grpc/grpc-java/issues/8751.
> Where I can find it? https://oss.sonatype.org/ does not have needed
> snapshot...
>
> --
> 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/09cc323e-d437-4876-bb9c-8cfaf058029dn%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%2B4M1oN6WONiWuTtCfDiDUaPdYKNOBzSfDaBinL%3DF1E%2BF4EFVg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Using gRPC for server client communication in a java desktop app

['Eric Anderson' via grpc.io]

On Tue, Jun 21, 2022 at 4:51 AM Rohm  wrote:

> Hello, I would like to hear what you people think about approach mentioned
> in the title in general.


Nothing is strange about this use-case. gRPC would be fine. REST and gRPC
are very similar for this use case, from a networking perspective.

- In a small team: Do you think it is possible maintain the services in a
> way, that clients won't have to updated everytime the server is updated?
> (e.g. clients that use api.v1 can still operate with a server that is on
> api.v2)
>

The normal thing to do is not create a v2 unless you really have to. You
are free to add new fields to existing services without breaking existing
clients. If you do make a v2 and you want to support v1 clients, the server
will need to have a v1 service implementation.

-- 
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%2B4M1oNotThxDbnOgWur4Kpf1dLZoH7p7%2B3RK4yM1G9W0TLyug%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Accessing NettyServiceHandler for grpc-java

['Eric Anderson' via grpc.io]

On Tue, Jun 14, 2022 at 6:39 PM Doug DesCombaz  wrote:

> Some issues:
> 1)  I don't think I can use the NettyServerBuilder() because it expects a
> shadowed version of the event loops. In other words, the GRPC project
> brings in the Netty code and repackages, so many classes can't be used
> back-and-forth.
>

That's if you are using grpc-netty-shaded. The grpc-netty artifact doesn't
shade Netty, so you can share event loops.

2) The NettyServerHandler
> 
>  isn't
> exposed in the package.
>

And if it were it wouldn't really be useful. It is still using the old
monolithic callback-based Netty HTTP/2 API so can't intermix with other
HTTP handlers for the same connection. I don't think we'll ever go the
Http2MultiplexCodec route, but getting on the Http2FrameCodec would allow
some of these things to be possible. Although it would still take some
redesign/refactoring in gRPC as RPC handling is intermixed with connection
handling. To make something where you would implement your service using
Netty APIs would essentially end up as a rewrite.

Some possibilities:
> 1) I think it would be possible if I forked the grpc-java: /netty... code.
> Probably expose the underlying Context/Channel/Pipelines to the generated
> service stub. Maybe, but also not too trivial.
>
2) Ultimately, I can just run two servers, and send it over a socket, but I
> was hoping to not add a hop.
> 3) Any other ideas ?
>

Port sharing is not really in the cards right now. If you tried to fork the
code I think you'd discover rapidly its architecture is vastly different
from what you're searching for.

You could use LocalChannel instead of having a second socket, but the gRPC
code would still be expecting HTTP/2 frames.

Making a gRPC server that only handles the RPC stuff isn't that hard of an
affair. It wouldn't be all that bad for someone to make a gRPC Netty
handler to use in Netty-based applications.

-- 
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%2B4M1oNK-BNzBhABS3vbtHa6XyOtqb0vAZHC546%3Dh%2BdR0aeJSA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Is gRPC actually compatible with HTTP semantics?

['Eric Anderson' via grpc.io]

On Thu, Apr 28, 2022 at 10:03 PM Samuel Williams <
space.ship.travel...@gmail.com> wrote:

> Hello, I'm the maintainer of an HTTP client/server covering HTTP/1 & 2.


I assume this is related to https://github.com/socketry/async-http/pull/92
. I saw the thread, but it seemed to resolve reasonably correctly, so I
decided I didn't need to speak up.

HTTP/1 says "SHOULD" have `te: trailers` in the client to server request
> headers, `trailer: name1, name2, ... nameN` in the response headers and
> `name1, name2, ... nameN` after a chunked body.
>

Right, it is a helpful aid to the client, but isn't mandatory. In gRPC
there have been some implementations where the server responds with trailer
header due to specific APIs (e.g., the Go HTTP server API). That is "okay"
from gRPC's perspective but not mandatory.

I don't see as much detail in the relevant RFCs for HTTP/2, so maybe that
> means it's not needed.
>

HTTP/2 doesn't change the semantics here at all.

I would really appreciate any insight you might have regarding how this
> should be handled as someone who wants to implement a compliant HTTP1/2
> client & server interface, and whether gRPC is compliant with HTTP as a
> semantic rather than just HTTP/2 the protocol/framing format.
>

The RFC has the SHOULD for the sender but nothing for the receiver. I see
few allowances afforded to the receiver other than accepting *all* the
trailers or ignoring *all* the trailers. There's nothing about stripping
out trailers that are lacking from the Trailer header, for example. Failing
definitely seems inappropriate.

The Trailer header just seems like an optimization. It is helpful, but not
mandatory. "Welcome to HTTP."

-- 
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%2B4M1oN824fx%3D5kRzQmGXtC4mPhcEoXd5H5M2p3iNT_VTDgK2w%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRPC Java v1.46.0 Released

['Eric Anderson' via grpc.io]

The v1.46.0 release 
is now available.

Bug Fixes

   - netty: Fixed incompatibility with Netty 4.1.75.Final that caused
   COMPRESSION_ERROR (#9004 )
   - xds: Fix LBs blindly propagating control plane errors (#9012
   ). This change forces the
   use of UNAVAILABLE for any xDS communication failures, which otherwise
   could greatly confuse an application. This is essentially a continuation of
   the fix in 1.45.0 for XdsNameResolver, but for other similar cases
   - xds: Fix ring_hash reconnecting behavior. Previously a
   TRANSIENT_FAILURE subchannel would remain failed forever
   - xds: Fix ring_hash defeating priority’s failover connection timeout.
   grpc/proposal#296 
   - binder: Work around an Android Intent bug for consistent
   AndroidComponentAndress hashCode() and equals() (#9061
   )
   - binder: Fix deadlock when using process-local Binder (#8987
   ). Process-local binder has
   a different threading model than normal FLAG_ONEWAY, so this case is now
   detected and the FLAG_ONEWAY threading model is emulated
   - okhttp: Removed dead code in io.grpc.okhttp.internal.Util. This should
   have no impact except for static code analysis. This code was never used
   and was from the process of forking okhttp. It calculated things like MD5
   which can trigger security scanners (#9071
   )

Behavior Changes

   - java_grpc_library.bzl: Pass use_default_shell_env = True for protoc (
   #8984 ). This allows using
   MinGW on Windows
   - xds: Unconditionally apply backoff on ADS and LDS stream recreation.
   Previously if a message had been received on the stream no backoff wait
   would be performed. This limits QPS to a buggy server to 1 QPS, instead of
   a closed loop
   - xds: Skip Routes within VirtualHosts whose RouteAction has no
   cluster_specifier. This probably means the control plane is using a
   cluster_specifier field unknown/unsupported by gRPC. The control plane can
   repeat the Route with a different cluster_specifier for compatibility with
   older clients
   - xds: Support xds.config.resource-in-sotw client capability. Resources
   wrapped in a io.envoyproxy.envoy.service.discovery.v3.Resource message
   are now supported (#8997 )

New Features

   - gcp-observability: A new experimental module for improving visibility
   into gRPC workloads. Initially supports logging RPCs to Google Cloud Logging
   - grpclb: Support setting initial fallback timeout by service config (
   #8980 )

Dependencies

   - PerfMark bumped to 0.25.0 (#8948
   )
   - okhttp: the okhttp dependency is now compile only (#8971
   ). Okhttp’s internal HTTP/2
   implementation was forked inside grpc-okhttp a long time ago, but there had
   been a few stray internal classes that had not been forked but should have
   been. That has now been fixed in preparation for OkHttp 3/4 support.
   Compile-only may cause a runtime failure for code using reflection on
   OkHttpChannelBuilder; add a dependency on okhttp 2.7.4 to resolve
   - bom: Removed protoc-gen-grpc-java from the BOM, as the classifier was
   confusing and it provided no value (#9020
   )

Acknowledgements

@jesseschalken 
@kluever 
@beatrausch 

-- 
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%2B4M1oOKnuWErzK8tZ7yQQ%2B1P%3DzaZ%2Bi1dMFgOusc_Jb_c6phtA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Spec clarification about multi-value custom metadata -> HTTP/2 headers

['Eric Anderson' via grpc.io]

On Thu, Apr 14, 2022 at 4:13 PM Peter Wiese  wrote:

> Per the gRPC over HTTP/2 spec
> https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#requests
>
> I read that as either form is acceptable. If that is true my other
> question is if a gRPC server receives headers in either form are they
> semantically the same?
>

I'm a bit confused what wasn't explained by this about Custom-Metadata; it
seems you saw it:

> Duplicate header names may have their values joined with "," as the
> delimiter and be considered semantically equivalent.


So yes, they are semantically the same. This is actually an HTTP-ism
exposed in gRPC, so the HTTP spec talks about this
 if you care.

A grpc-dotnet client (which replaces the wrapper over Grpc.Core) turns
> multiple metadata items into a single HTTP/2 header and a grpc-dotnet
> server reads it back as a single header with a comma-separated value (as a
> string).
>

That's okay. Note that it would *not* be okay to split on ',' within the
API; that can only be done with knowledge about that specific
header's format. (E.g., maybe it supports commas in double quotes like CSV,
or allows backslashes before commas to escape, or maybe it isn't
multi-valued at all)

Note that proxies can also perform this transformation, so every language
may see the combined form.

I think it would be quite fair to only support single-valued headers within
a gRPC API for non-binary headers. It is much easier to use and less prone
to buggy usage.

-- 
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%2B4M1oN0_Aa8syjXM9f99P_Niy8YTE1CPSTqjOLL8C%2BV-D9fOg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] writing a grpc-based interface specification

['Eric Anderson' via grpc.io]

Depending on what you mean by "formal,"
https://github.com/googleapis/googleapis may be a good reference.

If that's not what you're looking for, describe more of what you mean by
"formal." (There are a couple different usages that vary by circumstance.)

On Thu, Apr 21, 2022 at 5:56 AM Stefan Seefeld 
wrote:

> Hello,
>
> we are using gRPC as part of a client-server system for which we need to
> write a formal interface specification. Is there any formal gRPC
> documentation that I could reference, i.e. something more formal than a
> bunch of web-based tutorials ?
>
> What experience do others have with formalizing gRPC-based interfaces ? We
> are surely not the first ones to run into such questions...
>
> Many 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/8a9daa0a-8f15-4edb-a700-af55eeaa6dadn%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%2B4M1oMjQTrDoAExS%2B5FP6nQD1S1aORG%2BEW%2B%2BCGfQJt%3D3q7zvQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Re: serverCallStreamObserver.isCancelled() cannot detect client disconnection for gRPC version higher than 1.41.0

['Eric Anderson' via grpc.io]

On Fri, Apr 15, 2022 at 10:09 PM 'Wen Bo (Bill) Li' via grpc.io <
grpc-io@googlegroups.com> wrote:

> If this is the new approach, what would be the new best practice in terms
> of code implementation on detecting client disconnection (using the
> workaround you provided above)?
>

It's not really a new vs old approach. Both approaches co-exist. The
ServerCall-based one has a callback that won't run concurrently with other
ServerCall.Listener/StreamObserver callbacks. That makes it very convenient
for non-thread-safe usage. The Context one is good for code needing a
callback via another thread, and is more generic and can apply to non-gRPC
and nested usages. It shouldn't ordinarily matter which of the two
isCancelled() methods you use in your specific code, with the exception of
this bug and that Context will always become cancelled at the end of the
RPC while the ServerCall one only becomes cancelled if the RPC was
cancelled.

-- 
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%2B4M1oNEJ0K9ophkbDjDeOU7mqVVyiPNJd%2BjkduuGGkX83m7qw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Re: serverCallStreamObserver.isCancelled() cannot detect client disconnection for gRPC version higher than 1.41.0

['Eric Anderson' via grpc.io]

I've reproduced similar behavior, but I'm missing a piece to get it
working. I am getting the same (apparently broken) behavior on v1.30.0,
v1.40.0, and v1.41.0. So I'll need to fitz with it more. I've attached my
seems-broken-all-the-time "reproduction."

v1.41.0 has in its release notes
:

   - core: ServerCall.isCancelled() and
   ServerCallStreamObserver.isCancelled() implementations no longer
   incorrectly return true at the end of every RPC (#8408)

So your behavior change is probably related to that. As a quick workaround,
you can use Context.current().isCancelled() instead
of serverCallStreamObserver.isCancelled().

I think I see the problem in the code; I believe we are setting the
cancelled flag within the application's callback thread, which means if you
block that thread with your while loop it won't ever be able to be set.
Before it was also getting set from another thread, but that set it too
often. But it also looks like we are doing some of that on purpose. There
was a lot to the discussion when the change was made, and we'll need to
reread it to remember what all was going on.

If you wouldn't mind, could you create an issue on github for grpc-java for
this? If not, we can, but having the original reporter create the issue
generally works best. Either way I'll comment on it with what I've
discovered.

On Fri, Apr 15, 2022 at 6:55 PM Bill Li  wrote:

> I have just found that it's grpc-netty-shaded that is causing the
> behaviour described above. The latest working version is 1.40.2. It's
> working fine by setting grpc-protobuf, grpc-stub and grpc-testing to the
> latest release version.
>
> On Friday, 15 April 2022 at 16:47:33 UTC-4 Bill Li wrote:
>
>> Yes, it is grpc-java.
>>
>> How I detected this was that google-cloud-pubsub is one of our
>> dependencies and I noticed that 1.114.6 works but not 1.114.7. After
>> digging into it deeper, I found the grpc version was upgrade from 1.40.x to
>> 1.41.x.
>>
>> The server is written in Java and the client is written in Python. The
>> server version is currently at 1.42.2. I am not sure what the client grpc
>> version is. I am using Python 3.8 and protoc version is 3.6.1.
>>
>> The disconnection happens in the middle of a streaming RPC and the
>> cancellation is detected inside a while loop. Here is a sample code snippet:
>>
>> Greeting greeting = request.getGreeting();
>> String firstName = greeting.getFirstName();
>> String lastName = greeting.getLastName();
>>
>> int i = 0;
>>
>> ServerCallStreamObserver serverCallStreamObserver =
>> (ServerCallStreamObserver)responseObserver;
>>
>> try {
>> while (true) {
>> if (serverCallStreamObserver.isCancelled()) {
>> System.out.println("cancelled");
>> serverCallStreamObserver.onCompleted();
>> break;
>> }
>>
>> String result = "Hello " + firstName + " " + lastName + ", response
>> number: " + i;
>> GreetResponse response = GreetResponse.newBuilder()
>> .setResult(result)
>> .build();
>> responseObserver.onNext(response);
>>
>> Thread.sleep(1000L);
>> i++;
>> }
>> } catch (InterruptedException e) {
>> e.printStackTrace();
>> }
>>
>> On Thursday, 14 April 2022 at 17:21:43 UTC-4 sanjay...@google.com wrote:
>>
>>> I am assuming it is grpc-java you are talking about. Couple of questions:
>>>
>>> - "when gRPC version is higher than 1.41.x" : can you pinpoint whether
>>> the client version or the server version causes this changed behavior?
>>> - "...cannot detect disconnection of a client ..." do you mean that when
>>> a disconnection happens in the middle of a streaming RPC the server used to
>>> detect it as a cancellation and that doesn't happen anymore?
>>>
>>> Same question about "...if the client disconnects from the server,..." :
>>> do you mean to say a TCP disconnection to be detected inside your while
>>> loop?
>>>
>>>
>>>
>>> On Thursday, April 14, 2022 at 10:31:52 AM UTC-7 zhl...@gmail.com wrote:
>>>
 Hi,

 I have recently discovered serverCallStreamObserver.isCancelled()
 cannot detect disconnection of a client when gRPC version is higher than
 1.41.x. So, the server logic that I have contains a while loop that runs
 forever and if the client disconnects from the server, it will call
 onCompleted() before breaking from the loop. I am wondering what has
 changed in the new versions and what is the new way to implement a similar
 behaviour?

 Regards,
 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/be8566bb-39ac-4376-8578-c75f604bd682n%40googlegroups.com
> 
> .
>

-- 
You received this 

Re: [grpc-io] Issue in Reactive gRPC streaming: Sending GOAWAY failed:'Connection reset by peer'. Forcing shutdown of the connection. Broken pipe

['Eric Anderson' via grpc.io]

On Sat, Apr 9, 2022 at 12:53 AM pranjul tayal 
wrote:

> With BloomRPC server is working fine. But when I am connecting server with
> client then on CLI of client it shows "io.grpc.StatusRuntimeException:
> UNAVAILABLE: io exception".
> On CLI of server it shows "Debugger failed to attach: handshake failed -
> received >PRI * HTTP/2.0< - expected >JDWP-Handshake<"
>

It seems like you are pointing the client at the wrong port. JDWP is the
Java remote debugging protocol.

-- 
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%2B4M1oPaXyjW-XkH3XEdDwLmkzE-ONRAQ78qtod9pu4%3DR8E%2BzA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] GRPC Call blockingUnaryCall

['Eric Anderson' via grpc.io]

What are you accomplishing via the NameResolverFactory? The deprecation
notice and the linked issue provide some guidance. But if you share your
specific use case I can point you to the replacement approach.

On Tue, Apr 12, 2022 at 8:45 AM EDMONDO SENA  wrote:

> Using NettyChannelBuilder.NameResolverFactory I Have Fixed the problem,
> but NameResolverFactory is deprecate.
>
> Which method has replaced it??
>
> Can you gelo me?
> Thanks a lot.
>
> //Edmondo.
>
>
>
> Il giorno mar 12 apr 2022 alle 17:37 Eric Anderson  ha
> scritto:
>
>> It typically does a DNS resolution, connects to the addresses one-by-one
>> until it finds one that works, does a TLS handshake, and the RPC exchange
>> which includes the server's only latency. 15 seconds is a long time. I'd
>> either expect the server is slow to respond or the networking is
>> poor (e.g., dropped packets) causing lots of latency.
>>
>> On Mon, Apr 11, 2022 at 1:33 AM EDMONDO SENA  wrote:
>>
>>> Hi all,
>>>
>>> making a client-server call using the following method to open the
>>> channel:
>>> ManagedChannelBuilder.ForTarget (: port) takes 15 seconds to
>>> get the response. Where hostname is the container name
>>>
>>> Can you explain to me what it depends on?
>>>
>>> Thanks-
>>> //Edmondo.
>>>
>> --
>>> 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/2f9e32af-90bc-49fc-84fa-5b8dfec7b30en%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%2B4M1oMKFLV_5_Wv2j2Fo_Fwis9iNztQ_CMX-JAnhLr%2BVJknDg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] GRPC Call blockingUnaryCall

['Eric Anderson' via grpc.io]

It typically does a DNS resolution, connects to the addresses one-by-one
until it finds one that works, does a TLS handshake, and the RPC exchange
which includes the server's only latency. 15 seconds is a long time. I'd
either expect the server is slow to respond or the networking is
poor (e.g., dropped packets) causing lots of latency.

On Mon, Apr 11, 2022 at 1:33 AM EDMONDO SENA  wrote:

> Hi all,
>
> making a client-server call using the following method to open the channel:
> ManagedChannelBuilder.ForTarget (: port) takes 15 seconds to get
> the response. Where hostname is the container name
>
> Can you explain to me what it depends on?
>
> Thanks-
> //Edmondo.
>
> --
> 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/2f9e32af-90bc-49fc-84fa-5b8dfec7b30en%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%2B4M1oPa3Nh%3DGWA4_pdVHLbYxQatd_0n%2Bt31cM%3DuwCt30%3Do%3Dkg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] I'm using Jetpack compose. How do I use grpc to print a value to the screen?

['Eric Anderson' via grpc.io]

gRPC can't print a value to the screen, but you can use gRPC to get a value
that you then print on the screen. Generally grpc communication is done
asynchronously and then the UI is updated once you have a result. You may
be interested in the gRPC Kotlin documentation
.

On Thu, Apr 7, 2022 at 12:49 AM Kanchan  wrote:

> I'm using Jetpack compose. How do I use grpc to print a value to the
> screen?
>
> --
> 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/b9d4aa27-6f7a-4783-a2af-9a5d8dded5f1n%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%2B4M1oPh6iQLG7sxMT%2B2vqEJdu%3DV5v7u8e22rc-M9d3CpAvqYQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Which term should I use: Interceptor or Middleware?

['Eric Anderson' via grpc.io]

We generally use the term interceptor, and that is the term used in the Go
API itself. So interceptor means something pretty precise. On client-side
Auth is commonly not implemented using an interceptor and instead may use
PerRPCCredentials. But on server-side, authn/authz is an interceptor. If
you wanted to call "all those things, like interceptors, PerRPCCredentials,
and other glue" middleware, that would be fair. If talking about a specific
implementation of something, probably better to use a more precise term.
With that approach, go-grpc-middleware as a repository name is fine, as it
has lots of various stuff, and which specific APIs it uses will vary over
time.

Essentially, in the context of gRPC, I think middleware is best suited as a
conceptual term. That said, it's also a term that is common in some
communities and unfamiliar in others. I rarely use the term myself, but I
may use it when talking to new users or the community while searching for
mutually-understood lingo. For a new user, "if you want middleware,
generally use an interceptor" can be exactly what they're needing.

I'll note that interceptor happens to be a cross-language term; most grpc
languages use that same word for essentially the same thing. Other terms
have to be translated, like PerRPCCredentials may be CallCredentials in
another language. Generally we'll use the precise term (e.g.,
"PerRPCCredentials") in whatever language context we are in/we are most
familiar with/the audience is most familiar with.

On Sun, Apr 3, 2022 at 3:04 PM Pavel Patrin  wrote:

> Hello everyone. I'm completely sure this question was discussed a lot of
> times, but I can't find anything about it here or in official docs.
>
>
> We have two places:
>
>-
>
>https://grpc.io/ - it uses the term "Interceptor" and avoids using
>"Middleware".
>-
>
>https://github.com/grpc-ecosystem/go-grpc-middleware - uses both
>Middleware and Interceptor, and looks like they didn't distinguish between
>themselves.
>
> I'm writing a configuration object for Golang service, and choosing how to
> name the field: "WithAuthMiddleware" or "WithAuthInterceptor". What is the
> official gRPC community position about it?
>
> --
> 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/185fa072-34ca-43ed-a618-49a8103ca06an%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%2B4M1oO9OWo2cpu%3Di3y%3DHtRBOnW3Osd8aKg5-fBAqsjT6P2Dtg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] GRPC Get Server Address

['Eric Anderson' via grpc.io]

What programming language are you using?

On Fri, Apr 8, 2022 at 7:55 AM Mingyu Lu  wrote:

> Hi,
> I am using GRPC with UNIX domain socket. I'd like to have one server
> listen on two sockets A and B.
> If requests come from A, I'd like to do something but if from B, I want to
> do something different.
> For security concern, I can't trust what comes from request.
> I suppose if I can get server address when requests come in, problem
> solved.
> Does anyone have any idea ? 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/b4c59951-59c3-4b2c-9773-9a5ba6f589f3n%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%2B4M1oOo7rMeGPc10MKezeXQqY03n2%2BxNp8WQVGO%2BU9%2BjRftjQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRPC Java v1.45.1 Released

['Eric Anderson' via grpc.io]

The v1.45.1 release 
is now available.Bug Fixes

   - netty: Fixed incompatibility with Netty 4.1.75.Final that caused
   COMPRESSION_ERROR (#9004 )
   - xds: Fix LBs blindly propagating control plane errors (#9012
   ). This change forces the
   use of UNAVAILABLE for any xDS communication failures, which otherwise
   could greatly confuse an application. This is essentially a continuation of
   the fix in 1.45.0 for XdsNameResolver, but for other similar cases

-- 
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%2B4M1oNU6wp4EyasDmrHetBV9F2gtpSF_YoF0M9FQ7HD_1%2B98Q%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Re: How to correctly handle UNAVAILABLE: Abrupt GOAWAY returned from nginx

['Eric Anderson' via grpc.io]

On Sat, Mar 12, 2022 at 10:13 PM 'sanjay...@google.com' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Upgrading to grpc 1.41 is definitely worth trying because of this
> https://github.com/grpc/grpc-java/pull/8359 .
>

I agree, although that fix was backported to v1.40.0 (but use newer
v1.40.2). Nginx's behavior will fail RPCs. You need retries to avoid that.
v1.40.0 enabled retries, and has the fix to improve this specific
situation. But in general, we'd recommend upgrading to one of the two most
recent minor releases.

-- 
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%2B4M1oOmfuNmcsNrx_iowWtUPeTt%2B6vEUp8uNJPXeMxee8Q1Bg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] combination of protoc version, protobuf-java, and grpc-java

['Eric Anderson' via grpc.io]

It sounds like you aren't using Maven or Gradle.

For the generated code, if generating code with version X of protoc or the
gRPC plugin, you need to use the corresponding Java components (runtime) at
version X or later.

You are using protoc 3.19.0, so you need to use protobuf-java 3.19.0 or
later. Similarly, if you were using protoc-gen-grpc-java 1.43.0, you'd need
to use grpc-protobuf 1.43.0 or later. For simplicity the versions of the
code generator and the runtime generally match; newer runtimes support
older generated code to allow combining generated code from multiple
sources (libraries) and isn't all that important when you are running the
generator and choosing the runtime version yourself.

On Tue, Feb 22, 2022 at 7:07 AM Ronak Prajapati  wrote:

> Hi Team,
>
> How can I find
>
> *right combination of protoc version, protobuf-java, and grpc-java.*
>
> can you suggest me this and how can I download it I want to use it in  my
> standalone application.
>
> I will build my own script build protoc and then wamt use GRPC library to
> send it from client to server.
>
> right now I am facing below issue,
>
>
> *!com.google.protobuf.GeneratedMessageV3.isStringEmpty(userAccountUniqueId_)*
> Where I am using *protoc-3.19.0-win64 and protobuf-java-3.17.2 jar*
>
> In which this isStringEmpty method doees not exist. But protoc is
> generating this code.
>
> --
> 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/a2eb0b26-cc25-42b8-aa5b-7bd63044c031n%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%2B4M1oNUGLOXKbrfyUgJ5r5zFBGYF5yvBTcOJJwUMSi_o4-QiA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Interpretation of "updates_only" flag in the gnmi subscription request

['Eric Anderson' via grpc.io]

On Wed, Feb 16, 2022 at 4:36 AM Ashutosh Maheshwari <
ashutosh.maheshw...@gmail.com> wrote:

> Referring to the grpc specification of updates_only flag here -
> https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md
>
> I would like to learn from the creator and users of grpc, what is the
> correct interpretation of updates_only flag w.r.t sample and onchange based
> subscriptions.
>
> ...
> Would you please clarify from GRPC standpoint, what is the right
> interpretation ?
>

I don't see anything there really from the "gRPC standpoint." Yes, it uses
gRPC, but the concepts it is discussing are gNMI concepts built on top. It
seems to be gNMI-specific, which this list probably can't help you much
with.

-- 
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%2B4M1oMQfxvvY64H-LkngWP-Ju1ZPVKjJ%3DHkKrBxGb%3DTAiOAzg%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Java 8 end of life for gRPC ?

['Eric Anderson' via grpc.io]

On Fri, Jan 28, 2022 at 7:19 AM 'Russell Shaw' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Our company uses Java8 on Z/OS


The TL;DR for all this stuff is probably: For Google Cloud users, overall
I'd expect service-specific issues to crop up more than gRPC compatibility
issues. For example, if you want to use a new service, the library may only
support Java 11+. But you really want a plan to upgrade to Java 11 and
beyond.

Thank you so much for the email. We really do want to hear trouble caused,
as otherwise there's no feedback loop. Sorry for the delay, your email was
just brought to my attention.

In your specific case, it looks like IBM's Java 11 was only recently made
available
?
That's a bit worrisome, as it only buys you 1.5 more years, as end of
Premier Support of Java 11 is rapidly approaching. I'm going to need to
keep an eye on that. But you aren't *blocked*, right? It is just "gotta
move quickly"?

I'll note that practically speaking I doubt we'll actually drop Java 8 in
March. I mainly wanted people to realize *that we could*, because we really
need to have these conversations now and then when we delay it is perceived
as niceness :-). I expect gRPC will wait until ~June before dropping Java
8, because dropping Java 8 hasn't been on user's radar until recently.

But that may not hold for the rest of the Google client libraries. You as a
Google Cloud library consumer are intended to be insulated from gRPC, so
you should really only need to track the Google Cloud libraries.

I am guessing that the final gRPCJava version built via Java 8, will still
> be able to talk to Pubsub for a while, until the PubSub/gRPC protocols
> changes enough that it eventually breaks.
>

In that case Pubsub support policies still apply. See Google's Java
supported version documentation
.

gRPC v1.44.0 is still compatible with v1.0.0. A backward incompatible
change would be a big deal and probably need a multi-year migration
process. I know of no features currently discussed that would need to break
the protocol. (Sure, a new feature may need both sides to be upgraded *to
be used*, but then you just wouldn't benefit from the feature.) I wouldn't
be concerned about protocol breakages in the low-single-digit years time
frame.

There could, however, be behavior changes which don't impact correctness
but could impact performance or similar. This is less likely about gRPC
specific implementation but instead the HTTP/2 ecosystem or auth or
$SOME_OTHER_NON_GRPC_BUT_RELATED topic. These are managed by the Google
service support policies. Google will almost certainly try to avoid these,
but if something crops up you'd go through the Google support processes.
Not speaking authoritatively, but if there's a case of 1-5% performance
decrease, then that just may be the price paid. But something like a 75%
decrease is more like a service deprecation with notifications, etc. Google
can track usage of the old versions via the User-Agent.

Is there any Google Cloud Platform information on "no longer supported"
> versions of Pubsub / grpcjava  jars / cloud-boms? I can't find it mentioned.
>

I thought I had seen something about library versions being supported for a
year, but it might be in support contracts or similar non-public
documentation, or I just may be wrong. The Java version support policy does
clearly define that the Java 7 releases are best effort. I'd expect Java 8
to be included in that when it reaches its EOL.

-- 
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%2B4M1oMnLmtLkKV4%2BSkNZ0osv-4CyiM-2Sm1%3DBpEX8rivXFX%3DQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

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

['Eric Anderson' via grpc.io]

I have made a "grpc proxy" example in Java
,
which I've shared a few
 times
. Such
things should be possible in most other languages, although the difficulty
would vary.

What language is server/client B written in?

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%2B4M1oNrmTo9Ax1XG7KTO2d_d0UqQ3TXLsTd8ahzZCMEF8ZPYA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] client StreamObserver is always getting messages in sequence

['Eric Anderson' via grpc.io]

On Tue, Feb 8, 2022 at 10:15 PM mayank kulshreshtha 
wrote:

> the expectation was that the messages which i will receive in observer
> will be out of order
>

StreamObserver (and ClientCall.Listener) are not thread-safe, so gRPC
serializes callbacks into them.

as ClientCallImpl.class has
> callExecutor.execute(new MessagesAvailable());
>

Yes, but callExecutor is the user's executor wrapped in a
SerializingExecutor

.

  this.callExecutor = new SerializingExecutor(executor);


> is this an expected behaviour?
>

Yes, it is. It is *very hard* for applications to manage the events if they
arrive out-of-order. It is much easier for users to implement a
non-thread-safe class.

-- 
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%2B4M1oNkB_GAo%3DR2OPq%3DvgPDdvJg3M%2B4CqN%3DBf5y8zzHmVXoQA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRPC Java v1.41.2 Released

['Eric Anderson' via grpc.io]

gRPC Java 1.41.2 is released and is available on Maven Central. It will
take additional time to be indexed by search.maven.org, but it is in the
repository.

https://github.com/grpc/grpc-java/releases/tag/v1.41.2

Bug Fixes

   - core: fix a race condition when calling ManagedChannel.enterIdle() (
   #8763 )
   - xds: stop generating UUIDs for filter chains that lack them. The UUID
   was preventing the XdsServer from noticing when a control plane sent a
   needless duplicate update, causing XdsServer to drain all its existing
   connections to use the “new” configuration #8736
   

Dependencies

   - Upgraded Protobuf to 3.18.2 to avoid CVE-2021-22569. See the protobuf
   advisory
   

   - Upgraded Guava to 30.1.1-android

-- 
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%2B4M1oPpGJRNAxpfmzseDddWbmtpyLedq22-OtPtHXRC5BwOXQ%40mail.gmail.com.

[grpc-io] Re: gRPC Java 1.42.2 Released

['Eric Anderson' via grpc.io]

Correction: Protobuf was upgraded to 3.18.2, not 3.19.2.

On Thu, Jan 6, 2022 at 3:15 PM Eric Anderson  wrote:

> gRPC Java 1.42.2 is released and is available on Maven Central. It will
> take additional time to be indexed by search.maven.org, but it is in the
> repository.
>
> https://github.com/grpc/grpc-java/releases/tag/v1.42.2
>
> Bug Fixes
>
>- census: fixed a bug which in rare cases, a NullPointerException may
>be thrown by recordFinishedAttempt(). Users not enabling grpc-census
>are not impacted by this bug (#8706
>)
>- core: fix a race condition when calling ManagedChannel.enterIdle() (
>#8761 )
>
> Dependencies
>
>- Upgraded Protobuf to 3.19.2 to avoid CVE-2021-22569. See the protobuf
>advisory
>
> 
>- Upgraded Guava to 30.1.1-android
>
>

-- 
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%2B4M1oN77fpHqSEVf5t%3DXxr6EcjGueKLpzDsLxwWX63tNT7wzQ%40mail.gmail.com.

[grpc-io] gRPC Java 1.42.2 Released

['Eric Anderson' via grpc.io]

gRPC Java 1.42.2 is released and is available on Maven Central. It will
take additional time to be indexed by search.maven.org, but it is in the
repository.

https://github.com/grpc/grpc-java/releases/tag/v1.42.2

Bug Fixes

   - census: fixed a bug which in rare cases, a NullPointerException may be
   thrown by recordFinishedAttempt(). Users not enabling grpc-census are
   not impacted by this bug (#8706
   )
   - core: fix a race condition when calling ManagedChannel.enterIdle() (
   #8761 )

Dependencies

   - Upgraded Protobuf to 3.19.2 to avoid CVE-2021-22569. See the protobuf
   advisory
   

   - Upgraded Guava to 30.1.1-android

-- 
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%2B4M1oPqo54LXEcUth3KEjsTnBP%3Dd9qFYfKFD1G9gjs%3DwOcXMw%40mail.gmail.com.

[grpc-io] gRPC Java v1.43.2 Released

['Eric Anderson' via grpc.io]

gRPC Java 1.43.2 is released and is available on Maven Central. It will
take additional time to be indexed by search.maven.org, but it is in the
repository.

https://github.com/grpc/grpc-java/releases/tag/v1.43.2

Dependencies

   - Upgraded Protobuf to 3.19.2 to avoid CVE-2021-22569. See the protobuf
   advisory
   


-- 
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%2B4M1oNN2171Oi0EvOtTKdUWmEvDtmgaA759g4dbi%2BCQACMAVw%40mail.gmail.com.

[grpc-io] Java/Kotlin: Protobuf DoS CVE-2021-22569

['Eric Anderson' via grpc.io]

All older versions of protobuf-java are vulnerable to a DoS when parsing a
malicious protobuf message. Users of protobuf-java and protobuf-kotlin,
which includes non-Android grpc-java and non-Android grpc-kotlin users,
should upgrade to protobuf-java 3.16.1, 3.18.2, or 3.19.2. See the protobuf
advisory

.

protobuf-javalite and protobuf-kotlin-lite are not impacted, which means
the majority of Android usages should not be impacted. Protobuf-kotlin is
impacted because it has a dependency on protobuf-java.

You can use `mvn dependency:tree` (Maven) or `gradle dependencies
--configuration runtimeClasspath` (Java plugin Gradle) or `gradle
dependencies --configuration releaseRuntimeClasspath` (Android Gradle) to
determine the version of protobuf-java being used.

-

Users of com.google.cloud:libraries-bom should upgrade to 24.1.2 which
selects the newer protobuf version.

Other impacted gRPC users should add an explicit dependency on the newer
version of protobuf-java to override the grpc-suggested version. Maven
users are also encouraged to use Maven Enforcer's requireUpperBoundDeps to
detect version downgrades.

gRPC will be releasing patch releases that bump the protobuf version to aid
pushing the vulnerable protobuf-java versions out of the ecosystem.
Upgrading to these also resolves the issue, although Maven users must use
requireUpperBoundDeps or manually verify the results with dependency:tree.

-- 
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%2B4M1oOqmurs0QVBFokKgexzsRuP_A3nvu6j8tk4AF%2BmJjdK3Q%40mail.gmail.com.

[grpc-io] Re: gRFC P5: JDK Version Support Policy

['Eric Anderson' via grpc.io]

Bumping now that people are likely coming back online, to avoid being lost
in holiday inboxes.

On Thu, Dec 23, 2021 at 9:33 AM Eric Anderson  wrote:

> I've created a gRFC for the JDK version support policy:
> https://github.com/grpc/proposal/pull/283
>
> *gRPC Java users running Java 7 or Java 8 should definitely read.* Those
> that don't have Java 17 plans yet should also take a look. The important
> part is the Proposal section, which is short. The current TL;DR is we'd
> follow Oracle's Premier Support timelines
> .
>
> Discussion can happen here or on the PR.
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oP8Z1qSOZ_ucgVi5t-bSs4WEM_00MC1YDe87dODig%2B-ag%40mail.gmail.com.

[grpc-io] gRFC P5: JDK Version Support Policy

['Eric Anderson' via grpc.io]

I've created a gRFC for the JDK version support policy:
https://github.com/grpc/proposal/pull/283

*gRPC Java users running Java 7 or Java 8 should definitely read.* Those
that don't have Java 17 plans yet should also take a look. The important
part is the Proposal section, which is short. The current TL;DR is we'd
follow Oracle's Premier Support timelines
.

Discussion can happen here or on the PR.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oOoQv3gCoGn1ORJCc9UR%3D%3DJDP%3DW3%2BmksDuB0veVVWCeOA%40mail.gmail.com.

Re: [grpc-io] Custom HTTP headers with each packet

['Eric Anderson' via grpc.io]

What language is your server written in? gRPC's Metadata is sent as HTTP
headers, so you want to add Metadata to each response.

On Mon, Dec 6, 2021 at 9:43 PM gamer boii  wrote:

> My grpc server is reading a pcap file and sending it to a backend client.
> Now, I want to add some custom HTTP header to each packet before sending it
> to the backend client. How can I do it? Are there any example code I can
> look at?
>
> --
> 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/63e92602-2cfa-4d19-9c3e-4d570026523an%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%2B4M1oMhx9Tefv6eqAYjdn1cmNOCLcsD_zHL_wpdoaAzec56og%40mail.gmail.com.

Re: [grpc-io] which port range is GRPC used.

['Eric Anderson' via grpc.io]

gRPC uses HTTP/2, so 80/443 would be the "standard" ports. But using a port
under 1024 is annoying and unnecessary in data centers, so I think people
just "choose a port." For a public-facing service, 443 would be the normal
port.

On Mon, Dec 6, 2021 at 11:01 PM Bhushan Patil 
wrote:

> Hi,
>  I am new to GRPC, and I have a question, what port range is used GRPC
> client and server. and how we can configure particular port on both.
>
>
> Confidentiality Notice and Disclaimer: This email (including any
> attachments) contains information that may be confidential, privileged
> and/or copyrighted. If you are not the intended recipient, please notify
> the sender immediately and destroy this email. Any unauthorized use of the
> contents of this email in any manner whatsoever, is strictly prohibited. If
> improper activity is suspected, all available information may be used by
> the sender for possible disciplinary action, prosecution, civil claim or
> any remedy or lawful purpose. Email transmission cannot be guaranteed to be
> secure or error-free, as information could be intercepted, lost, arrive
> late, or contain viruses. The sender is not liable whatsoever for damage
> resulting from the opening of this message and/or the use of the
> information contained in this message and/or attachments. Expressions in
> this email cannot be treated as opined by the sender company management –
> they are solely expressed by the sender unless authorized.
>
> --
> 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/a190f8ab-cc4d-423f-9d6e-63c6b371e481n%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%2B4M1oOvL0PufQbMSUZbP6NQJHBrjxg%3DrDSCgH2EbcytsNdnxw%40mail.gmail.com.

Re: [grpc-io] [grpc-java] Change response headers based on response message?

['Eric Anderson' via grpc.io]

On Mon, Nov 15, 2021 at 8:30 AM Mansfield Mark 
wrote:

> I'm trying to build an auth flow (email + OTP -> JWT) between a grpc-web
> client and a grpc-java server, with an Envoy proxy between the two.


I can't really speak to grpc-web too much. But I can help with the Java
side.

Just to make sure I'm not missing anything big, this is my mental image of
> how I think RPC calls are handled on the server, with a ServerInterceptor
> attached.
>
>1. ServerInterceptor#interceptCall to wrap the real call in a
>CustomServerCall
>2. CustomServerCall#sendHeaders to build and return response headers
>3. CustomServerCall#sendMessage to build and return response body
>4. CustomServerCall#close to set final status, response trailers, etc.
>5. Response headers are converted to HTTP response headers when sent
>back to the gRPC web client. Response trailers look like they are only part
>of the gRPC payload, but they don't get handled by the browser.
>
> Response trailers are moved to the HTTP payload, behind the gRPC message.
They aren't handled then directly by the browser, but code within the
browser should still have access to them.

I'm under the impression that with this pattern, the response headers are
> always built and sent before the RPC call actually starts.
>

The flow you describe doesn't include when the call "starts," so it isn't
clear to me where you've gotten wrong here. But the response headers
generally occur after receiving the request message. In Java they are
triggered when the server sends its first response message (since there
might be multiple with streaming).

This makes me think there's no access to the request body when constructing
> response headers.
>

It isn't *guaranteed* by the API the interceptors interact with, but with
the normal stubs it would normally be the case that the request body is
received before the response headers are sent. The main exception to that
is when the application errors, and never sends response headers or
response message.

My workaround is:
>
>1. Attach a username + password as request *headers*, instead of in
>the request body.
>
> This would be normal if you are doing something like HTTP Basic. The only
time I'd expect to include the user+pass in the request body is if you are
sending an RPC to a login service to exchange the user+pass for a token.

Authentication is a cross-cutting concern and isn't specific to a single
RPC method, so it is one of the most common usages of headers/metadata. I
don't see any workaround here.

>
>1. Convert username + password into a JWT in
>CustomServerCall#sendHeaders, and include a set-cookie header
>
> I don't understand how JWT gets involved here, and why it happens
in ServerCall.sendHeaders. I'd expect authentication processing to happen
in ServerInterceptor.interceptCall(). I could understand how you intercept
sendHeaders to attach set-cookie though. Although it seems the client would
continue sending the user+pass in the headers...

Are you describing the behavior for a login RPC? I can't say there's been
any thought to how set-cookie could be used, as that is not generally
observed by gRPC clients.

i think you'd need to have a SetCookieInterceptor that attaches mutable
state to the Context and has the service modify that state with cookie
details. I could write up a sketch for that after some meetings if you are
interested. But really, that is then specific to grpc-web. I think the more
"normal" approach would be to have the grpc-web client participate in the
handshake by receiving the cookie in a response message, and then having
the client attach the cookie in subsequent requests.

>
>1. The actual body of the server call is a no-op.
>
> This workaround sounds like a misuse of the API, so I wanted to see what
> your thoughts were.
>
> 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/712f96ff-4a78-48a9-b00c-84fa0f75dbban%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%2B4M1oMiC-FBgm-J3kbwHJVTVJ1zFduuUxp4Kuhy-BHT1%3DAQyQ%40mail.gmail.com.

Re: [grpc-io] GRPC client interceptors in Java and fault injection

['Eric Anderson' via grpc.io]

On Mon, Nov 15, 2021 at 12:55 AM Christopher Meiklejohn <
christopher.meiklej...@gmail.com> wrote:

> To achieve this, I've made a custom interceptor that throws an exception
> (or, creates a Status of a particular type like FAILED_PRECONDITION, and
> converting that to an exception) and throwing in the sendMessage callback,
> where I can access the message contents.
>

Interceptors should not throw. Generally interceptors should
call Listener.onClose() instead. But that also means you *must not* pass
the listener to `next`, because then it will *also* call onClose().

Before I throw the exception, I call delegate().halfClose() and *do not*
> call super.sendMessage.
>

You can have an RPC without a message. Streaming RPCs can work this way.
You are creating a new RPC, and then gracefully closing it, but the RPC
still exists.

Should this be happening?  Any insights on how I can go about debugging
> exactly what is happening?
>

You should delay calling `next` (which creates a new RPC) from the
interceptor until you are certain the RPC will be needed (i.e., that you
won't inject a failure).

The Client Cache Example is in a similar situation to you, as it needs to
avoid sending an RPC if there is a cache hit. Your code will be a bit
simpler, because you don't need CachingListener, but the
interceptCall+ForwardingClientCall code is appropriate to look at.
Unfortunately, the current code in master suffers from actually sending the
RPC unnecessarily, so you can look at my branch that has sketched out a
better approach (again, pay most attention to
interceptCall+ForwardingClientCall):
https://github.com/ejona86/grpc-java/blob/caching-interceptor-avoid-rpcs/examples/android/clientcache/app/src/main/java/io/grpc/clientcacheexample/SafeMethodCachingInterceptor.java

Essentially, it 1) avoids calling `next` until it is certain it needs an
RPC and 2) caches method calls until it has made its decision.

-- 
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%2B4M1oOxTQ-UaTkBEYe8xW85Q532tu4BHhmR3LqEiq7V%2BiNebA%40mail.gmail.com.

Re: [grpc-io] What kind of header is expected to avoid having this UNKNOWN/UnsupportedOperationException issue?

['Eric Anderson' via grpc.io]

You are experiencing https://github.com/grpc/grpc-java/issues/7953, where
grpc-java was incompatible with Netty 4.1.60+. It was fixed in grpc-java
v1.35.1, v1.36.1, and 1.37 (all released back in March/April). It seems
strange that you didn't try v1.33.1 and v1.36.2, or the latest version.
Another option is to use grpc-netty-shaded which has its own copy of Netty.

On Thu, Sep 23, 2021 at 12:52 AM Eggie  wrote:

> Hi there,
> I have a grpc server talking fine to another grpc server. However, I want
> to use jetty as my main server/port. In this case, I proxy the request
> throw jetty server and using jetty http2 client to forward the request.
> However, I am experiencing this issue. I want to ask if anyone might know
> what could causing this? or what my http2 header is missing and causing
> this? so far i know that my grpc is 1.33.0/1.36.0(I tried both), netty is
> 4.1.63 final and netty.tcnative is 2.0.38.Final.error detail:
> ```
> *Status{code=UNKNOWN, description=null,
> cause=java.lang.UnsupportedOperationException*
> *at **org.apache.ratis.thirdparty.io
> *
> *.grpc.netty.AbstractHttp2Headers.setLong(AbstractHttp2Headers.java:465)*
> *at **org.apache.ratis.thirdparty.io
> *
> *.grpc.netty.AbstractHttp2Headers.setLong(AbstractHttp2Headers.java:26)*
> *at **org.apache.ratis.thirdparty.io
> *
> *.netty.handler.codec.http2.DefaultHttp2ConnectionDecoder$FrameReadListener.onHeadersRead(DefaultHttp2ConnectionDecoder.java:407)*
> *```*
>
> Sincerely,
> Danielle
>
> --
> 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/9f295aca-63a3-4ce1-84e8-98ba6ee05a5an%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%2B4M1oMe%2BfAHmbpsrdB8iHktj_KM5tvzQBciB8LbXN2sowkCxw%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] When is the right timing to free applicaiton‘s data buffer passed to Stream io？

['Eric Anderson' via grpc.io]

There is no way to know when the buffer is safe to reuse. Because of races
between sending and notifications, you can't even safely use the buffer
after the RPC is complete.

The problem has been discussed some before
, but there is no current
solution other than copy-before-passing-to-gRPC, or use non-pooled buffers.
For *receiving*, however, there has been some work and it is possible to
receive the gRPC (pooled) buffers and avoid copying them if you are willing
to do some (not-too-bad) plumbing yourself *and* your interceptors don't
drop messages on the floor.

On Tue, Oct 12, 2021 at 12:26 AM Sammi Chen  wrote:

>
> We are using grpc-java in a distributed storage project.
>
>
> We are trying to use buffer pool on application level to improve the
> performance.  There buffer will be passed to grpc  StreamObserver#onNext
> to send to remote server.
>
> The question is when can we reclaim the buffer to reuse?  Is there any
> callback or event to notify that the data is sent and received so that we
> can safely reuse the buffer?
>
>
> 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/efcc3d14-a948-45e7-aade-4599adf1352bn%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%2B4M1oN_XNWKxtgK5hx1gXtM3u%3DpOB1DqjrNpEZ6THSTKAQM-A%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature