Re: [grpc-io] Re: Problems in wrting a client interceptor for python

[cyc19921205]

That's exactly I do in my code.
Hope it could be provided in `grpcio` package.
Java gRPC provides a class `SimpleForwardingClientCall`, which makes things 
much simpler.

On Tuesday, June 9, 2020 at 1:09:58 AM UTC+8, Lidi Zheng wrote:
>
> One example of how to implement the grpc.Call interface is to composite 
> the original returned object (_Rendezvous) to a new class with the logic 
> you want to add: 
> https://github.com/googleads/google-ads-python/blob/ab71f5286e66b402125eafa5dd9db4f4c37b4806/google/ads/google_ads/interceptors/exception_interceptor.py#L29
>
> On Mon, Jun 8, 2020 at 12:17 AM > wrote:
>
>> Also, `grpc._channel._Rendezvous` is a private class. It makes me nervous 
>> to inherit.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "grpc.io" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to grp...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/grpc-io/bf23e779-3219-448f-9d90-e7cae112e957o%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/4739dff0-06ab-4a4c-9e01-c5971f0af8ceo%40googlegroups.com.

[grpc-io] gRPC-Java 1.30.0 Released

['Chengyuan Zhang' via grpc.io]

gRPC Java 1.30.0 is released and available on Maven Central and JCenter. 

*gRPC Java 1.30.0 Release Notes*

*Behavioral Changes*

   - netty: Bandwidth delay product (BDP) is enabled by default (#6979 
   ). BDP dynamically adjusts 
   flow control window to optimize the network bandwidth utilization. To 
   disable this feature, build channel/server with 
   `NettyChannelBuilder#flowControlWindow` or 
   `NettyServerBuilder#flowControlWindow`. Existing `flowControlWindow` users 
   need to use `initialFlowWindowSize` to enable BDP.


*New Features*

   - core: ManagedChannel provides LoadBalancer#Helper with implemented 
   createResolvingOobChannel (#6923 
   ).
   - stub: Add 
   `ClientCallStreamObserver.disableAutoRequestWithInitial(int)` and 
   `ServerCallStreamObserver.disableAutoRequest()` that disables all automatic 
   inbound flow-control requests. These methods are intended to replace the 
   existing `CallStreamObserver.disableAutoInboundFlowControl()`. There may 
   still be some tweaks to the API, so `disableAutoInboundFlowControl()` is 
   not yet deprecated
   - inprocess,core: add ability to pass status cause to client (#6968 
   ). The new API is added to 
   `InprocessChannelBuilder` to show stacktrace from transport when an error 
   happens in tests.
   - netty: support setting options of boss in NettyServer (#6947 
   ). Adds a new API on 
   `NettyServerBuilder` to allow passing channel options for the boss ELG.


*Bug Fixes*

   - okhttp: use new APIs to configure TLS in Android (roll forward of #6959 
   ) (#6960 
   ). Starting from Android 
   10, there is a new set of public APIs for configuring TLS, where we were 
   previously invoking hidden methods in SSLSocket. Some of those hidden 
   methods are no longer allowed (will be removed in the future) in Android 
   11. We migrate to use public APIs whenever possible.
   - netty: Using classloader to isolate grpc without isolating netty can 
   cause exceptions when creating netty channel/server is fixed (#7048 
   ).
   - api, core, services: make ProtoReflectionService interceptor 
   compatible (#6967 ). 
   Previously intercepting the ProtoReflectionService breaks the internal hack 
   of passing the server instance to the service. Now we change the way of how 
   it obtains the server instance so that applying interceptors to it doesn’t 
   break its functionality. This change also allows multiple servers to use a 
   shared ProtoReflectionService instance.
   - netty: Reduce race window size between GOAWAY and new streams. This 
   should greatly reduce the number of calls that fail with errors similar to 
   “UNAVAILABLE: HTTP/2 error code: NO_ERROR Received Goaway.” Although note 
   that these errors have multiple sources, and it only addresses one of them
   - core: Delay transport shutdown when changing a subchannel’s addresses. 
   This should prevent users from seeing errors saying “UNAVAILABLE: 
   InternalSubchannel closed transport due to address change,” which should 
   have already been rare


*Documentation*

   - For Java 9+ users, we now recommend using 
   `org.apache.tomcat:annotations-api` for the `Generated` annotation instead 
   of `javax.annotation:javax.annotation-api`, as it has a more appropriate 
   license
   - SECURITY.md: add instruction for disabling Conscrypt's default 
   TrustManager (#6962 ). By 
   default, Conscrypt delegates hostname verification to the platform's 
   default HostNameVerifier, which in OpenJDK is a deny-all implementation. 
   You can configure the Conscrypt provider to not use its TrustManager.


*Dependencies*

   - Starting from this version, some transitive dependencies of gRPC 
   artifacts are changed from compile scope to runtime scope. Users may 
   experience their application can not rebuild once the gRPC version is 
   upgraded, because some other component of the project may require a 
   dependency that is no longer transitively provided by gRPC artifacts at 
   compile time; and if that happens, users should explicitly add that 
   dependency for the other component. This change does not affect running the 
   application at runtime.
   - Bumped protobuf to 3.12.0


*Examples*

   - Deleted example-kotlin (#6936 
   ). grpc-kotlin 
    was officially released and 
   examples can be found in its own repository.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, sen

[grpc-io] A29: xDS-Based Security for gRPC Clients and Servers

['sanjay...@google.com' via grpc.io]

Hello,

I have created a PR https://github.com/grpc/proposal/pull/184 for 
"xDS-Based Security for gRPC Clients and Servers" which describes adding 
transport security (TLS or mTLS) to xDS-orchestrated gRPC connections. Note 
that xDS support to gRPC (client side) was already described in A27: 
xDS-Based Global Load Balancing 

.

Pls review and comment.

Sanjay

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/e23de72b-c132-416c-8944-58f1365b09a1n%40googlegroups.com.

Re: [grpc-io] Re: Problems in wrting a client interceptor for python

['Lidi Zheng' via grpc.io]

One example of how to implement the grpc.Call interface is to composite the
original returned object (_Rendezvous) to a new class with the logic you
want to add:
https://github.com/googleads/google-ads-python/blob/ab71f5286e66b402125eafa5dd9db4f4c37b4806/google/ads/google_ads/interceptors/exception_interceptor.py#L29

On Mon, Jun 8, 2020 at 12:17 AM  wrote:

> Also, `grpc._channel._Rendezvous` is a private class. It makes me nervous
> to inherit.
>
> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/bf23e779-3219-448f-9d90-e7cae112e957o%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/CAMC1%3DjdawT0s%3DPdFVPz9uYMC_LPq4N%2BiGrTmv9%3Dwt61eDPJE7Q%40mail.gmail.com.

Re: [grpc-io] Re: Any C++ example for AsyncStreaming Client?

[anassayedmain]

it does'nt involve streaming. 

On Monday, June 8, 2020 at 9:05:48 PM UTC+5:30, Patrice Chalin wrote:
>
> Hi, Have you tried the Asynchronous-API tutorial linked to on the C++ 
> languade page: 
> https://grpc.io/docs/languages/cpp/?
>
> On Sat, Jun 6, 2020 at 06:38 > wrote:
>
>> Hi, I am new to this forum. I have some issues implementing client side 
>> streaming. Lack of ready to run example on the grpc website or other 
>> sources forced me to write one on my own, but facing alot of issues. Were 
>> you able to accomplish the client side Asynchronous Streaming. Please reply 
>> as and when feasible. 
>>
>> On Thursday, April 27, 2017 at 1:10:34 AM UTC+5:30, Anirudh Kasturi wrote:
>>>
>>>
>>> Any updates on this? 
>>> On Thursday, April 13, 2017 at 11:25:06 AM UTC-7, Anirudh Kasturi wrote:

 Hello folks,

 Can you please give me pointers to an example that has an 
 AsyncStreaming Client?  

 Also, when the client is streaming data to the server, we will be 
 basically streaming multiple messages.  Is there a default timeout when 
 the 
 channel sees no more messages for a certain amount of time so that we can 
 shut it down?

 I would like to understand the state machine of the client async 
 streamin.  How does the client keeps streaming messages to the server and 
 when does it go to the FINISH state?  For each message the client sends 
 the 
 server has a response.  In that case is it better to use pure async or 
 asycn streaming?

 Best,
 Anirudh

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "grpc.io" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to grp...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/grpc-io/9d79a739-465a-487d-b369-ab622b39a136o%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/1c25e2ca-a273-4c25-b572-96657ecb9d6bo%40googlegroups.com.

Re: [grpc-io] Re: Any C++ example for AsyncStreaming Client?

[Patrice Chalin]

Hi, Have you tried the Asynchronous-API tutorial linked to on the C++
languade page:
https://grpc.io/docs/languages/cpp/?

On Sat, Jun 6, 2020 at 06:38  wrote:

> Hi, I am new to this forum. I have some issues implementing client side
> streaming. Lack of ready to run example on the grpc website or other
> sources forced me to write one on my own, but facing alot of issues. Were
> you able to accomplish the client side Asynchronous Streaming. Please reply
> as and when feasible.
>
> On Thursday, April 27, 2017 at 1:10:34 AM UTC+5:30, Anirudh Kasturi wrote:
>>
>>
>> Any updates on this?
>> On Thursday, April 13, 2017 at 11:25:06 AM UTC-7, Anirudh Kasturi wrote:
>>>
>>> Hello folks,
>>>
>>> Can you please give me pointers to an example that has an AsyncStreaming
>>> Client?
>>>
>>> Also, when the client is streaming data to the server, we will be
>>> basically streaming multiple messages.  Is there a default timeout when the
>>> channel sees no more messages for a certain amount of time so that we can
>>> shut it down?
>>>
>>> I would like to understand the state machine of the client async
>>> streamin.  How does the client keeps streaming messages to the server and
>>> when does it go to the FINISH state?  For each message the client sends the
>>> server has a response.  In that case is it better to use pure async or
>>> asycn streaming?
>>>
>>> Best,
>>> Anirudh
>>>
>> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/9d79a739-465a-487d-b369-ab622b39a136o%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/CAGzN0bYt861SkmYDr9W0NVx1xQWoFmU6GYpMsPx2c4BjTSCoJw%40mail.gmail.com.

Re: [grpc-io] Re: Any C++ example for AsyncStreaming Client?

[anassayedmain]

Thanks for the quick reply. The link you mentioned has given examples for 
bidi sync streaming and not bidi-asyn-streaming.

>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/0171e177-6e6d-4afd-9c1c-de28887a9adbo%40googlegroups.com.

Re: [grpc-io] Re: Any C++ example for AsyncStreaming Client?

['Mya Pitzeruse' via grpc.io]

The route_guide example often includes examples for all api call types.

https://github.com/grpc/grpc/tree/master/examples/cpp/route_guide

On Sat, Jun 6, 2020 at 5:38 AM  wrote:

> Hi, I am new to this forum. I have some issues implementing client side
> streaming. Lack of ready to run example on the grpc website or other
> sources forced me to write one on my own, but facing alot of issues. Were
> you able to accomplish the client side Asynchronous Streaming. Please reply
> as and when feasible.
>
> On Thursday, April 27, 2017 at 1:10:34 AM UTC+5:30, Anirudh Kasturi wrote:
>>
>>
>> Any updates on this?
>> On Thursday, April 13, 2017 at 11:25:06 AM UTC-7, Anirudh Kasturi wrote:
>>>
>>> Hello folks,
>>>
>>> Can you please give me pointers to an example that has an AsyncStreaming
>>> Client?
>>>
>>> Also, when the client is streaming data to the server, we will be
>>> basically streaming multiple messages.  Is there a default timeout when the
>>> channel sees no more messages for a certain amount of time so that we can
>>> shut it down?
>>>
>>> I would like to understand the state machine of the client async
>>> streamin.  How does the client keeps streaming messages to the server and
>>> when does it go to the FINISH state?  For each message the client sends the
>>> server has a response.  In that case is it better to use pure async or
>>> asycn streaming?
>>>
>>> Best,
>>> Anirudh
>>>
>> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/9d79a739-465a-487d-b369-ab622b39a136o%40googlegroups.com
> 
> .
>


-- 

Mya Pitzeruse

Principal Software Engineer - Service Infrastructure

Gender Pronouns: She, Her, Hers

mjp...@indeed.com


Indeed - We help people get jobs.

Indeed.com 

Facebook   |  Twitter
  |  Instagram


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

[grpc-io] Re: compiling grpcio for FreeBSD 8.4

[Phani B]

Please note that this is on FreeBSD8.4 itself. There is no 
cross-compilation involved.

On Monday, 8 June 2020 15:33:05 UTC+5:30, Phani B wrote:
>
> Using GRPC_PYTHON_BUILD_WITH_CYTHON=1 CC=clang CXX=clang++ python setup.py 
> install
>
> I have managed to get the compiler to invoke the correct files. 
>
> However, things again don't work with the following error.  Please note 
> that the compilation happens with -stdlib=libc++.
>
> clang -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -DNDEBUG -O2 
> -pipe -fno-strict-aliasing -fPIC -DOPENSSL_NO_ASM=1 -D_WIN32_WINNT=1536 
> -DGPR_BACKWARDS_COMPATIBILITY_MODE=1 -DHAVE_CONFIG_H=1 
> -DGRPC_ENABLE_FORK_SUPPORT=1 -Isrc/python/grpcio -Iinclude -I. 
> -Ithird_party/abseil-cpp -Ithird_party/address_sorting/include 
> -Ithird_party/cares -Ithird_party/cares/cares 
> -Ithird_party/cares/config_freebsd 
> -Ithird_party/boringssl-with-bazel/src/include -Ithird_party/upb 
> -Isrc/core/ext/upb-generated -Ithird_party/zlib 
> -I/usr/local/include/python2.7 -c src/python/grpcio/grpc/_cython/cygrpc.cpp 
> -o 
> python_build/temp.freebsd-8.4-RELEASE-amd64-2.7/src/python/grpcio/grpc/_cython/cygrpc.o
>  
> -std=c++11 -stdlib=libc++ -pthread
>
> *src/python/grpcio/grpc/_cython/cygrpc.cpp:1547:10: **fatal error: **'ios' 
> file not found*
>
> #include "ios"
>
> Any help will be appreciated.
>
>
> On Saturday, 30 May 2020 22:43:31 UTC+5:30, Phani B wrote:
>>
>> Another thing I have tried is installing clang 3.2 on freeBSD 8.4 itself 
>> ( this has c++11 support) and try compiling GRPCIO.
>> However, I am again getting into compilation issues.  
>>
>> building 'grpc._cython.cygrpc' extension
>>
>> clang -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -DNDEBUG -O2 
>> -pipe -fno-strict-aliasing -fPIC -DOPENSSL_NO_ASM=1 -D_WIN32_WINNT=1536 
>> -DGPR_BACKWARDS_COMPATIBILITY_MODE=1 -DHAVE_CONFIG_H=1 
>> -DGRPC_ENABLE_FORK_SUPPORT=1 -Isrc/python/grpcio -Iinclude -I. 
>> -Ithird_party/abseil-cpp -Ithird_party/address_sorting/include 
>> -Ithird_party/cares -Ithird_party/cares/cares 
>> -Ithird_party/cares/config_freebsd 
>> -Ithird_party/boringssl-with-bazel/src/include -Ithird_party/upb 
>> -Isrc/core/ext/upb-generated -Ithird_party/zlib 
>> -I/usr/local/include/python2.7 -c src/python/grpcio/grpc/_cython/cygrpc.c 
>> -o 
>> python_build/temp.freebsd-8.4-RELEASE-amd64-2.7/src/python/grpcio/grpc/_cython/cygrpc.o
>>  
>> -pthread
>>
>> clang: error: no such file or directory: 
>> 'src/python/grpcio/grpc/_cython/cygrpc.c'
>>
>> clang: error: no input files
>>
>>
>> I am expecting cygrpc.cpp to be compiled instead here.
>>
>>
>> On Wednesday, 27 May 2020 19:42:29 UTC+5:30, Phani B wrote:
>>>
>>> Can someone 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/e609ee94-b016-42de-90c7-f35979403ca3o%40googlegroups.com.

[grpc-io] Re: compiling grpcio for FreeBSD 8.4

[Phani B]

Using GRPC_PYTHON_BUILD_WITH_CYTHON=1 CC=clang CXX=clang++ python setup.py 
install

I have managed to get the compiler to invoke the correct files. 

However, things again don't work with the following error.  Please note 
that the compilation happens with -stdlib=libc++.

clang -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -DNDEBUG -O2 
-pipe -fno-strict-aliasing -fPIC -DOPENSSL_NO_ASM=1 -D_WIN32_WINNT=1536 
-DGPR_BACKWARDS_COMPATIBILITY_MODE=1 -DHAVE_CONFIG_H=1 
-DGRPC_ENABLE_FORK_SUPPORT=1 -Isrc/python/grpcio -Iinclude -I. 
-Ithird_party/abseil-cpp -Ithird_party/address_sorting/include 
-Ithird_party/cares -Ithird_party/cares/cares 
-Ithird_party/cares/config_freebsd 
-Ithird_party/boringssl-with-bazel/src/include -Ithird_party/upb 
-Isrc/core/ext/upb-generated -Ithird_party/zlib 
-I/usr/local/include/python2.7 -c src/python/grpcio/grpc/_cython/cygrpc.cpp 
-o 
python_build/temp.freebsd-8.4-RELEASE-amd64-2.7/src/python/grpcio/grpc/_cython/cygrpc.o
 
-std=c++11 -stdlib=libc++ -pthread

*src/python/grpcio/grpc/_cython/cygrpc.cpp:1547:10: **fatal error: **'ios' 
file not found*

#include "ios"

Any help will be appreciated.


On Saturday, 30 May 2020 22:43:31 UTC+5:30, Phani B wrote:
>
> Another thing I have tried is installing clang 3.2 on freeBSD 8.4 itself ( 
> this has c++11 support) and try compiling GRPCIO.
> However, I am again getting into compilation issues.  
>
> building 'grpc._cython.cygrpc' extension
>
> clang -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -DNDEBUG -O2 
> -pipe -fno-strict-aliasing -fPIC -DOPENSSL_NO_ASM=1 -D_WIN32_WINNT=1536 
> -DGPR_BACKWARDS_COMPATIBILITY_MODE=1 -DHAVE_CONFIG_H=1 
> -DGRPC_ENABLE_FORK_SUPPORT=1 -Isrc/python/grpcio -Iinclude -I. 
> -Ithird_party/abseil-cpp -Ithird_party/address_sorting/include 
> -Ithird_party/cares -Ithird_party/cares/cares 
> -Ithird_party/cares/config_freebsd 
> -Ithird_party/boringssl-with-bazel/src/include -Ithird_party/upb 
> -Isrc/core/ext/upb-generated -Ithird_party/zlib 
> -I/usr/local/include/python2.7 -c src/python/grpcio/grpc/_cython/cygrpc.c 
> -o 
> python_build/temp.freebsd-8.4-RELEASE-amd64-2.7/src/python/grpcio/grpc/_cython/cygrpc.o
>  
> -pthread
>
> clang: error: no such file or directory: 
> 'src/python/grpcio/grpc/_cython/cygrpc.c'
>
> clang: error: no input files
>
>
> I am expecting cygrpc.cpp to be compiled instead here.
>
>
> On Wednesday, 27 May 2020 19:42:29 UTC+5:30, Phani B wrote:
>>
>> Can someone 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/49fb20cd-a5fb-45d7-b461-b871f721005fo%40googlegroups.com.

[grpc-io] unable to compile grpc services using eclipse

[chetan . hck]

Hi all,

I have installed Protobuf on my host system and also grpc is installed

by using the proto file i am able to generate four files.

SimulatorServices.grpc.pb.cc
SimulatorServices.grpc.pb.h
SimulatorServices.pb.cc
SimulatorServices.pb.cc

but after compiling on the eclipse am getting this error. 
*../grpc/cpp/CommandServices/SimulatorServices.pb.h:10:10: fatal error: 
google/protobuf/port_def.inc: No such file or directory*

the cross compiler which i have used is *aarch64-linux-gnu-g++ for c++ and 
aarch64-linux-gnu-gcc for c*

*and the protoc version is **libprotoc 3.11.2*

can anyone please suggest on 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/049c2f2a-181a-4a80-8729-cd45e8409b2do%40googlegroups.com.

[grpc-io] Re: Problems in wrting a client interceptor for python

[cyc19921205]

Also, `grpc._channel._Rendezvous` is a private class. It makes me nervous 
to inherit.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/bf23e779-3219-448f-9d90-e7cae112e957o%40googlegroups.com.

Re: [grpc-io] Re: Getting/setting metadata in Python

[cyc19921205]

It seems that I'm getting OT on this thread. I've created a new one 
.

On Saturday, June 6, 2020 at 2:53:05 AM UTC+8, Lidi Zheng wrote:
>
> Your observation is right that if an interceptor returns a generator 
> instead of a grpc.Call object, downstream applications will lose access to 
> initial_metadata, trailing_metadata, etc..
>
> However, in the API reference [1], the streaming interceptors define the 
> return value as:
>
> > An object that is both a Call for the RPC and an iterator of 
> response values. Drawing response values from the returned Call-iterator 
> may raise RpcError indicating termination of the RPC with non-OK status.
>
> So, returning a generator without wrapping it as grpc.Call is not fully 
> supported. Given that, this support can be implementWe always welcome 
> contributors.
>
> [1] 
> https://grpc.github.io/grpc/python/grpc.html#grpc.StreamStreamClientInterceptor
>
> 
>
> On Fri, Jun 5, 2020 at 3:16 AM > wrote:
>
>> It doesn't work if an interceptor intercepts the responses.
>> Considering there is such an interceptor:
>> def wrapper(iterator):
>>   for entry in iterator:
>> yield entry
>> class MyInterceptor(grpc.StreamStreamClientInterceptor):
>>   def intercept_stream_stream(self, continuation, client_call_details, 
>> request_iterator):
>> return wrapper(continuation(client_call_details, request_iterator))
>> Well I know I could delegate a method `initial_metadata` to the original 
>> iterator, but unfortunately, I've seen many interceptors written in the way 
>> above, causing that I couldn't retrieve the initial metadata from last 
>> interceptor.
>> Any idea?
>>
>> 在 2016年4月6日星期三 UTC+8上午9:08:36，Nathaniel Manista写道：
>>>
>>> On Tue, Apr 5, 2016 at 9:58 AM, Tang Weiyu  wrote:
>>>
 Definition of rpc:
   rpc telemetrySubscribe(SubscriptionRequest) returns (stream 
 OpenConfigData) {}

>>>
>>> What's important here is that the RPC is response-streaming: it will 
>>> return zero, or one, or many more responses.
>>>
>>> How to get metadata from client side for streaming type of rpc call?

 On Mon, Apr 4, 2016 at 5:15 PM, Tang Weiyu  wrote:

> Thanks Nathaniel, unfortunately the returned response don't have those 
> 2 methods, though I did get the returned response in the form of stream 
> Type defined in proto file RCP.
> Anything missing here?
>
> for data,call in stub.Subscribe(sub_req, _TIMEOUT_SECONDS):
>   metadata = data.initial_metadata()
>

>>> Unpacking the iterator returned by your RPC invocation appears to be a 
>>> mistake here. I suspect that this should be something like:
>>>
>>> my_response_iterator = stub.Subscribe(sub_req, _TIMEOUT_SECONDS)
>>> my_initial_metadata = my_response_iterator.initial_metadata()
>>> for my_response in my_response_iterator:
>>>   
>>> my_terminal_metadata = my_response_iterator.terminal_metadata()
>>>
>>> Again, the critical part is that the RPC is response-streaming - the 
>>> code for a response-unary RPC would look very different.
>>> -N
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "grpc.io" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to grp...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/grpc-io/e93d5c60-693c-4790-b107-8a851f42df9fo%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/cefd0dad-ae11-4441-8c19-0d51a909aaa9o%40googlegroups.com.

[grpc-io] Problems in wrting a client interceptor for python

[cyc19921205]

I'm now working on a feature that needs server headers in a client 
interceptor. Unfortunately, I see a previous interceptor implemented like 
this:
def wrapper(iterator):
  for entry in iterator:
yield entry
class MyInterceptor(grpc.StreamStreamClientInterceptor):
  def intercept_stream_stream(self, continuation, client_call_details, 
request_iterator):
return wrapper(continuation(client_call_details, request_iterator))
The returned object is a bare iterator so that I cannot use 
`response.initial_metadata` to get the headers.

I'm considering three ways to retain the metadata:
1. Delegate last response and do my job in the delegate class.
2. Override `Rendezvous` classes and make new ones to return. (It may lose 
changes made in previous interceptors.)
3. Monkey patch last response. (It cannot patch magic methods)

So the the only clean way is to delegate the response. 
However, the delegation looks ugly, because the class has a dozen of 
methods to delegate.
Is there a clean and beautiful way to do the job?

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/12f15f6e-4546-4214-b004-b0dc94a7da68o%40googlegroups.com.