[grpc-io] Re: Can't decode compressed gRPC message as compression not configured
We have not experienced this issue for the past several days. We've updated the grpc-java libs on both sides(client/server) to v1.51.1. Here are the HTTP headers: 2023-02-02 02:30:19,985 DEBUG [GRPC worker, id #3] netty.NettyServerHandler - [id: 0x408a80cd, L:/xxx.xxx.xxx.xxx:8443 - R:/yyy.yyy.yyy.yyy:64339] INBOUND HEADERS: streamId=3 headers=GrpcHttp2RequestHeaders[:path: /com.xxx.yyy.grpc.service.v1.XxxService/Connect, :authority: xxx.yyy.com:8443, :method: POST, :scheme: https, te: trailers, content-type: application/grpc, user-agent: grpc-java-netty/1.51.1, traceparent: 00-9a43474eb67253ba175f03f6a4440250-cae6829dd96d83f5-01, grpc-accept-encoding: gzip] streamDependency=0 weight=16 exclusive=false padding=0 endStream=false 2023-02-02 02:30:20,254 DEBUG [GRPC worker, id #3] netty.NettyServerHandler - [id: 0x408a80cd, L:/xxx.xxx.xxx.xxx:8443 - R:/yyy.yyy.yyy.yyy:64339] OUTBOUND HEADERS: streamId=3 headers=GrpcHttp2OutboundHeaders[:status: 200, content-type: application/grpc, grpc-encoding: identity, grpc-accept-encoding: gzip] padding=0 endStream=false Will post an update if it happens again. Regards On Friday, January 27, 2023 at 7:39:39 PM UTC+2 sanjay...@google.com wrote: > On Friday, January 27, 2023 at 2:06:28 AM UTC-8 chris...@gmail.com wrote: > ... > It might not be the reason though (the error was on the server-side), > since the API says: > > > *Enables full-stream decompression of inbound streams. This will cause the > channel's outboundheaders to advertise support for GZIP compressed streams, > and gRPC servers which support the feature may respond with a GZIP > compressed stream.* > > Yes, it looks unrelated so I am going to ignore it. > > > > > > Can you enable debug/trace logging to see the value of the > "grpc-encoding" header for the offending RPC? That will give us some idea > whether you need to use a custom decompressor registry. > > Could you please provide more info of how to do that? > > At present we have such logging config: > > > > > > > which produces log like that (no "grpc-encoding" header in it): > > DEBUG netty.NettyServerHandler - [id: 0x9f841cd8, L:/xxx:8443 - > R:/yyy:43421] INBOUND PING: ack=false bytes=1234 > DEBUG netty.NettyServerHandler - [id: 0x9f841cd8, L:/xxx:8443 - > R:/yyy:43421] OUTBOUND PING: ack=true bytes=1234 > > DEBUG netty.NettyServerHandler - [id: 0x9f841cd8, L:/xxx:8443 - > R:/yyy:43421] OUTBOUND DATA: streamId=3 padding=0 endStream=false > length=249 > bytes=c708820610f8dc9594df30186b22b8010a0732353233363432120d6f706f732d3239373535316333180120033a0642555344420b313030323432... > > DEBUG netty.NettyServerHandler - [id: 0x9f841cd8, L:/xxx:8443 - > R:/yyy:43421] INBOUND DATA: streamId=3 padding=0 endStream=false length=48 > bytes=2b08e00110fbdc9594df301804221d0a0732353233363432120c6f72642d3239373735316333180220012803 > > The headers appear in a log message like this: > > Aug 26, 2022 5:21:53 PM > io.grpc.netty.shaded.io.netty.handler.codec.http2.Http2FrameLogger > logHeaders > FINE: [id: 0x22c81f9d, L:/xx.xx.x.xx:50052 - R:/yy.yyy.yy.yyy:42068] > INBOUND HEADERS: streamId=1 headers=GrpcHttp2RequestHeaders[:path: > /grpc.health.v1.Health/Check, :authority: > [qqq::qqq:qq:qq::qqq:qqq]:50052, :method: POST, :scheme: http, te: > trailers, goog-outboundacl-exempt: true, grpc-trace-bin: > AABri/UCUi7MmVLcREUbqBPsAgD8gAgARv0A/gAA, > grpc-tags-bin: AAAKb3JpZ2luYXRvchhjbG91ZC1nZmUtcHJvZC1kZWRpY2F0ZWQ, > content-type: application/grpc, user-agent: grpc-c++/1.40.0-dev > grpc-c/18.0.0 (linux; chttp2), grpc-accept-encoding: identity,deflate,gzip, > accept-encoding: identity,gzip, grpc-timeout: 4510m] padding=0 > endStream=false > > - looks like you need to enable FINE logging for > io.grpc.netty.shaded.io.netty (you have DEBUG for > io.grpc.netty.shaded.io.grpc.netty which is not enough) > - there is no grpc-encoding header in my example snippet either but I > would like to see what you have in yours when the error happens then I will > analyze the code further > > > > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/71fbc239-23fa-45e6-8dcc-67897ca693fcn%40googlegroups.com.
[grpc-io] required details about grpc gate-way in node.js
I need details about gateway feature in node.js and wen will grpc realease gateway feature in node.js . can anyone help me..? -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/025fafed-1218-4cef-90d1-ddf61fbd3b69n%40googlegroups.com.
[grpc-io] Re: Suggested approach to chain gRPC Calls
Jens, In general, the best way to do this is to simply create the channel in your Servicer constructor and then use self._channel or self._stub from your server handlers. On Wednesday, February 1, 2023 at 5:24:28 PM UTC-8 Jens Troeger wrote: > Thank you, Xuan! > > Hi, you're correct that channel should be created either during server > start or during initialization, you can then pass the stub reference to > server handler. > > Is there a recommended approach to hook into the server > start/initialization? And suppose I can create a stub, how do I then pass > it down to the handlers? Is there state I can share for intercepts, or how > do I best create and access such a “global” resource? > > Cheers, > Jens > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/6255e8bb-6c65-46be-a0e4-0e6c47f8cc77n%40googlegroups.com.
[grpc-io] Re: Suggested approach to chain gRPC Calls
Thank you, Xuan! Hi, you're correct that channel should be created either during server start or during initialization, you can then pass the stub reference to server handler. Is there a recommended approach to hook into the server start/initialization? And suppose I can create a stub, how do I then pass it down to the handlers? Is there state I can share for intercepts, or how do I best create and access such a “global” resource? Cheers, Jens -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/25093341-a3d9-40fd-b5ff-9f0cb272e5b1n%40googlegroups.com.
[grpc-io] Re: Suggested approach to chain gRPC Calls
Hi, you're correct that channel should be created either during server start or during initialization, you can then pass the stub reference to server handler. As for the threads, you can use thread_pool to control executors used by the server: https://github.com/grpc/grpc/blob/master/src/python/grpcio/grpc/__init__.py#L2030 Best, Xuan On Friday, January 27, 2023 at 9:12:38 AM UTC-8 Jens Troeger wrote: > Hello, > > Suppose I have a Servicer A whose request handler needs to call another > Servicer B. Creating a channel and a stub every time A’s handler runs > doesn’t seem efficient or sensible. > > What’s the suggested/proper way to chain gRPC calls? (In Python, if that > matters.) > > Can I hook into the Servicer’s boot, open a channel and create a stub, and > then pass down that stub through the context? Is there some interceptor > support that’s useful? > > Which leads me to the next question: can I control how many threads and > processes a Servicer can spawn for request handling? I assume each of those > needs their own channel and stub to call to another Servicer? > > Much thanks! > Jens > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/b8e23730-5165-414c-a012-b70575f7ced4n%40googlegroups.com.
[grpc-io] Re: Working example for Proxyless Java-based gRPC setup with java-control-plane
Thank you for the info! It was helpful. I continued to work on the example and finally managed to get a local xDS server built based on the java-control-plane. Really need to understand xDS at the protocol level. I am not entirely sure if my set up is correct, but the communication is established through the xDS server and I can now dig deeper to figure things out. Definitely nice to have a proxyless setup! On Tuesday, January 31, 2023 at 11:29:39 AM UTC-7 zi...@google.com wrote: > grpc-java OSS has a unit test that implements an xds control plane > > > https://github.com/grpc/grpc-java/blob/master/xds/src/test/java/io/grpc/xds/XdsTestControlPlaneService.java > > ping-pong test case: > https://github.com/grpc/grpc-java/blob/master/xds/src/test/java/io/grpc/xds/FakeControlPlaneXdsIntegrationTest.java#L88 > > The example > https://github.com/grpc/grpc-java/blob/master/examples/example-xds/README.md > requires a control plane environment so it may not work locally > automatically > > > Hope this helps, > > On Tuesday, January 31, 2023 at 10:07:14 AM UTC-8 Oleg Cohen wrote: > >> Greetings, >> >> I am looking for a working example of how to set up a Java-based >> proxyless gRPC application. I would like to have the set up run locally, >> not in K8S. Not able to get the java-control-plane to work properly with >> sample Xds server and client. >> >> Would appreciate any pointers to help with getting this work! >> >> Thank you, >> Oleg >> > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/6e0adc5b-0cf0-4b06-bd1e-d234287532ben%40googlegroups.com.
