I am using Windows 10.
When I am following the steps described at
https://github.com/grpc/grpc/blob/master/BUILDING.md#build-from-source and
execute the code in
https://github.com/grpc/grpc/blob/master/test/distrib/cpp/run_distrib_test_cmake.sh,
I run into a problem related to absl.
When I
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:
>
>
>
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.
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
Thank you very much for answer . I get it，i think. And what do you mean by
"not compressiable"，is this scenrio you are talking about: the header
value is often changing thus grpc have to compress it in almost every
request?
在2024年4月10日星期三 UTC+8 03:12:23 写道：
> You're right that gRPC C++
https://github.com/grpc/proposal/pull/423
Feedback welcome.
--
Sergey.
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to grpc-io+unsubscr...@googlegroups.com.
To
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();
}
Hello Abhijeet,
There can be a long lived stream that stays alive without the use of a for.
The for (while true essentially) is a convinent way to structure receiving
messages/sending messages. You don't need a for loop/time.Sleep to keep the
stream alive. gRPC-Go server's do fork a goroutine
