[grpc-io] Re: [Grpc Python] Tests - intercept request

['Lidi Zheng' via grpc.io]

For implementing the testing interceptor, you might find this example 
useful: 
https://github.com/grpc/grpc/tree/master/examples/python/interceptors/default_value,
 
which injects default response value.

Alternatively, you could create a fake server instead. This will ensure you 
are only testing the intended parts of your service.

On Friday, June 3, 2022 at 5:47:26 AM UTC-7 Fabien wrote:

> Hi all,
>
> I am currently working on writing tests to my service implemented with 
> grpc python - using grpc_testing package.
>
> Everything has been quite smooth until now, using the inovke methods and 
> so on which works very well.
>
> However i'm now having a hard time : one of my service - let's call it 
> service 1 -  has a method which call another service - service 2 -, the 
> current implementation create the stub channel directly in the method from 
> service 1 with a given ip and port.
> As such, I would like in my tests for this method (in service 1) to 
> intercept every request adressed to service 2 (could it be done 
> independently of any ip / port given in the real implementation ?) and 
> return a mock value when necessary.
>
> So far here is how i see things :
>
>   - Set up step -
>
>1. Register service 1 with grpc_testing.server_from_dictionary
>2. Create a mock for service 2 
>
>  - When testing the method calling service 2 
>
>1. Register service 2 mock to intercept requests
>2. Invoke_unary_unay
>3. Service 2 return the mock value
>4. Collect result of method in service 1
>
> Points 1 and 3 from part 2 are what I am struggling with.
>
> I have seen the examples in 
> https://github.com/grpc/grpc/tree/master/src/python/grpcio_tests/tests/testing
>  
> and the client test is what I found to be the more interesting for the 
> given points, but is not consistent with my current implementation.
> I nonetheless would like to know if any of you have any tip on this please 
> ?
>
> Thank you in advance !
>
> Sincerly,
>

-- 
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/97d38b64-58af-4ae1-a2e2-0437e8bc4099n%40googlegroups.com.

[grpc-io] Re: Calling gRPC method in pytest

['Lidi Zheng' via grpc.io]

Can you provide a reproduce case and post the bug on GitHub grpc/grpc repo?

On Tuesday, May 31, 2022 at 9:37:17 AM UTC-7 jason@stormfish-sci.com 
wrote:

> BTW the MockObject inherits users_grpc.grpc.ServicerContext.
>
> On Tuesday, May 31, 2022 at 11:04:16 AM UTC-4 Jason Hoppes wrote:
>
>> I have a method AddUser in my gRPC interface. I am trying to test using 
>> pytest. I created a mock Context.
>>
>> The generated code creates the signature:
>>
>> def AddUser(self, request, context)
>>
>> When I call this with the MockContext object I get the error:
>>
>> TypeError: unsupported operand type(s) for +: 'float' and 'MockContext'
>>
>> For s & g I added the __add__ method to my context object and returned a 
>> float. I still got the same error.
>>
>> Could someone please help me so,ve this problem?
>>
>> 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/49d5ab14-4202-451c-bbe8-9da737274a86n%40googlegroups.com.

[grpc-io] Re: GOAWAY recieved

['Lidi Zheng' via grpc.io]

It would help if you can provide a repro case.

On Tuesday, May 31, 2022 at 5:56:02 AM UTC-7 f.ban...@gmail.com wrote:

> Hello,
>
> I have received ""error" :14 UNAVAILABLE : GOAWAY received" while testing 
> my server in Bloorpc. Any idea about the reason will be appreciated.
>
> 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/4c6d1c0e-4349-4269-bea9-bf1a981acf13n%40googlegroups.com.

[grpc-io] Re: Access grpc

['Lidi Zheng' via grpc.io]

You can try out the examples on http://grpc.io to start a gRPC server and 
connect a gRPC client to the serving port.

On Sunday, May 29, 2022 at 6:16:45 PM UTC-7 nani...@gmail.com wrote:

> Hi Team ,
>
> Good Morning 
>
> Just want to check , my gRPC- server  application is running in Kubernetes 
> and  exposed ports as well . now we  access the client from my local system 
> with in the same network .
>
> if yes what are  the steps we need to take care. 
>
>
>
> Thanks 
> Prashanth T 

-- 
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/2aefbfc5-a171-4cd5-8de3-43b2a82433f9n%40googlegroups.com.

[grpc-io] Re: How to do server-side backpressure?

['Lidi Zheng' via grpc.io]

Hi,

It helps to adopt streaming calls. gRPC C++ server will only cache 1 
message and apply flow control on this stream. For an existing application, 
this could mean compacting multiple service methods into one.

If above is not possible, you can consider to tune channel args 
(https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/grpc_types.h):

1. Limit the concurrent streams via `grpc.max_concurrent_streams`
2. Limit the per stream buffer size via `GRPC_ARG_HTTP2_WRITE_BUFFER_SIZE


On Saturday, May 28, 2022 at 8:54:11 AM UTC-7 wlx6...@gmail.com wrote:

> Hi everyone!
>
> I just find that in C++, when using AsyncService, even if I don't request 
> a new request, gRPC will still read data from the network. This caused a 
> huge memory usage in my system.
>
> Detailed Scenario:
>
> I have a client that will send a lot of requests to the server.
>
> On the server-side, I didn't request any requests. The server blocked in 
> cq_->Next(, ) but was kept consuming memory. Caused an OOM in my 
> system.
>
> So my question is how to prevent the server from reading data from the 
> network when I don't request a new request? i.e. how to do server-side 
> backpressure so I can save the memory??
>
> Could anyone help me? 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/c0b01c89-a7c6-441d-92ef-f2706555e797n%40googlegroups.com.

[grpc-io] Re: How to generate a single python file from several proto files

['Lidi Zheng' via grpc.io]

Replied in the SO post.

On Monday, March 14, 2022 at 1:38:09 PM UTC-7 tres@gmail.com wrote:

> Hi.
>
> I have a project with a jobmate about grpc. And my jobmate have chop the 
> big proto file in several files. Well, this is correct but I can generate 
> the correct python files.
>
> The proto directory is now as:
>
> $ tree proto/
> proto/
> ├── common
> │   └── request.proto
> ├── file
> │   ├── file.proto
> │   └── file_service.proto
> ├── job
> │   ├── job.proto
> │   └── job_service.proto
> ├── pool
> │   ├── pool.proto
> │   └── pool_service.proto
> └── worker
> ├── worker.proto
> └── worker_service.proto
> 5 directories, 9 files
>
> I put too this question in:
>
>
> https://stackoverflow.com/questions/71472265/how-to-generate-a-single-python-file-from-several-proto-files
>
> Thanks and regards.
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/8b3bab6c-2929-4823-9ed9-514074961188n%40googlegroups.com.

[grpc-io] Re: M1 wheels for gRPC Python

['Lidi Zheng' via grpc.io]

Hi Philipp,

Thanks for writing up the good summary about the challenges we have around 
Apple Silicon.

I don't have a solution. But I can contribute following info: Apple is 
introducing "Universal Binary" to bundle binaries for arm64 and x86_64 into 
1. Read more: 
https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary.

M1 users can try to use `arch -x86_64 ` to use x86_64 binaries as 
Apple intended. I manually validated that this workaround is functional.

We do realize that this workaround is not native to normal Python workflow. 
We will bump up the priority to ship M1-native wheels.


On Monday, March 7, 2022 at 1:37:49 PM UTC-8 Philipp Moritz wrote:

> Dear gRPC Maintainers,
>
> in my experience it is presently still very challenging to get gRPC for 
> Python
> working on Apple's M1 Platform ("Apple Silicon"). There have been various 
> user
> issues on github (see [1][2][3][4][5][6] for a partial collection of the 
> issues)
> regarding this, so I think many other members of the open source community
> are facing very similar challenges.
>
> This becomes increasingly more important as more open source projects are
> building on top of gRPC, and each of these projects is inheriting all the
> challenges around getting Python gRPC working on M1.
>
> The issues are mainly about compiling gRPC and its dependencies (including
> boringssl, zlib etc.) from the provided gRPC Python source distibutions. 
> One possibility
> to make this massively easier would be for Google/the gRPC team to provide 
> binary
> wheels for Python gRPC on M1 -- this would completely remove this set of 
> friction
> points for everybody. Currently there are lots of different workarounds 
> that all
> break in subtle and frustrating ways on different configurations.
>
> I'm specifically asking on behalf of the Ray project (
> https://github.com/ray-project/ray),
> currently we have to provide specialized instructions [7] to support M1 
> because there
> are no gRPC M1 wheels (we basically have to fall back on conda's binary 
> distribution,
> which forces everybody to use conda).
>
> You could improve the lives of everybody relying on Python gRPC on M1 
> greatly by
> shipping M1 gRPC wheels on pypi, so people won't need to worry about 
> getting a
> working gRPC distribution.
>
> Just wanted to get the discussion started and make sure this is on your 
> radar and
> check if there are plans for supporting it :)
>
> I'd also like to take this opportunity to thank you all for making a lot 
> of high quality
> open source software available (e.g. gRPC, absl, bazel, K8s, TensorFlow) 
> -- these are all
> great to use, extremely well engineered and very useful enhancements of the
> open source ecosystem!
>
> All the best and thanks for your help,
> Philipp.
>
> [1] https://github.com/grpc/grpc/issues/25993
> [2] https://github.com/grpc/grpc/issues/25082
> [3] https://github.com/grpc/grpc/issues/28449
> [4] https://github.com/grpc/grpc/issues/24846 (similar problems for Ruby)
> [5] https://github.com/grpc/grpc/issues/26155
> [6] https://github.com/grpc/grpc/issues/24390
> [7] 
> https://docs.ray.io/en/latest/installation.html?highlight=M1#m1-mac-apple-silicon-support
>

-- 
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/b0ed5d80-6c40-4af3-893b-ba435ae20c43n%40googlegroups.com.

[grpc-io] Re: Python gRPC: Can Reflection be used safely with async grpc server?

['Lidi Zheng' via grpc.io]

Yes, gRPC Reflection supports AsyncIO. It picks implementation based on the 
input server type.

On Tuesday, March 1, 2022 at 8:51:32 AM UTC-8 Lidi Zheng wrote:

> The code can be found here: 
> https://github.com/grpc/grpc/blob/master/src/python/grpcio_reflection/grpc_reflection/v1alpha/reflection.py
>
> On Tuesday, March 1, 2022 at 3:08:49 AM UTC-8 adria...@sky.uk wrote:
>
>> Hi
>>
>> Can gRPC Reflection be safely used by the `grpc.aio` implementation. I 
>> have added `reflection.enable_server_reflection()` to an async server, and 
>> it works, but am wondering if it has any known side effects, as it's not 
>> part of the `aio` package?
>>
>> Thanks
>>
>> Adrian
>>
>

-- 
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/d3067f46-2feb-4fac-8f57-f3f35c20b0ffn%40googlegroups.com.

[grpc-io] Re: Python gRPC: Can Reflection be used safely with async grpc server?

['Lidi Zheng' via grpc.io]

The code can be found 
here: 
https://github.com/grpc/grpc/blob/master/src/python/grpcio_reflection/grpc_reflection/v1alpha/reflection.py

On Tuesday, March 1, 2022 at 3:08:49 AM UTC-8 adria...@sky.uk wrote:

> Hi
>
> Can gRPC Reflection be safely used by the `grpc.aio` implementation. I 
> have added `reflection.enable_server_reflection()` to an async server, and 
> it works, but am wondering if it has any known side effects, as it's not 
> part of the `aio` package?
>
> Thanks
>
> Adrian
>

-- 
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/9ff5690e-6ffd-474a-b57f-a955b32fb09dn%40googlegroups.com.

[grpc-io] Re: Using the gRPC AsyncIO API in python

['Lidi Zheng' via grpc.io]

We only have unit tests at this point:

- Testing how to use the async generator and read/write API, or both: 
https://github.com/grpc/grpc/blob/6a10e41db75bd6074bf01a08d260365e44922f04/src/python/grpcio_tests/tests_aio/unit/server_test.py#L164
- A slightly more complex test server with streaming method: 
https://github.com/grpc/grpc/blob/6a10e41db75bd6074bf01a08d260365e44922f04/src/python/grpcio_tests/tests_aio/unit/_test_server.py#L95



On Friday, February 11, 2022 at 2:37:10 PM UTC-8 Mark Bearden wrote:

> Is there any available example of implementing the server side of an async 
> *bidirectional-streaming* service method, using grpc.aio?   If I followed 
> the link to the unit test correctly, then it only shows a client for the 
> call that is in python.   Looks like the code for the server side (
> *Grpc.Testing.TestService* class) is C#.
>
> On Wednesday, December 1, 2021 at 2:47:22 PM UTC-5 Lidi Zheng wrote:
>
>> Hi,
>>
>> Here is an unit test case using stream.write() and stream.read() to 
>> communicate in bidirectional streaming: 
>> https://github.com/grpc/grpc/blob/master/src/python/grpcio_tests/tests_aio/unit/channel_test.py#L180
>>
>> Sorry that we didn't have an example to demonstrate this usage.
>>
>> On Tuesday, November 30, 2021 at 11:46:26 AM UTC-8 n.me...@gmail.com 
>> wrote:
>>
>>> Hello,
>>> I apologize in advance if it is a dumb question, but I was wondering how 
>>> can I do something like stream.write() or stream.read() in bidirectional 
>>> streaming in python where I want to asynchronously call these.
>>>
>>> The official gRPC Python AsyncIO API documentation only has abstract 
>>> methods in the classes. Does this mean that I actually have to (override) 
>>> implement the methods myself? How do I actually get the context to 
>>> correctly configure a class like grpc.aio.StreamStreamCall() ? (Apologies 
>>> again if it is a dumb question, I'm a beginner to this and development in 
>>> general)
>>>
>>> I referred to these sources but couldn't find a direct answer-
>>> https://grpc.github.io/grpc/python/grpc_asyncio.html#overview
>>> https://github.com/grpc/grpc.io/issues/726#issuecomment-806234300
>>>
>>> https://stackoverflow.com/questions/67465629/grpc-python-server-to-client-communication-through-function-call
>>>
>>> https://pretagteam.com/question/how-do-i-handle-streaming-messages-with-python-grpc
>>> https://grpclib.readthedocs.io/en/latest/client.html
>>>
>>

-- 
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/a25c97b2-4242-4f55-bc63-33fcca8b60dfn%40googlegroups.com.

[grpc-io] Re: Can Python package `py-grpc-prometheus` be used with the Python gRPC AsyncIO version?

['Lidi Zheng' via grpc.io]

The interceptor API for AsyncIO is different than the normal interceptor 
API. AsyncIO requires the method signatures to pass on "async"-ness from 
function to function.

If there is an AsyncIO metrics library, it should be possible to integrate 
with gRPC AsyncIO. However, if there isn't, the metrics library is likely 
to be using transports (gRPC, HTTP). The IO from transport is blocking, and 
will be harder to integrate into the AsyncIO world.

On Monday, February 14, 2022 at 7:41:14 AM UTC-8 adria...@sky.uk wrote:

> We are converting existing Python gRPC services to the Python gRPC AsyncIO 
> version (1.43.1). We currently use the py-grpc-prometheus package to 
> collect/emit server and client metrics. This packages subclasses:
> ```
> class PromServerInterceptor(grpc.ServerInterceptor): 
>
> class PromClientInterceptor(grpc.UnaryUnaryClientInterceptor, 
> grpc.UnaryStreamClientInterceptor, grpc.StreamUnaryClientInterceptor, 
> grpc.StreamStreamClientInterceptor):
> ```
>  and uses a number of other gRPC package attributes, etc.
>
> The question is, are the blocking and asyncio classes 'compatible' when 
> used in this way? If not, any suggestions on alternative ways of collecting 
> server/client request/response metrics?
>
> 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/82935abc-e0ce-48e2-b319-e4d5a421d988n%40googlegroups.com.

Re: [grpc-io] Slow gRPC communication with large file in Python

['Lidi Zheng' via grpc.io]

Windows tends to have slower "localhost" transport comparing to Linux. 
Josh, can you share your deployment setup?

The answer in SO is also helpful, streaming calls perform better in terms 
of throughput.

On Tuesday, February 8, 2022 at 10:46:03 AM UTC-8 Richard Belleville wrote:

> Josh,
>
> I don't think I'm able to reproduce with your repo. I'm getting something 
> like 0.2s on my desktop:
>
> (venv) rbellevi@rbell:~/Dev/tmp/grpc_min$ python3 grpc_client.py 
> 0.28313207626342773s18506294 photons in 1008640 bins
> 0.14323067665100098s18506294 photons in 1008640 bins
> (venv) rbellevi@rbell:~/Dev/tmp/grpc_min$ python3 grpc_client.py 
> 0.23985695838928223s18506294 photons in 1008640 bins
> 0.13980460166931152s18506294 photons in 1008640 bins
>
> Also, your requirements.txt includes "grpc=1.0.0". I'm assuming this is 
> just an typo. I used "grpcio".
>
> Maybe try running cProfile to generate a profile of the repro on your 
> machine and sharing that here?
>
> On Tue, Feb 8, 2022 at 10:34 AM Josh Parks  wrote:
>
>> I'm trying to do a large array transfer (10-50MB) over gRPC in python and 
>> it's quite slow (5-10 seconds, both client and server on localhost). I've 
>> tried both streaming and unary requests, and they both seem to run slowly.
>>
>> For more details/conversation, here's the stackoveflow question: 
>> https://stackoverflow.com/questions/70993553/grpc-slow-serialization-on-large-dataset
>>
>> And for the minimum reproducible example: 
>> https://github.com/parksj10/grpc_min
>>
>> Any help/guidance much appreciated!!!
>>
>>
>> -- 
>> 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/b713e084-a3d9-46e3-aae2-8501164ca449n%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/38e794a0-bd37-4640-8fe5-e24e1eeca0e7n%40googlegroups.com.

Re: [grpc-io] client side load balancing in grpc python

['Lidi Zheng' via grpc.io]

Hi,

You are using the custom resolver API for Java. This API is available only 
in limited gRPC languages, like Java/Go, but not Core-based languages, like 
C++/Python/Ruby/C#/ObjC/PHP.

You may need to inject the candidate addresses to DNS backends. Many DNS 
providers / cloud providers offer this feature.

Locally, depending on the OS, there should be ways to define name -> IP 
resolutions, like /etc/hosts.


On Wednesday, February 2, 2022 at 10:40:44 AM UTC-8 Easwar Swaminathan 
wrote:

> You can find gRPC Python documentation here: 
> https://grpc.github.io/grpc/python/ and a basic tutorial here: 
> https://grpc.io/docs/languages/python/.
>
> [+Richard Belleville, +Lidi Zheng] for specific load balancing API in 
> Python.
>
> On Fri, Jan 28, 2022 at 4:52 AM animesh sharma  
> wrote:
>
>> Hi Team,
>>
>> I was trying to implement client side load balancing in gRPC. I know how 
>> to do it in Java but not able to find appropriate document describing how 
>> to do the same in python, below is my Java code.
>> ```
>> NameResolver.Factory nameResolverFactory = new 
>> MultiAddressNameResolverFactory( new InetSocketAddress("localhost", 1), 
>> new InetSocketAddress("localhost", 10001), new InetSocketAddress(
>> "localhost", 10002) ); ManagedChannel channel = 
>> ManagedChannelBuilder.forTarget("service") 
>> .nameResolverFactory(nameResolverFactory) .defaultLoadBalancingPolicy(
>> "round_robin") .usePlaintext() .build(); 
>>
>> ```
>>
>> In python I know how to connect to one server but not a list of gRPC 
>> servers
>> channel = grpc.insecure_channel('localhost:1') 
>>
>> can anyone kindly guide me or point me to a document on how to implement 
>> the same?
>>
>> Thanks,
>>
>> Animesh
>>
>> -- 
>> 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/4ce5e1e3-46cb-482a-829c-6e5c518e6762n%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/e8b9e388-0ad7-4089-9396-f79b38fc6d88n%40googlegroups.com.

Re: [grpc-io] Re: grpcio_testing code samples

['Lidi Zheng' via grpc.io]

The grpc-testing package is for mocking the services. It can intercept 
messages, inject logic, alter timestamp.

How to write tests is a programming philosophy question. In most of the 
gRPC Python tests, we try to use "end2end" style tests, conduct tests only 
using the public API.

On Saturday, December 4, 2021 at 12:53:56 PM UTC-8 M T wrote:

> One thing I just noticed that I didn't include in my original request: I'm 
> looking for examples on how to write tests for *python* grpc services & 
> clients.
>
> Thanks for getting back to me - but unfortunately, neither link helps:
>
> * https://github.com/grpc/grpc/tree/master/examples only contains usage 
> examples of actually implementing services / clients, but not about  how to 
> test them
> * https://github.com/grpc/grpc/tree/master/test only contains a bunch of 
> .cc files, which don't help in my case, since I'm looking for python unit 
> tests, and the only python-related files I could find in there where about 
> testing the generation of the wheels that are required for the python 
> grpcio packages
>
> When I said "the documentation only lists what classes / methods exist, 
> but not how to use them", I was talking about this: 
> https://grpc.github.io/grpc/python/grpc_testing.html - and this is quite 
> cryptic to a newbie like me. A simple example (e.g. unit tests for the 
> hello world example) would be enough to get started, but the way it is, I 
> can't really make sense of any of these classes. And googling also didn't 
> provide me with any kind of guidance on the python grpc test classes. A 
> possible place to add such an example would be 
> https://grpc.io/docs/languages/python/basics/, I guess, which contains 
> the hello world example for python.
>
> On Wed, Dec 1, 2021 at 8:10 PM 'yas...@google.com' via grpc.io <
> grp...@googlegroups.com> wrote:
>
>> Thank you for the feedback! Do the examples in 
>> https://github.com/grpc/grpc/tree/master/examples and 
>> https://github.com/grpc/grpc/tree/master/test help?
>>
>> On Tuesday, November 16, 2021 at 6:32:13 AM UTC-8 M T wrote:
>>
>>> Hi all,
>>>
>>> I'm just starting to get into grpc, and was wondering about tests. The 
>>> documentation of the testing package only lists what classes etc. are 
>>> available, but not really how to use them - would it be possible to add 
>>> small testing examples to the general code examples, to help people 
>>> starting out?
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "grpc.io" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/grpc-io/pNIulgyXSQ0/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/a787b200-e683-4a48-9d90-f1da02430f41n%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/eb364618-65c1-42c6-8950-a36412d62623n%40googlegroups.com.

[grpc-io] Re: python gRPC server graceful shutdown

['Lidi Zheng' via grpc.io]

Based on the behavior observed, there might be an issue with the signal 
handler registration. One common problem for Python signal handling is that 
the signal handler can only be hooked on the main thread, otherwise, it 
won't take effect.

Feel free to post a feature request to grpc/grpc GitHub repo, if you feel a 
certain change would benefit.

On Saturday, January 15, 2022 at 7:05:06 PM UTC-8 amits...@gmail.com wrote:

> I don't have a direct answer for your question, but if I would to 
> investigate what may be going on, i would try running the server outside of 
> Kubernetes and container. I would run it on a local system, send the 
> SIGTERM signal, and see what happens first.
>
> On Saturday, January 15, 2022 at 7:29:03 AM UTC+11 M T wrote:
>
>> Pressed the wrong button when I tried to edit the code example... here's 
>> the correct (simplified) example:
>>
>>
>> def handle_sigterm(*_: Any) -> None :
>> """Shutdown gracefully."""
>>   done_event = server.stop(30)
>>   done_event.wait(30)
>>   print('Stop complete.')
>>
>> server = grpc.server(
>> futures.ThreadPoolExecutor(max_workers = options['max_workers']),
>> )
>> add_Servicer_to_server(service, server)
>> server.add_insecure_port(options['address'])
>> server.start()
>> signal(SIGTERM, handle_sigterm)
>> server.wait_for_termination()
>>
>> I'm deploying my service through kubernetes, which stops pods by first 
>> sending a SIGTERM event, and, if the pod is still alive after a timeout, it 
>> kills it using SIGKILL.
>>
>>
>> The behavior that I witness:
>> * the time it takes for the pod to terminate looks a lot like it's using 
>> the full 30s that kubernetes gives it = it ends up getting killed by SIGKILL
>> * the log for the stop of the service inside the SIGTERM handler never 
>> appears
>>
>>
>> So I think that one of following things might be happening here (that I 
>> can think of):
>>
>>
>> 1. the handler never gets called because the process gets killed before 
>> it gets to handle it
>> 2. the server takes so long to shut down, that kubernetes ends up killing 
>> it before it gets to logging the message
>> 3. the shutdown event doesn't get set even after the server is done 
>> shutting down, causing kubernetes to kill it without logging the message
>>
>>
>> I see that the official examples contain a asyncio example for graceful 
>> shutdown, can we maybe get something like for the regular, non-asyncio case
>>  (
>> https://github.com/lidizheng/grpc/tree/master/examples/python/helloworld
>> )?
>>
>> And for the long run: would it be possible to get something like 
>> wait_for_termination that is capable of handling graceful shutdown 
>> natively, without the developers having to add something on top of it?
>>
>> Thanks for your help!
>> On Friday, January 14, 2022 at 9:20:22 PM UTC+1 M T wrote:
>>
>>> Hi all,
>>>
>>> I'm currently trying to add some graceful shutdown logic into my gRPC 
>>> server, but it seems that my shutdown handler never gets called:
>>>
>>> def handle_sigterm(*_: Any) -> None :
>>> """Shutdown gracefully."""
>>>   done_event = server.stop(30)
>>>   done_event.wait(30)
>>>   self.stdout.write('Stop complete.')
>>>
>>> server = grpc.server(
>>> futures.ThreadPoolExecutor(max_workers = options['max_workers']),
>>> )
>>> add_
>>> server.add_insecure_port(options['address'])
>>> self.stdout.write(f'Starting gRPC server at {options["address"]}...')
>>> server.start()
>>> start_http_server(int(khaleesi_settings['MONITORING']['PORT']))
>>> signal(SIGTERM, handle_sigterm)
>>> self._log_server_state_event(
>>> action = Event.Action.ActionType.START,
>>> result = Event.Action.ResultType.SUCCESS,
>>> details = 'Server started successfully.'
>>> )
>>> server.wait_for_termination()
>>> except Exception as start_exception:
>>> self._log_server_state_event(
>>> action = Event.Action.ActionType.START,
>>> result = Event.Action.ResultType.ERROR,
>>> details = f'Server startup failed. {type(start_exception).__name__}: 
>>> {str(start_exception)}'
>>> )
>>> raise start_exception from None
>>>
>>

-- 
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/2563551c-4ed8-417b-b4de-03417bde06a6n%40googlegroups.com.

[grpc-io] Re: [python] How to add REST API support using google.api.http?

['Lidi Zheng' via grpc.io]

Hi,

The REST API annotation is not a native feature of gRPC. Using gRPC Python 
(based on the snippet) won't be able to spawn an HTTP/1.1 server with the 
given interface.

However, there are multiple projects that can handle the HTTP/1.1 and 
HTTP/2 (gRPC) translation for you. For example: 
https://github.com/grpc-ecosystem/grpc-gateway

On Friday, January 14, 2022 at 9:18:39 AM UTC-8 MAX IKON wrote:

> Can you please tell me how to add REST API support using 
> google.api.http?syntax 
> = "proto3";
> import "google/api/annotations.proto"; service TestService { rpc 
> Method(MethodRequest) returns (MethodResponse) { option (google.api.http) = 
> { post: "/api/v1/test" body: "*" }; } }
> What should be added here?
> server = grpc.server(futures.ThreadPoolExecutor(max_workers=10)) 
> stt_pb2_grpc.add_TestServiceServicer_to_server( TestService(), server ) 
> address = f"{host}:{port}" server.add_insecure_port(address) server.start() 
> server.wait_for_termination()
>

-- 
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/475df23f-a151-4791-be48-8374f49d483cn%40googlegroups.com.

[grpc-io] Re: gRPC Python - Mac M1 (arm64) - Issue running grpcio-tools

['Lidi Zheng' via grpc.io]

Yes, there is an issue tracking this 
bug: https://github.com/grpc/grpc/issues/28387.

So far, this issue only presents on Python 3.10.

On Thursday, January 13, 2022 at 10:22:32 PM UTC-8 amits...@gmail.com wrote:

> Hi all,
>
> I installed grpcio-tools using the poetry python packager using poetry
> add grpcio-tools. I have verified it's the same issue described below
> if I use pip directly.
>
> When trying to use grpcio-tools on Python 3.10 - Mac M1, I am running
> into this error when generating some Python code:
>
> % poetry run python -m grpc_tools.protoc --python_out=.
> --grpc_python_out=. user_sessions.proto
> Traceback (most recent call last):
> File 
> "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/runpy.py",
> line 196, in _run_module_as_main
> return _run_code(code, main_globals, None,
> File 
> "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/runpy.py",
> line 86, in _run_code
> exec(code, run_globals)
> File 
> "/Users/echorand/Library/Caches/pypoetry/virtualenvs/user-sessions-2yjUCcPI-py3.10/lib/python3.10/site-packages/grpc_tools/protoc.py",
> line 20, in 
> from grpc_tools import _protoc_compiler
> ImportError: 
> dlopen(/Users/echorand/Library/Caches/pypoetry/virtualenvs/user-sessions-2yjUCcPI-py3.10/lib/python3.10/site-packages/grpc_tools/_
> protoc_compiler.cpython-310-darwin.so,
> 0x0002): tried:
>
> '/Users/echorand/Library/Caches/pypoetry/virtualenvs/user-sessions-2yjUCcPI-py3.10/lib/python3.10/site-packages/grpc_tools/_
> protoc_compiler.cpython-310-darwin.so'
> (mach-o file, but is an incompatible architecture (have 'x86_64', need
> 'arm64e')), '/usr/lib/_protoc_compiler.cpython-310-darwin.so' (no such
> file)
>
> I tried this next:
>
> % arch -x86_64 poetry run python -m grpc_tools.protoc --proto_path .
> --python_out=. --grpc_python_out=. user_sessions.proto
>
> And that works. So, perhaps an issue with the universal binary wheel
> of grpcio-tools I am using and it's non compatibility with arm64?
>
> Thanks,
> Amit.
>

-- 
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/d9fa6e6f-1668-48f9-b6ad-5b8709f13823n%40googlegroups.com.

[grpc-io] Re: using custom executor for grpc client for handling requests and response.

['Lidi Zheng' via grpc.io]

Sorry, that's not supported by Python yet. We do have an ongoing work on 
EventEngine API (https://github.com/grpc/proposal/pull/245) that can cover 
this functionality in future.

On the other hand, you are free to spawn your threads with the Python 
thread pool, the gRPC channel is safe to be used in multiple threads.


On Tuesday, December 28, 2021 at 8:51:35 AM UTC-8 Deepu Varma wrote:

> Hii I have created grpc channel with host and load balancer here.
>
> 1)created channel
> self.channel = grpc.insecure_channel(
> self.host, options=[("grpc.lb_policy_name", "round_robin")]
> )
>
> 2)created stub
> self.blocking_stub = policy_pb2_grpc.ServiceStub(self.channel)
>
> and I have used this stub along with metadata and timeout with request 
> to call the service 
>
> My question here is how can I add executor with custom threads from 
> client side ?
>
> I have seen java code to use custom executor but how can we do in python ?
>
> 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/d8e03c8b-568d-4baa-ab19-3c1aeff88663n%40googlegroups.com.

[grpc-io] Re: BeagleBone Black GRPC

['Lidi Zheng' via grpc.io]

You may want to use the issue template on GitHub to describe the problem 
you are facing https://github.com/grpc/grpc/issues. (You file an issue 
instead.)

For example, actual log from cmake will be helpful.



On Sunday, December 26, 2021 at 12:00:37 AM UTC-8 Naresh P wrote:

> I am unable to install GRPC on BeagleBone Black 
> I am getting cmake issue,
> Can anyone please 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/d2f9e1f2-1556-4437-ba3b-df55450657ccn%40googlegroups.com.

[grpc-io] Re: google python-speech sample is broken on raspberry pi after grpcio 1.41.0

['Lidi Zheng' via grpc.io]

Hi Louie,

After 1.41, I'm not aware of a change that might require a newer glibc. 
Usually, pip will read the wheel's metadata and advice on if the given 
wheel will work or not on that platform.

For immediate fix, I would recommend using Raspberry Pi officially 
supported Python wheels: https://www.piwheels.org/project/grpcio/

glibc 2.33 is definitely too new. Can you open an issue on GitHub to track 
this problem? https://github.com/grpc/grpc/issues

Cheers,
Lidi Zheng

On Thursday, December 23, 2021 at 11:18:36 AM UTC-8 Louie wrote:

> Hi,
>
> okay i not sure i am sending this feedback to right group at google but 
> hopefully you can forward it to the group that maintains google cloud 
> python samples
> ( Leah Cole  @ google is the lead for google cloud python samples  you 
> could forward this to Leah)
>
> i am using this https://github.com/googleapis/python-speech  sample to 
> test google-cloud-speech on a raspberry pi running the latest buster os 
> version
>
> reproduce case
> -
> fetch github.com/googleapis/python-speech 
> open python-speech in pycharm
> create venv using python 3.7
> install google-cloud-speech  (this install grpcio 1.43.0)
> install pyaudio
> run python-speech/samples/microphone/transcribe_streaming_infinite.py  and 
> the following error appears:
>
> ImportError: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.33' not 
> found (required by /[prj 
> path]/python-speech-main/venv/lib/python3.7/site-packages/grpc/_cython/
> cygrpc.cpython-37m-arm-linux-gnueabihf.so)
>
>
> one fix
> --
> - uninstall grpcio 1.43
> - install grpcio 1.41
> - sample now works
>
>
> bottom line
> --
> the raspberry pi buster or bullseye os versions currently does use glibc 
> 2.33
>
> Louie Genduso
> Westfield, IN usa
>
>
>
>
>

-- 
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/69e48d96-c491-4c3e-b894-497a7941c3fbn%40googlegroups.com.

[grpc-io] Re: Issue with Google cloud logging in Django application running on a container

['Lidi Zheng' via grpc.io]

I saw a similar ask from another channel. I will copy the answer here, so 
hopefully it can be useful for more people.

Forking support document can be found at: 
https://github.com/grpc/grpc/blob/master/doc/fork_support.md. gRPC channels 
won't be able to be used across processes (well, no sockets can). I'm not 
certain what the Django-q forking mechanism is. You probably seeing the 
closed channel in the child process, that is expected. I would recommend to 
only create gRPC objects after forking. For example:

```py
### Before ###
channel = grpc.insecure_channel(...)
stub = foo_pb2.FooStub(channel)

def handler():
  response = stub.Bar(...)


### After ###
def handler():
  channel = grpc.insecure_channel(...)
  stub = foo_pb2.FooStub(channel)
  response = stub.Bar(...)
```

On Thursday, December 16, 2021 at 9:07:43 AM UTC-8 Abhijith R wrote:

> Hi All,
>
> I have an application running on a docker container hosted internally, 
> which uses cloud logging to log information to GCP. 
>
> The application and logging was working fine for few minutes the I saw a 
> SSL error similar to the one below.
>
> "E1004 21:08:52.855508502 45 ssl_transport_security.cc:523] Corruption 
> detected. "
> "E1004 21:08:52.855608271 45 ssl_transport_security.cc:499] 
> error:13fc:SSLroutines:OPENSSL_internal:SSLV3_ALERT_BAD_RECORD_MAC "
> "E1004 21:08:52.855621453 45 secure_endpoint.cc:205] Decryption error: 
> TSI_DATA_CORRUPTED "
>
> to fix this issue, I set the below env variables
> ENV GRPC_POLL_STRATEGY "epoll1"
> ENV GRPC_ENABLE_FORK_SUPPORT "1"
>
> This fixed the above error but now I see a new error as below:
> File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 498, 
> in grpc._cython.cygrpc.Channel.segregated_call
> File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 353, 
> in grpc._cython.cygrpc._segregated_call
> File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 357, 
> in grpc._cython.cygrpc._segregated_call
> ValueError: Cannot invoke RPC on closed channel!
>
> Can someone guide me on how to approach this problem.
>
> Thanks,
> Abhijith
>
>
>

-- 
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/9af61ef9-e8d0-44f6-9940-cc275b868f24n%40googlegroups.com.

[grpc-io] Re: Using the gRPC AsyncIO API in python

['Lidi Zheng' via grpc.io]

Hi,

Here is an unit test case using stream.write() and stream.read() to 
communicate in bidirectional streaming: 
https://github.com/grpc/grpc/blob/master/src/python/grpcio_tests/tests_aio/unit/channel_test.py#L180

Sorry that we didn't have an example to demonstrate this usage.

On Tuesday, November 30, 2021 at 11:46:26 AM UTC-8 n.me...@gmail.com wrote:

> Hello,
> I apologize in advance if it is a dumb question, but I was wondering how 
> can I do something like stream.write() or stream.read() in bidirectional 
> streaming in python where I want to asynchronously call these.
>
> The official gRPC Python AsyncIO API documentation only has abstract 
> methods in the classes. Does this mean that I actually have to (override) 
> implement the methods myself? How do I actually get the context to 
> correctly configure a class like grpc.aio.StreamStreamCall() ? (Apologies 
> again if it is a dumb question, I'm a beginner to this and development in 
> general)
>
> I referred to these sources but couldn't find a direct answer-
> https://grpc.github.io/grpc/python/grpc_asyncio.html#overview
> https://github.com/grpc/grpc.io/issues/726#issuecomment-806234300
>
> https://stackoverflow.com/questions/67465629/grpc-python-server-to-client-communication-through-function-call
>
> https://pretagteam.com/question/how-do-i-handle-streaming-messages-with-python-grpc
> https://grpclib.readthedocs.io/en/latest/client.html
>

-- 
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/b8b6df19-3401-492b-a044-35bc0d5279e3n%40googlegroups.com.

Re: [grpc-io] [Python] ServiceUnavailable: 503 DNS resolution failed for service in Windows

['Lidi Zheng' via grpc.io]

+Craig Tiller 

The logic around Windows name resolution is stable for years. By searching
the socket error 10109, I didn't find any more info:
https://docs.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2

Craig, since you wrote this module originally, if you have a second, can
you help to take a look at what this resolution error could mean?



On Wed, Oct 13, 2021 at 2:55 PM 'busu...@google.com' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hi,
>
> I'm posting on behalf of a user who raised this question in the the python
> library for Google Cloud Firestore. (original issue
>  with example
> code, stack traces).
>
> They are working in a Windows environment. Calls to the 
> *firestore.googleapis.com
> * endpoint through the gRPC client
> eventually result in this error:
>
> debug_error_string =
> "{"created":"@1632831473.22100","description":"Resolver transient
> failure","file":"src/core/ext/filters/client_channel/client_channel.cc","file_line":1356,"referenced_errors":[{"created":"@1632831473.22100","description":"DNS
> resolution failed for service: 
> firestore.googleapis.com","file":"src/core/ext/filters/client_channel/resolver/dns/native/dns_resolver.cc","file_line":202,"grpc_status":14,"referenced_errors":[{"created":"@1632831473.22100","description":"OS
> Error","file":"src/core/lib/iomgr/resolve_address_windows.cc","file_line":93,"os_error":"The
> specified class was not
> found.\r\n","syscall":"getaddrinfo","wsa_error":10109}]}]}"
>
>
> *Additional Context:*
>
>- They are using grpc 1.40.0
>- They are able to access the REST API of *firestore.googleapis.com
>* through `requests`.
>- They tried switching to GRPC_DNS_RESOLVER=native as suggested in
>https://github.com/grpc/grpc/issues/18691
> without
>success.
>- They can run the same code successfully from their personal (Mac)
>computer.
>
>
> Any pointers on what to try next would be much appreciated. 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/50378f56-90fc-4b9d-9ec5-d18f65bb1e0fn%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%3DjcTBu4P6rRs9%2BrPmPHL6Pv7gTbp99RETcFRoXiSJEXBSg%40mail.gmail.com.

[grpc-io] Re: [Python] gRPC hello world example fails on HPC cluster

['Lidi Zheng' via grpc.io]

gRPC Python server spawns worker threads. Each incoming request will be 
routed to one of the worker. The main thread is expected to be blocked via 
the `wait_for_termination` call.

On the other hand, I have little expertise about HPC cluster. I'm not sure 
what is blocking here. I wonder if you have access to debuggers like gdb, 
then you can peek into what function it is executing last.



On Friday, October 1, 2021 at 8:29:29 AM UTC-7 lee ming wrote:

>
> Hi,
>
> I am running into a really odd issue where the following line (obtained 
> from hello world's greeter_server.py example) freezes when it is executed 
> on a HPC cluster. 
>
> server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
>
> The following stack trace could provide more information on where the 
> greeter_server program gets stuck within the gRPC Python library:
>
> Thread 204411 (active): "MainThread"
> __init__ (grpc/_server.py:958)
> create_server (grpc/_server.py:1003)
> server (grpc/__init__.py:2064)
> serve (greeter_server.py:31)
>  (greeter_server.py:40)
>
> (Apologies for the poor formatting)
>
> The weird thing about this issue is that 
>
>- The hello world example (greeter_server + greeter_client) works fine 
>locally.
>- I attempted to debug by adding the "GRPC_VERBOSITY=DEBUG 
>GRPC_TRACE=all" flag (and confirmed it works locally), but nothing 
>gets printed out while running on the HPC cluster.  Furthermore, no 
>exception is thrown, rather the program simply freezes with the above 
> stack 
>trace.
>
> I'm wondering if anyone has run into this issue before. I have spoken to 
> the administrator of the HPC cluster and as far as I know there are no 
> specific restrictions from preventing gRPC servers from being hosted.
>
> 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/ab9b059c-7532-4e63-92a8-b4436a6c0ef8n%40googlegroups.com.

[grpc-io] Re: gRCP Kubernetes Timeouts

['Lidi Zheng' via grpc.io]

Hi,

gRPC's trace flags might help: 
https://github.com/grpc/grpc/blob/master/doc/environment_variables.md

I would recommend "GRPC_VERBOSITY=debug GRPC_TRACE=api" as a starting point.

The RPC latency could be a result of many factors. E.g., the pod's resource 
limit, the network environment. With the tracing flag, we might be able to 
see why a particular RPC failed, is it name resolution or failed to connect 
to endpoints.

If nothing wrong is observed in trace log, we could use "netstat" to check 
packet loss, or "tcpdump" to see where the traffic is actually going.

On Tuesday, August 24, 2021 at 3:28:31 PM UTC-7 Aaron Pelz wrote:

> Hi all, 
>
> New to the group and a little newer to gRPC in general, so hoping to get 
> some pointers on where to dig deeper.
>
> Currently we have two services that interact via GRPC. Their client and 
> server libraries are generated by the protoc compiler. Our server side runs 
> python (grpcio 1.37.0) and our client side runs Node (grpc-js 1.3.7). Both 
> sides use Kubernetes deployed in the cloud. We chose GRPC for its typed 
> contracts, polyglot server/client code generation, speed, and, most 
> importantly, its HTTP2 support for long-running, stateful, lightweight 
> connections.
>
> Our setup uses Contour/Envoy load balancing.
>
> The issue right now is that we have requests that
>   1) sometimes never even make it to the server side (i.e. they hit their 
> client-specified timeout with DEADLINE_EXCEEDED)
>   2) take a variable amount of time to get ack'd by the server side (this 
> may not necessarily be an issue but perhaps it is telling as to what is 
> happening)
> - This range is quite jarring and varies per GRPC method:
>   - Method 1 (initialize) - p75 43ms, p95 208ms, p99 610ms, max 750ms
>   - Method 2 (run)- p75 8ms,  p95 13ms,  p99 35ms,  max 168ms
>   - Method 3 (abandon)- p75 7ms,  p95 34ms,  p99 69ms,  max 285ms
>
> When we see requests that never make it to the server side, the requests 
> simply hit their client-specified timeout window without being 
> acknowledged. For these unsuccessful requests, we also never see a 
> corresponding Envoy log. Sometimes the connection happens to only have a 
> one-off network error like this that goes away, however, we had a recent 
> incident where one of our client pods (in a Kubernetes cluster) could not 
> reach the server at all and thousands of requests failed consecutively over 
> ~24 hours. Memory space was quickly lost and we had to restart the pod.
>
> It is worth it to note that some of our processes (e.g. calls to `run` 
> method) take up to 5 minutes to process on the server side. Every other 
> method should take less than ~1s to complete.
>
> Any ideas on where this could be happening, or if there are extra systems 
> we can add telemetry to would be helpful!
>
> Cheers,
> Aaron
>
>

-- 
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/a1ea3563-b2fa-4be3-b6f3-6cae6920155en%40googlegroups.com.

[grpc-io] Re: Python BiDi server side implementation questions

['Lidi Zheng' via grpc.io]

I would recommend to try the gRPC AsyncIO API, it solves all 3 problems you 
are asking. Here is an example containing the bidi server-side code:

https://github.com/grpc/grpc/blob/master/examples/python/route_guide/asyncio_route_guide_server.py

> Is there a non-blocking way to check if any new requests came in, without 
having to create a separate thread?

In AsyncIO world, you can create a coroutine to consume the requests.

> Is there a way to attach an observer to the stream to process requests as 
they come in?

The request-consuming coroutine can also invoke the logic you want for 
every incoming request.

> Is there a way to get hold of a stream "object" that I can use to send 
responses back from a different thread? From what I have seen, "yield" 
seems to be the only way to stream data back from server to client.

The AsyncIO API's `context 
` 
object has `context.read()` and `context.write()` method that one can carry 
the logic of an RPC to another coroutine.

---

For sync/normal API:

> Is there a non-blocking way to check if any new requests came in, without 
having to create a seperate thread?

No. We don't have an API for checking.

> Is there a way to attach an observer to the stream to process requests as 
they come in?

Server interceptors might do the trick for you.

> Is there a way to get hold of a stream "object" that I can use to send 
responses back from a different thread? From what I have seen, "yield" 
seems to be the only way to stream data back from server to client.

You need to build your own pipe (Pipe 

 
example).



On Tuesday, August 3, 2021 at 3:11:07 PM UTC-7 Akhilesh Raju wrote:

> Hi all,
>
> At a very high level, I have a BiDi stream between a python grpc server 
> and node grpc client.
> The client sends a request to the server to start streaming of data back 
> to the client. At any time, the client can decide it wants to stop the 
> streaming of data from the server and send a request to the server to do 
> the same.
> For example purposes, the data streamed back by the server is a simple str 
> representation of the current timestamp.
> The proto file and server python code can be found here - GitHub Gist 
> 
>
> Here is what I would ideally like to do
>
>1. Send stream start request from client to server
>2. Server receives it and starts sending back data as and when its 
>produced, without any intervention from the client
>3. After some time T, the client decides that it wants to stop the 
>stream and sends a stop request to the server
>4. The server received the request and stop sending any more data.
>
> The def TimeStream function is provided with 2 things - a request 
> iterator and context. When I try to fetch requests from the 
> request_iterator via next(request_iterator), if there are no pending 
> requests, the next() statement blocks till a new request comes in.
> To continuously stream data back from the server and also process incoming 
> requests from the client, I had to create a new thread to fetch requests 
> through the request_iterator, allowing the originial thread the request 
> came on, free to "yield" values.
> This can be seen in lines 80-135 in the server.py file 
> 
>
> With this in mind, here are the questions I have
>
>- Is there a non-blocking way to check if any new requests came in, 
>without having to create a seperate thread?
>- Is there a way to attach an observer to the stream to process 
>requests as they come in?
>- Is there a way to get hold of a stream "object" that I can use to 
>send responses back from a different thread? From what I have seen, 
> "yield" 
>seems to be the only way to stream data back from server to 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/1136b74e-3e0d-4bdc-a5da-5068bd5306e9n%40googlegroups.com.

[grpc-io] Re: In python asyncio grpc server, handling a client-triggered cancellation of an RPC on the server-side

['Lidi Zheng' via grpc.io]

Adding the SO link for this question: 
https://stackoverflow.com/questions/68491834/handle-client-side-cancellation-in-grpc-python-asyncio

In case new discussions happen there.

On Thursday, July 22, 2021 at 3:41:11 PM UTC-7 Brunston wrote:

> ...Turns out you *can* catch the asyncio.CancelledError raised by grpc 
> core. That should work for my current usecase. Any other suggestions that 
> can shed light on the shared context would still be helpful!
> Brunston
>
> On Thursday, July 22, 2021 at 2:51:03 PM UTC-7 Brunston wrote:
>
>> Hi all! I have a question about a Python asyncio gRPC server:
>>
>> How can I perform some server-side action (eg, cleanup) based on a 
>> cancellation of an RPC from the client?
>>
>> In my microservice, I have an asyncio gRPC server whose main RPCs are 
>> bidirectional streams.
>>
>> On the client side (which is also using asyncio), when I cancel 
>> something, it raises an asyncio.CancelledError which is caught and not 
>> reraised by the grpc core:
>>
>>
>> https://github.com/grpc/grpc/blob/master/src/python/grpcio/grpc/_cython/_cygrpc/aio/server.pyx.pxi#L679
>> except asyncio.CancelledError: _LOGGER.debug('RPC cancelled for servicer 
>> method [%s]', _decode(rpc_state.method())) 
>>
>> So I cannot rely on catching the asyncio.CancelledError in my own code, 
>> because it's caught beforehand and not reraised.
>>
>> The shared context is supposed to contain information as to whether the 
>> RPC was canceled on the client side, by calling .cancel() from the RPC 
>> call and being able to see if it was canceled by calling .cancelled():
>>
>> https://grpc.github.io/grpc/python/grpc_asyncio.html#shared-context
>>
>> abstract cancel()
>> Cancels the RPC. Idempotent and has no effect if the RPC has already 
>> terminated. Returns A bool indicates if the cancellation is performed or 
>> not. Return type bool 
>>
>> abstract cancelled()
>> Return True if the RPC is cancelled. The RPC is cancelled when the 
>> cancellation was requested with cancel(). Returns A bool indicates 
>> whether the RPC is cancelled or not. Return type bool 
>>
>> However, this shared context is not attached to the context variable 
>> given to the RPC on the server side by the gRPC generated code. (I cannot 
>> run context.cancelled() or context.add_done_callback; they're not 
>> present)
>>
>> Thoughts? Much appreciated!
>>
>> -Brunston
>>
>

-- 
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/d072c7b0-4a1c-4e47-8341-69c7afcf63b1n%40googlegroups.com.

[grpc-io] Re: anyone know of a public proxy that forward grpc traffic?

['Lidi Zheng' via grpc.io]

gRPC is based on HTTP/2. So technically, most L4 and L7 proxies can route 
gRPC traffic.

But for proxies with more comprehensive embedded gRPC feature, I would 
suggest:


   - Envoy: HTTP/2 first proxy
   - Nginx: Supports gRPC since 1.13.10



On Sunday, July 11, 2021 at 1:43:55 AM UTC-7 elh.m...@gmail.com wrote:

> something like forward free proxy today only for grpc as well.

-- 
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/fcdb2c5d-7ee1-4acf-878b-74fad24ae10fn%40googlegroups.com.

Re: [grpc-io] Re: gRPC occasionally appears abnormal

['Lidi Zheng' via grpc.io]

Hi,

UNAVAILABLE is one of the gRPC status codes, like 503 in HTTP status code.
You can read more about the gRPC status code at
https://github.com/grpc/grpc/blob/master/doc/statuscodes.md.

What you are experiencing could have many different causes. I would
recommend tuning up the Java client's log verbosity to see what exactly is
failing the connection.

Lidi Zheng



On Mon, Jun 14, 2021 at 11:56 PM 李灵韬  wrote:

>
> I changed my code
> ManagedChannelBuilder.forAddress("localhost",
> port).usePlaintext().build();
> to
> ManagedChannelBuilder.forAddress("localhost",
> port).forAddress("127.0.0.1", port).usePlaintext().build();
> , this seems to succeed, no errors occurred, very strange
> 在2021年6月15日星期二 UTC+8 上午11:34:46<李灵韬> 写道：
>
>> Caused by:
>> io.grpc.netty.shaded.io.netty.channel.AbstractChannel$AnnotatedConnectException:
>> Connection refused: no further information: /127.0.0.1:50051
>> Caused by: java.net.ConnectException: Connection refused: no further
>> information
>> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
>> at 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:702)
>> at
>> io.grpc.netty.shaded.io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
>> at
>> io.grpc.netty.shaded.io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
>> 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.lang.Thread.run(Unknown Source)
>>
>> 在2021年6月15日星期二 UTC+8 上午10:49:23<李灵韬> 写道：
>>
>>> Do I need to provide more information?
>>>
>>> 在2021年6月15日星期二 UTC+8 上午10:45:28<李灵韬> 写道：
>>>
 I recently added grpc to my app, but it occasionally reports errors,
 which cannot be reproduced stably.
 Console output:
 java.util.concurrent.ExecutionException:
 io.grpc.StatusRuntimeException: UNAVAILABLE: io exception
 at
 com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:566)
 at
 com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:547)

 My client uses Java, the server uses Python, and the grpc version is
 1.36.0

>>> --
> 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/bb149700-1af6-46fd-a5cc-37294b478e5bn%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%3DjeEdTBcy94BSeMOWJRYYzi5%3D_yG4SHd4tobZ-jGEwFP1Q%40mail.gmail.com.

Re: [grpc-io] How can ı reach grpc request headers in python?

['Lidi Zheng' via grpc.io]

Hi Cihad,

Here is an example of metadata (aka. HTTP Headers) usage in gRPC Python:
https://github.com/grpc/grpc/tree/master/examples/python/metadata.

If you just started to use gRPC Python, I would suggest to read our guide:
https://grpc.io/docs/languages/python/
For question about certain API usage, you may found API reference useful:
https://grpc.github.io/grpc/python/index.html


On Thu, May 20, 2021 at 8:14 AM Cihad Ceviz  wrote:

> Hello, I'm a newbie in the world of grpc and coding. If my question is
> ridiculous, I apologize in advance.
>
> Question: There is a token that we have defined in X. And I have to decide
> whether to run transactions using this token. I can receive the incoming
> request correctly, but I don't know how to access the headers part of this
> request. Is it possible to reach the variable that I define the request by
> typing ".headers" as in the RESTFUL API architecture? What should I do? Can
> you help me?
>
> Thank You, Good Work
>
> If I need to share my code block:
>
> ` def UDTForegroundApp(self, request, context):
> apiRequest = {
> "Token": I need to put the token in the request here
>   
>   
>   
>   
> }
>
> headers = {'Content-type': 'application/json', 'Accept': 'text/plain'}
> requests.post('http://
> */api/auth/save-application', data=json.dumps(apiRequest), 
> headers=headers)
>
> return generatedProtos.application_pb2.DTForegroundAppResponse(ret_complete = 
> services.config.foreground_application_ret_complete) `
>
> --
> 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/018258c9-8062-456e-a327-1e1b0eac8070n%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%3DjcCoFdrzQ%2B41KzDPRcdyh%3DT5GJuvC6k1cGdzxLD7zOTbg%40mail.gmail.com.

Re: [grpc-io] C++ streaming request/non-streaming response

['Lidi Zheng' via grpc.io]

Oops sorry, it seems two threads got tangled in Google Group:
https://groups.google.com/g/grpc-io/c/_0wBUQB_QDk/m/GxHoowm-CQAJ

On Thu, Apr 15, 2021 at 10:12 AM Jeff Steger  wrote:

> Lidi,
> Your response was not to my question, but probably to someone else’s
> question.
>
> On Wed, Apr 14, 2021 at 2:49 PM 'Lidi Zheng' via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> Hi Tarek,
>>
>> The `asyncio.CancelledError` is only generated when an asyncio coroutine
>> is cancelled, in gRPC case, an ongoing RPC is cancelled locally. If the RPC
>> representation (the grpc.aio.Call object) is passed to other coroutines,
>> it's possible that they might cancel it, hence current coroutine will
>> receive a `asyncio.CancelledError`.
>>
>>
>> On Monday, April 12, 2021 at 9:36:06 AM UTC-7 sunanda...@gmail.com wrote:
>>
>>> Hi,
>>> Sounds strange. I have recently used a similar RPC call with grpc 1.34.
>>> Not observed such issue.
>>> You can try 1.34 or the latest.
>>>
>>> Regards,
>>> Nandi
>>>
>>> On Sun, Apr 11, 2021 at 6:16 AM Jeff Steger  wrote:
>>>
>>>>
>>>>
>>>> Hi all,
>>>> I am using grpc 1.23.0. I recently came across an issue that seems to
>>>> be documented here:
>>>>
>>>> https://github.com/paralin/grpc-bus/issues/35
>>>>
>>>> In sum:
>>>>
>>>> When a new call is created with a streaming request/non-streaming
>>>> response, an initial message is sent immediately (before call.write() is
>>>> ever explicitly invoked) with a blank value.
>>>>
>>>>
>>>>
>>>> Has anyone seen this before and does anyone know if there is a grpc
>>>> version where this is fixed?  Thanks!
>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "grpc.io" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/grpc-io/_0wBUQB_QDk/unsubscribe.
>>>> To unsubscribe from this group and all its topics, 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/CAA-WHum4DOYr9jQAX-iDSxc%3Dy9F4mFMYWPq72kWyRuiUpbDM5Q%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/grpc-io/CAA-WHum4DOYr9jQAX-iDSxc%3Dy9F4mFMYWPq72kWyRuiUpbDM5Q%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>> 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/31788ed7-0e23-4b39-b88a-6b7e81eb72e5n%40googlegroups.com
>> <https://groups.google.com/d/msgid/grpc-io/31788ed7-0e23-4b39-b88a-6b7e81eb72e5n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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%3DjfvoHXJ-%3DuFHLS_DaGZ8kgF283%2B6SjjgPy81JTh-MR5hg%40mail.gmail.com.

Re: [grpc-io] C++ streaming request/non-streaming response

['Lidi Zheng' via grpc.io]

Hi Tarek,

The `asyncio.CancelledError` is only generated when an asyncio coroutine is 
cancelled, in gRPC case, an ongoing RPC is cancelled locally. If the RPC 
representation (the grpc.aio.Call object) is passed to other coroutines, 
it's possible that they might cancel it, hence current coroutine will 
receive a `asyncio.CancelledError`.


On Monday, April 12, 2021 at 9:36:06 AM UTC-7 sunanda...@gmail.com wrote:

> Hi,
> Sounds strange. I have recently used a similar RPC call with grpc 1.34.
> Not observed such issue. 
> You can try 1.34 or the latest.
>
> Regards,
> Nandi
>
> On Sun, Apr 11, 2021 at 6:16 AM Jeff Steger  wrote:
>
>>
>>
>> Hi all,
>> I am using grpc 1.23.0. I recently came across an issue that seems to be 
>> documented here:
>>
>> https://github.com/paralin/grpc-bus/issues/35
>>
>> In sum:
>>
>> When a new call is created with a streaming request/non-streaming 
>> response, an initial message is sent immediately (before call.write() is 
>> ever explicitly invoked) with a blank value.
>>
>>
>>
>> Has anyone seen this before and does anyone know if there is a grpc 
>> version where this is fixed?  Thanks!
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "grpc.io" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/grpc-io/_0wBUQB_QDk/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAA-WHum4DOYr9jQAX-iDSxc%3Dy9F4mFMYWPq72kWyRuiUpbDM5Q%40mail.gmail.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/31788ed7-0e23-4b39-b88a-6b7e81eb72e5n%40googlegroups.com.

Re: [grpc-io] about grpc's architecture

['Lidi Zheng' via grpc.io]

Here's a thorough talk about gRPC internals: gRPC Deep Dive – Sree
Kuchibhotla & Jayant Kolhe, Google
https://www.youtube.com/watch?v=S7WIYLcPS1Y

On Mon, Apr 12, 2021 at 3:29 PM Tao Wang  wrote:

> Hi,
>
> I am trying to look into the source code of grpc. Is there any suggestion
> or documentation on gRPC's threading model or network model?
>
> --
> 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/30946a1c-4a19-4307-9ca0-ebe5ae551ca9n%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%3Djd1CTZV1K9%3D%2BKTCuUOaX7Csee_nvk2eUdk7Q5q3PPWrMQ%40mail.gmail.com.

[grpc-io] Re: AttributeError: 'grpc._cython.cygrpc._ServicerContext' object has no attribute 'add_done_callback'

['Lidi Zheng' via grpc.io]

Hi,

`add_done_callback` wasn't added to grpc.aio.Server because there was a 
discussion that it overlaps with server interceptors: 
https://github.com/grpc/grpc/pull/22503.

I can update the PR later this week. If possible, please explain more about 
your use case and why you think `add_done_callback` would be handy.

On Saturday, April 3, 2021 at 2:56:56 PM UTC-7 dr.t...@gmail.com wrote:

> Hi,
>
> Using python grpc.aio, I'm not able to add a callback  on server side 
> (using context) to be invoked on a grpc stream terminated/cancelled -- I 
> use grpc.aio.server().
> The documentation here 
>  
> mentions 
> the callback, but I can't seem to be able to get it to work. 
>
> If I use grpc.server() instead, I can set add_callback()
>
> I'm using:
> Name: grpcio
> Version: 1.36.1
> Name: grpcio-tools
> Version: 1.35.0
> Name: aiogrpc
> Version: 1.8
>
> 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/1e2cfa41-2531-44e3-97f2-eff35b2265b4n%40googlegroups.com.

[grpc-io] Re: Python: How should credentials be refreshed for long streaming requests?

['Lidi Zheng' via grpc.io]

Based on code, AuthMetadataPlugin fetches and injects the access token to 
headers (or initial metadata). For every RPC, unary or streaming, the 
initial metadata will only be sent once. So, normally, the backend 
validates the token when it receives the request, and the RPC is allowed to 
run for arbitrary amount of time.

Unless, the backend or one of the proxy has an aggressive cut-off mechanism 
to abort the RPC with UNAUTHENTICATED(16) and with the text message in #712.

In short, it's more likely this error is generated at the beginning of RPC 
instead of in the middle.

---

As for refresh credentials,  I saw the `CLOCK_SKEW`. So, there should not 
be invalid token when the client sent out the request. Is it possible that 
the first frame of the RPC lagged for 10s, so the server received an 
out-of-date access token? I guess we will need trace log to find out the 
root cause. Users can set `GRPC_TRACE=plugin_credentials` to see more 
details.

On Thursday, March 18, 2021 at 8:02:55 AM UTC-7 busu...@google.com wrote:

> google-auth implements AuthMetadataPlugin 
> 
>  
> . For some long streaming calls, it looks like the the credentials can 
> expire mid-request.
>
> What's the correct way to ensure the credentials get refreshed in this 
> case?
>
> https://github.com/googleapis/google-auth-library-python/issues/712
>

-- 
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/59ba26f6-4d27-4f72-9e2d-e219e08c2f30n%40googlegroups.com.

[grpc-io] Re: Python: Will it be affected if the Python version is less than 3.5

['Lidi Zheng' via grpc.io]

Yes. gRPC Python can run on Python2.7 environment.
On Sunday, March 7, 2021 at 10:23:09 PM UTC-8 李灵韬 wrote:

> Hello, I want to consult about the Python version. At present, I have 
> successfully run the example in the Python2.7 environment, but the official 
> website example says that it needs 3.5 or more. I don't know if it will be 
> affected by the version issue in the future. I want to confirm whether gRPC 
> can run in a version less than 3.5?
>

-- 
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/57f15553-391d-45dd-aaba-5d3a6b3cfca7n%40googlegroups.com.

[grpc-io] Re: Channel getting dropped

['Lidi Zheng' via grpc.io]

I'm not sure I fully understand the question "how can the client needs to
establish connectivity to these new pods". But this use case seems specific
to a cloud provider, and I don't have more context than you do.

Whether to connect to backends or use in-line load balancers, this is more
of a business logic decision. If one client needs to connect to all
backends to function, then the scalability of the backends will be limited.
Based on the information provided, if I were you, I would rethink how the
information is organized and consider a possible solution to shard them
properly. E.g., using a light-weight in memory database to handle the load.



On Thu, Feb 25, 2021 at 3:34 PM Mahadevan Krishnan 
wrote:

> Hi Lidi,
>
> Thanks for taking time to respond. We have been doing Keep Alive Pings
> every 30 seconds(even if there is no data) to keep the channel live.
>
> I had one more follow up question to check if you have any ideas on it.
>
> Currently the gRPC server is running on Kubernetes POD streaming out the
> data to Client. Server POD is responsible for reading from AWS Kinesis and
> pushing this out to our customers for sensor data. Data is sharded based on
> the Device ID and hence when I start more instances of gRPC Server POD, it
> helps distribute the load between multiple pods as each pod will read a few
> shards from AWS Kinesis. But now the question is how can the client needs
> to establish connectivity to these new pods. Otherwise they will miss out
> the data retrieved from these shards.
>
> Clients will need to open connections to these pods individually or can we
> use load balancers ?  Challenge with load balancer is it has to read data
> from all underlying servers and not any one of servers at a time.
>
> Regards,
> Mahadevan
>
> On Fri, Feb 12, 2021 at 12:43 PM Lidi Zheng  wrote:
>
>> Hi Mahadevan,
>>
>> Thanks for using gRPC!
>>
>> Based on the description, long living connections getting dropped
>> frequently could be caused by TCP socket timeouts.
>>
>> You can refer to our document about how to set keepalive pings:
>> https://github.com/grpc/grpc/blob/master/doc/keepalive.md
>> How to set channel arguments:
>> https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_client_with_options.py
>> The list of available channel arguments:
>> https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/grpc_types.h#L138
>>
>> I'm not sure what the maximum size of channels means. Channels share the
>> underlying TCP sockets when possible. If you mean the maximum number of TCP
>> sockets , gRPC doesn't have such limitations, please check your OS's
>> network settings and the network devices. But as mentioned, I'm more
>> suspect that this could be improved by using keepalive pings.
>>
>> Bests,
>> Lidi Zheng
>>
>>
>> On Fri, Feb 12, 2021 at 9:55 AM Mahadevan Krishnan 
>> wrote:
>>
>>> Hi Lidi,
>>>
>>> Sorry to directly reach out to you through email. I saw one of your
>>> presentations on youtube for gRPC about flow control. Hence I was thinking,
>>> you would be able to help us here on what we could be doing wrong. We are
>>> new to gRPC
>>>
>>> Regards,
>>> Mahadevan
>>>
>>> -- Forwarded message -
>>> From: Mahadevan Krishnan 
>>> Date: Wednesday, 10 February 2021 at 18:53:41 UTC-6
>>> Subject: Channel getting dropped
>>> To: grpc.io 
>>>
>>>
>>>
>>> We have been using Server Streaming Application written in Java through
>>> gRPC maintaining long living connection where we stream data to our clients
>>> based on the data collected from sensors. We have been seeing channel
>>> getting dropped more frequently, connection getting dropped and we need to
>>> make client re-establish connection even though there is no network blip.
>>> We wanted to understand if there is maximum size for channel and if there
>>> is a way to increase the channel size so that we do not lose the channel
>>> and messages that were in the channel needs to be processed. Any help on
>>> this is highly appreciated.
>>>
>>>

-- 
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%3DjfMOHA5FB4%3DY47HFgqN_q1NfhNLNVpA2eP0JguaFhixOA%40mail.gmail.com.

[grpc-io] Re: gRFC A40: xDS Configuration Dump via Client Status Discovery Service in gRPC

['Lidi Zheng' via grpc.io]

Also, the link to the gRFC PR: https://github.com/grpc/proposal/pull/223

On Tuesday, February 16, 2021 at 12:20:55 PM UTC-8 Lidi Zheng wrote:

> Hi,
>
> I drafted an gRFC for adding config dump functionality to gRPC. Comments 
> and suggestions are welcomed!
>
> gRFC Link: 
> https://github.com/lidizheng/proposal/blob/csds/A40-csds-support.md
>
> Lidi Zheng
>

-- 
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/30f2b404-9e56-4d61-b2e1-927f16f0cb73n%40googlegroups.com.

[grpc-io] gRFC A40: xDS Configuration Dump via Client Status Discovery Service in gRPC

['Lidi Zheng' via grpc.io]

Hi,

I drafted an gRFC for adding config dump functionality to gRPC. Comments 
and suggestions are welcomed!

gRFC Link: 
https://github.com/lidizheng/proposal/blob/csds/A40-csds-support.md

Lidi Zheng

-- 
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/96a4a58a-6433-45f4-a332-cf908c2dc963n%40googlegroups.com.

[grpc-io] Re: Channel getting dropped

['Lidi Zheng' via grpc.io]

Hi Mahadevan,

Thanks for using gRPC!

Based on the description, long living connections getting dropped
frequently could be caused by TCP socket timeouts.

You can refer to our document about how to set keepalive pings:
https://github.com/grpc/grpc/blob/master/doc/keepalive.md
How to set channel arguments:
https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_client_with_options.py
The list of available channel arguments:
https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/grpc_types.h#L138

I'm not sure what the maximum size of channels means. Channels share the
underlying TCP sockets when possible. If you mean the maximum number of TCP
sockets , gRPC doesn't have such limitations, please check your OS's
network settings and the network devices. But as mentioned, I'm more
suspect that this could be improved by using keepalive pings.

Bests,
Lidi Zheng


On Fri, Feb 12, 2021 at 9:55 AM Mahadevan Krishnan 
wrote:

> Hi Lidi,
>
> Sorry to directly reach out to you through email. I saw one of your
> presentations on youtube for gRPC about flow control. Hence I was thinking,
> you would be able to help us here on what we could be doing wrong. We are
> new to gRPC
>
> Regards,
> Mahadevan
>
> -- Forwarded message -
> From: Mahadevan Krishnan 
> Date: Wednesday, 10 February 2021 at 18:53:41 UTC-6
> Subject: Channel getting dropped
> To: grpc.io 
>
>
>
> We have been using Server Streaming Application written in Java through
> gRPC maintaining long living connection where we stream data to our clients
> based on the data collected from sensors. We have been seeing channel
> getting dropped more frequently, connection getting dropped and we need to
> make client re-establish connection even though there is no network blip.
> We wanted to understand if there is maximum size for channel and if there
> is a way to increase the channel size so that we do not lose the channel
> and messages that were in the channel needs to be processed. Any help on
> this is highly appreciated.
>
>

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

[grpc-io] Re: Multi-thread support for python asyncio gRPC clients

['Lidi Zheng' via grpc.io]

Answered in the SO post. Let's continue the discussion there.

On Friday, January 29, 2021 at 7:25:21 AM UTC-8 Michael McCarthy wrote:

> Hi folks,
>
> I have an asyncio gRPC client that is used in a multithreaded environment. 
> When multiple threads connect to the service via the client simultaneously, 
> I see a stream of the following errors:
> 2021-01-27 09:33:56,937 ERROR [asyncio] [thread_0] Exception in callback 
> PollerCompletionQueue._handle_events()() handle: )()> Traceback (most 
> recent call last): File "/usr/local/lib/python3.8/asyncio/events.py", line 
> 81, in _run self._context.run(self._callback, *self._args) File 
> "src/python/grpcio/grpc/_cython/_cygrpc/aio/completion_queue.pyx.pxi", line 
> 147, in grpc._cython.cygrpc.PollerCompletionQueue._handle_events 
> BlockingIOError: [Errno 11] Resource temporarily unavailable 2021-01-27 
> 09:33:56,937 ERROR [asyncio] [thread_1] Exception in callback 
> PollerCompletionQueue._handle_events()() handle: )()> Traceback (most 
> recent call last): File "/usr/local/lib/python3.8/asyncio/events.py", line 
> 81, in _run self._context.run(self._callback, *self._args) File 
> "src/python/grpcio/grpc/_cython/_cygrpc/aio/completion_queue.pyx.pxi", line 
> 147, in grpc._cython.cygrpc.PollerCompletionQueue._handle_events 
> BlockingIOError: [Errno 11] Resource temporarily unavailable 
>
> The requests appear to be completing successfully, however, the messages 
> are flooding my logs and making me nervous!
>
> In my tests, each thread creates its own channel and submits its own async 
> requests. The errors occur regardless of the load on the service. The 
> errors do not occur if the clients are running in different processes.
>
> My setup:
>
>- Python version: 3.8.6
>- grpcio version: 1.35.0
>
> Is the behaviour expected? Any insight is appreciated!
>
> I've also created this SO post 
> 
> .
>

-- 
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/ba5eb3de-fbe4-4262-b779-f8f18e6ea472n%40googlegroups.com.

[grpc-io] Re: gRFC L76: Break 2.7 Deprecate gevent Support - Python Major Version Bump

['Lidi Zheng' via grpc.io]

Correct GitHub Issue link: https://github.com/grpc/proposal/pull/217

On Wednesday, January 27, 2021 at 4:24:24 PM UTC-8 Lidi Zheng wrote:

> Hi,
>
> This propose suggests gRPC Python should perform a major version bump to 
> achieve two following goals:
>
>1. Stop releasing 2.7 binaries and stop coding in Python 2/3 
>compatible manner;
>2. Drop custom IO manager usages (e.g., gevent), which will be 
>re-implemented via EventEngine API in the future.
>
> GitHub Issue: https://github.com/grpc/proposal/pull/217 
> 
> gRFC: 
> https://github.com/lidizheng/proposal/blob/l76-python-major-version/L76-python-major-version-bump.md
>
> Comments/suggestions are welcomed!
>
> Lidi Zheng
>

-- 
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/f776fea5-6ccf-4ae1-83e2-565ab457824bn%40googlegroups.com.

[grpc-io] Re: gRFC A38: New Admin Interface API in gRPC

['Lidi Zheng' via grpc.io]

The link above is pointing to the wrong PR, please use this 
https://github.com/grpc/proposal/pull/218.

On Wednesday, January 27, 2021 at 4:14:28 PM UTC-8 Lidi Zheng wrote:

> Hi,
>
> I drafted a proposal that describes a convenience API in each gRPC 
> language to improve the usability of creating a gRPC server with admin 
> services (like Channelz, CSDS).
>
> https://github.com/grpc/proposal/pull/218 
> 
>
> Comments are welcomed!
> Lidi Zheng
>
>

-- 
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/88b81b94-1a07-4e8f-a1d5-654ae23cfe4fn%40googlegroups.com.

[grpc-io] gRFC L76: Break 2.7 Deprecate gevent Support - Python Major Version Bump

['Lidi Zheng' via grpc.io]

Hi,

This propose suggests gRPC Python should perform a major version bump to 
achieve two following goals:

   1. Stop releasing 2.7 binaries and stop coding in Python 2/3 compatible 
   manner;
   2. Drop custom IO manager usages (e.g., gevent), which will be 
   re-implemented via EventEngine API in the future.

GitHub Issue: https://github.com/grpc/proposal/pull/217 

gRFC: 
https://github.com/lidizheng/proposal/blob/l76-python-major-version/L76-python-major-version-bump.md

Comments/suggestions are welcomed!

Lidi Zheng

-- 
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/0cf04e28-ad37-4eee-9e54-9700fb94a236n%40googlegroups.com.

[grpc-io] gRFC A38: New Admin Interface API in gRPC

['Lidi Zheng' via grpc.io]

Hi,

I drafted a proposal that describes a convenience API in each gRPC language 
to improve the usability of creating a gRPC server with admin services 
(like Channelz, CSDS).

https://github.com/grpc/proposal/pull/218 


Comments are welcomed!
Lidi Zheng

-- 
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/515cc575-55ce-4dcd-a092-f388e8ef8bc9n%40googlegroups.com.

[grpc-io] Re: gRPC C++ compression interface support

['Lidi Zheng' via grpc.io]

See https://groups.google.com/g/grpc-io/c/048jQeimZMo.

All available compression algorithm can be found at 
https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/compression_types.h.
 
Currently there is no way to customize compression algorithm for gRPC C++.


On Tuesday, January 12, 2021 at 9:59:45 PM UTC-8 lxsas...@gmail.com wrote:

> Hi,
>
> grpc-go support registers the compressor with gRPC by its name as 
> following:
>
> ```
> func RegisterCompressor(c Compressor) {
> registeredCompressor[c.Name()] = c
> }
> ``` 
>
> github link: 
> https://github.com/grpc/grpc-go/blob/master/encoding/encoding.go
>
> How to register my customize a compressor like grpc-go when using c++ ?
>
> Thank you all.
>

-- 
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/d5ad1e37-7726-40d7-992d-c8ce96b9903cn%40googlegroups.com.

[grpc-io] Re: Is it possible to customize the compression algorithm in gRPC when using C++?

['Lidi Zheng' via grpc.io]

gRPC C++ is a wrapper over gRPC Core. All available compression algorithm 
can be found 
at 
https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/compression_types.h.

However, currently there is no way to customize compression algorithm. If 
this is critical to you, feel free to file a feature request on GitHub: 
https://github.com/grpc/grpc/issues

On Friday, January 8, 2021 at 4:41:46 AM UTC-8 lxsas...@gmail.com wrote:

> golang can register a custom compressor like this
>
> ```
> *grpc.UseCompressor(gzip.Name)*
> ```
>
> In C++ there is just support of several compression algorithms:
>
> ```
> *ChannelArguments args; // Set the default compression algorithm for the 
> channel. *
> *// gzip deflate ...*
> *args.SetCompressionAlgorithm(GRPC_COMPRESS_GZIP); GreeterClient 
> greeter(grpc::CreateCustomChannel( "localhost:50051", 
> grpc::InsecureChannelCredentials(), args));*
> ```
>
> How to add a customize *"compressor"* like golang?
>
>
>

-- 
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/759e7187-8106-41d1-a57c-9f298461548dn%40googlegroups.com.

[grpc-io] Re: Python: Can max receive message length be changed?

['Lidi Zheng' via grpc.io]

Yes. You can set the inbound (receiving) message size via a channel 
argument "grpc.max_receive_message_length" (see definition 

)

Here is an example for how to specify channel 
arguments: 
https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_client_with_options.py#L31

The unit for "grpc.max_receive_message_length" is bytes. If the target 
limit is 1G, the application can set `("grpc.max_receive_message_length", 
1024*1024*1024)` as one of the channel argument.

On Wednesday, October 14, 2020 at 5:10:26 PM UTC-7 busu...@google.com wrote:

> grpc-java appears to have a `maxInboundMessageSize` 
> https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannelBuilder.html#maxInboundMessageSize-int-
>  
> that allows the max inbound message size to be changed.
>
> Is there a similar option for Python?
>
> I see 
> https://groups.google.com/forum/#!searchin/grpc-io/max$20message$20size$20python%7Csort:date/grpc-io/HPLqOjAq2XI/mWrlGZ8cAgAJ
>  
> but it seems to be for max send message size.
>
> Context:
> Some requests to the Cloud Text-to-Speech API result in responses that 
> exceed the 4MB default: 
> https://github.com/googleapis/python-texttospeech/issues/5
> Googlers see internal issue 170125537
>

-- 
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/46582f68-a68c-49f2-8412-8f289a137d7dn%40googlegroups.com.

Re: [grpc-io] How to convert status codes into grpc.StatusCode enum in Python?

['Lidi Zheng' via grpc.io]

This is a constraint of current "grpc.StatusCode" design. Each enum is
constructed by an int and a str, e.g., (0, 'ok'). So, to convert literals
into enums, we need to write:

grpc.StatusCode((5, 'not found'))

For a short-term fix, you may encapsulate an iterating function to map int
to enum, like:

[x for x in grpc.StatusCode if x.value[0] == 5]

Do you think it would be helpful to support direct enum conversion? If we
add a new enum conversion feature, then the client library needs to bump up
the grpcio minimum version again. The conversion can be done without
regression via overriding the initialization method of "grpc.StatusCode".


On Mon, Oct 5, 2020 at 4:15 PM busunkim via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hi,
>
> How do I convert the integer status code (5) into the enum (
> grpc.StatusCode.NOT_FOUND)?
>
>
> https://grpc.github.io/grpc/python/grpc.html#grpc-status-code
>
> I tried the following (see Programmatic access to enumeration members and
> their attributes
> )
> but get an error.
> >>> import grpc
> >>> grpc.StatusCode(5)
> ValueError: 5 is not a valid StatusCode
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File
> "/usr/local/google/home/busunkim/.pyenv/versions/3.7.6/lib/python3.7/enum.py",
> line 310, in __call__
> return cls.__new__(cls, value)
>   File
> "/usr/local/google/home/busunkim/.pyenv/versions/3.7.6/lib/python3.7/enum.py",
> line 564, in __new__
> raise exc
>   File
> "/usr/local/google/home/busunkim/.pyenv/versions/3.7.6/lib/python3.7/enum.py",
> line 548, in __new__
> result = cls._missing_(value)
>   File
> "/usr/local/google/home/busunkim/.pyenv/versions/3.7.6/lib/python3.7/enum.py",
> line 577, in _missing_
> raise ValueError("%r is not a valid %s" % (value, cls.__name__))
> ValueError: 5 is not a valid StatusCode
>
>
> *Context*: I'd like turn a status code from a long running operation (
> google/longrunning/operations.proto
> 
> and google/rpc/status.proto
> )
> into a grpc.StatusCode for nicer exceptions in google-api-core
> .
>
> An operation message looks something like this:
>
> name:
> "projects/my-project/instances/test-instance/databases/db2/operations/_auto_op_43eacb16d4b5d9da"
> metadata {
>   type_url: "
> type.googleapis.com/google.spanner.admin.database.v1.UpdateDatabaseDdlMetadata
> "
>   value:
> "\nHprojects/my-project/instances/test-instance/databases/db2\0223CREATE
> TABLE Albums (\n  id INT64,\n) PRIMARY KEY(id)"
> }
> done: true
> error {
>   code: 9
>   message: "Duplicate name in schema: Albums."
> }
>
>
> 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/375d3166-2c49-4fb4-becd-44bfbf7b9f3do%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%3Djd5taKpfUDNbRNu53OaE6gdqr6E_B6HodAO%3DNMd_iqYgQ%40mail.gmail.com.

[grpc-io] Re: Help with gRPC Python.

['Lidi Zheng' via grpc.io]

HI James,

I think we have already discussed this issue 
in https://github.com/grpc/grpc/issues/24018. The proven effective 
workaround is setting an environment variable `GRPC_DNS_RESOLVER=native`. 
The reason why the resolver behaves differently in Ubuntu 20 is still under 
investigation.

Lidi

On Thursday, August 27, 2020 at 1:05:47 PM UTC-7 james.w...@gmail.com wrote:

> I though I may add, if I interupt the client while I am waiting for the 
> response I get:
>
> ```
>   File "greeter_client.py", line 37, in 
> run()
>   File "greeter_client.py", line 31, in run
> response = stub.SayHello(helloworld_pb2.HelloRequest(name='you'))
>   File "/home/james/.local/lib/python3.8/site-packages/grpc/_channel.py", 
> line 824, in __call__
> state, call, = self._blocking(request, timeout, metadata, credentials,
>   File "/home/james/.local/lib/python3.8/site-packages/grpc/_channel.py", 
> line 813, in _blocking
> event = call.next_event()
>   File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 338, 
> in grpc._cython.cygrpc.SegregatedCall.next_event
>   File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 169, 
> in grpc._cython.cygrpc._next_call_event
>   File "src/python/grpcio/grpc/_cython/_cygrpc/channel.pyx.pxi", line 163, 
> in grpc._cython.cygrpc._next_call_event
>   File "src/python/grpcio/grpc/_cython/_cygrpc/completion_queue.pyx.pxi", 
> line 63, in grpc._cython.cygrpc._latent_event
>   File "src/python/grpcio/grpc/_cython/_cygrpc/completion_queue.pyx.pxi", 
> line 42, in grpc._cython.cygrpc._next
> KeyboardInterrupt
>
> ```
>
> On Thursday, August 27, 2020 at 3:51:31 PM UTC-4 James Spears wrote:
>
>> Hello All, 
>>
>> I am having a very strange issue with running gRPC Python on my Ubuntu 20 
>> machine. 
>>
>> I have created a stack over flow question where I have been trying to 
>> trouble shoot the problem, but I think it requires someone who has specific 
>> knowledge.
>>
>> Please see the stack overflow question here:
>>
>>
>> https://stackoverflow.com/questions/63621097/grpc-python-quickstart-helloworld-greeter-client-py-is-hanging-before-printing
>>
>> Thanks for your time!
>>
>> 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/9ac23ee4-d65d-42c1-9648-515015036300n%40googlegroups.com.

[grpc-io] Re: GRPC Multiprocessing not working in Python

['Lidi Zheng' via grpc.io]

The reuse port mechanism provided by Linux is hashing your client address. 
If you create many clients, you should see the traffic distributed across 
server processes.

On Monday, September 7, 2020 at 9:21:51 AM UTC-7 schauha...@gmail.com wrote:

> I'm trying grpc multiprocess example listed here on OSX -
> https://github.com/grpc/grpc/tree/74bba2c90a4f4607674a01ec1c0b634708fea887/examples/python/multiprocessing
> [PID 19271] Binding to 'localhost:50976'
> [PID 19292] Starting new server.
> [PID 19293] Starting new server.
> [PID 19294] Starting new server.
> [PID 19295] Starting new server.
> [PID 19296] Starting new server.
> [PID 19297] Starting new server.
> [PID 19298] Starting new server.
>
> I do see multiple server processes started. However, on running the 
> client, I see only one of the server PID logged in server logs. Sample logs 
> below. I expected it to be spread across all the server processes. Am I 
> missing something here?
> [PID 19295] Determining primality of 1139
> [PID 19295] Determining primality of 779
> [PID 19295] Determining primality of 1709
> [PID 19295] Determining primality of 563
> [PID 19295] Determining primality of 1493
> [PID 19295] Determining primality of 226
> [PID 19295] Determining primality of 1140
> [PID 19295] Determining primality of 2027
>

-- 
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/c1bf56a7-3f2c-4207-9df8-6279138b76f8n%40googlegroups.com.

[grpc-io] gRPC A33: Client-Side Fault Injection

['Lidi Zheng' via grpc.io]

Please find gRFC at https://github.com/grpc/proposal/pull/201.

This gRFC discusses approaches to implement fault injection in gRPC, what 
are the fault injection features, how should they behave, and how to make 
it compatible with Envoy and with various control plane.

Comments and suggestions are welcomed :)

-- 
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/83a7a4ad-c89a-4d38-bd2a-6f78426375ben%40googlegroups.com.

[grpc-io] Re: Getting GRPC_ERROR When using docker container to realize grpc cpp server,

['Lidi Zheng' via grpc.io]

You could try to resolve the same address in the container. The error 
complains about failed name resolution.

On Wednesday, July 22, 2020 at 5:24:56 AM UTC-7 sathya...@gmail.com wrote:

> docker run -it  --net=host --name nzs-port7 dnbapp-nzs:1.0 /bin/bash
> E0722 08:49:44.118516158  12 server_chttp2.cc:40]
> {"created":"@1595407784.118446502","description":"Name or service not 
> known","errno":-2,"file":"
> /root/sathya-207-mdev/nz-svc/third_party/grpc_src/src/core/lib/iomgr/resolve_address_posix.cc","file_line":108,"os_error":"Name
>  
> or service not known","syscall":"getaddrinfo","target_address":"/bin/bash"}
>
> When i run the same image manually inside docker its working fine as 
> expected,
> Can u give me an idea/clue about RC ?
> /etc/resolv.conf, and everything is fine as expected
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/fe66933e-c15c-4f29-982c-7c07ccda544cn%40googlegroups.com.

[grpc-io] Re: How to get IP address in a connected grpc client?

['Lidi Zheng' via grpc.io]

Currently, this functionality is not supported. But there is an ongoing 
effort to do so in gRPC Core: https://github.com/grpc/grpc/pull/23489. Feel 
free to comment on the thread for your need.

On Saturday, July 18, 2020 at 1:47:44 AM UTC-7 xx1207...@gmail.com wrote:

> I've tried to build a grpc channel like this:
>
> grpc::CreateCustomChannel(serverIP + ":" + serverPort, 
> grpc::SslCredentials(sslOptions), args);
>
>
> I guess that grpc internally bind a IP for grpc client.
>
> *Now, how can I prossibly get the binded IP of 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/a483d236-4eb2-4124-8e14-34c3d54256b2n%40googlegroups.com.

[grpc-io] Re: Pure C client

['Lidi Zheng' via grpc.io]

You can refer to gRPC Core's header file: 
https://github.com/grpc/grpc/tree/master/include/grpc.

gRPC Core exposes C API, but it contains large number of C++ code. The gRPC 
Core API is designed to serve language wrappers (like C++, Python, Ruby) 
and it could be challenge to develop application upon.

On Thursday, July 16, 2020 at 2:43:43 AM UTC-7 zing...@gmail.com wrote:

> Hello all.
>
> I'm pretty new to grpc and library implementations. I need to integrate 
> grpc client to my pure c embedded application. Can you please advise, is it 
> possible to use gprc library from pure c, without C++ layer?
>
> As I see, for now, there is only Cpp in the examples.
>
> Thank you in advance,
> Best regards,
> Anton
>

-- 
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/d99fbfa9-29b9-4f93-a5ec-145530086398n%40googlegroups.com.

[grpc-io] Re: GetTopChannels returns empty resposne

['Lidi Zheng' via grpc.io]

Sorry the concepts are a bit confusing. The Channel concept in Channelz 
actually refers to "client". So, in a server application, you won't get 
statistics about any gRPC client. GetServers method should give what you 
need.

On Wednesday, June 3, 2020 at 5:36:27 AM UTC-7 ambigu...@gmail.com wrote:

>
> Hello,
>
> I used the channelz to debug my gRpc Service. But I find that it returns 
> empty channels, even if I send many requests.
>
> Platform: 
>
> Linux 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux
> gRpc 1.27.2
>
>
> The minimal code to reproduce:
>
> # server.py
> import grpc
> from concurrent import futures
> from grpc_channelz.v1 import channelz
>
>
> def serve():
> server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
> server.add_insecure_port('127.0.0.1:5000')
> channelz.add_channelz_servicer(server)
> server.start()
> server.wait_for_termination()
>
>
> if __name__ == '__main__':
> serve()
>
>
> And I see that the channelz is enabled default. How can I get the gRpc 
> channel information?
>
>
> 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/824c18f9-0edd-455a-9041-4457d98c0347n%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: Getting/setting metadata in Python

['Lidi Zheng' via grpc.io]

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 grpc-io+unsubscr...@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/CAMC1%3Djdxs%2BtOQSbRPagMLKQR7drWG4hd8AABiNEtgo9cwCSw8A%40mail.gmail.com.

Re: [grpc-io] gRFC L65: Additional PyPI Packages for gRPC Python

['Lidi Zheng' via grpc.io]

Richard had an idea that we could create a bundle named `grpcio[protobuf]`, 
which includes peripheral packages. After all, gRPC team wants to keep the 
implementation agnostic to codec, so they weren't packed into the main 
package.

It's a good idea, this gRFC is for package name confusion. For the new 
bundle package, I can start another proposal.

On Wednesday, May 13, 2020 at 8:18:51 PM UTC-7 hsa...@gmail.com wrote:

> Have you considered using the name for a new meta-package bundle for 
> related packages?
>
>- grpcio
>- grpcio-status
>- grpcio-channelz
>- grpcio-reflection
>- grpcio-health-checking
>- 
>
> Or even a kitchen sink package that includes grpcio-testing and 
> grpcio-tools. 
>
> On Wed, May 13, 2020 at 7:32 PM 'Lidi Zheng' via grpc.io <
> grp...@googlegroups.com> wrote:
>
>> Abstract:
>>
>> gRPC Python is uploaded as "grpcio" on PyPI, but there is another package 
>> named "grpc". Hence, some users are confused. This document proposes to 
>> upload additional packages named "grpc" and "grpc-*" to guide users to 
>> official packages.
>>
>> gRFC: 
>> https://github.com/lidizheng/proposal/blob/L65-python-package-name/L65-python-package-name.md
>> PR: https://github.com/grpc/proposal/pull/177
>>
>> -- 
>> 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/482e22f0-4044-4f7e-81b9-179f70ac5be5%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/grpc-io/482e22f0-4044-4f7e-81b9-179f70ac5be5%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/8567af8c-0404-40c4-8dcd-d44fa9008c46%40googlegroups.com.

[grpc-io] gRFC L65: Additional PyPI Packages for gRPC Python

['Lidi Zheng' via grpc.io]

Abstract:

gRPC Python is uploaded as "grpcio" on PyPI, but there is another package 
named "grpc". Hence, some users are confused. This document proposes to 
upload additional packages named "grpc" and "grpc-*" to guide users to 
official packages.

gRFC: 
https://github.com/lidizheng/proposal/blob/L65-python-package-name/L65-python-package-name.md
PR: https://github.com/grpc/proposal/pull/177

-- 
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/482e22f0-4044-4f7e-81b9-179f70ac5be5%40googlegroups.com.

Re: [grpc-io] gRPC python server memory consumption

['Lidi Zheng' via grpc.io]

Can you create a reproducible example and post it to
https://github.com/grpc/grpc/issues?

On Mon, Apr 20, 2020 at 6:47 PM JS  wrote:

> Hi,
>
> I am currently using gRPC python server and seeing an issue.
>
> This is with gRPC
> *Server*: Python
> *Client*: go-lang
>
> There are Unary RPCs defined in the python gRPC server which basically
> execute an ansible task (ansible spawns a subprocess forking off as a child
> from the main top level process) and returns the result to the end user.
> This task can be time consuming.
>
> I have defined a callback to handle any client side cancellations on
> timeout.
>
> Right now, I see there is a lot of memory that accumulates over time after
> running these RPCs which doesn't get freed once rpc is done.
>
> Do we need to handle any server side clean up after executing the RPC?
>
> The leak is significant that its impacting the functionality. often see *"err:
> rpc error: code = DeadlineExceeded desc = Deadline Exceeded" *when client
> sends a heartbeat request to the server.
>
> Using python 3.6 and gRPC version 1.24
>
> The memory goes up to ~6gb over time before OOM killer kicks in.
>
> Thanks
> J/-
>
> --
> 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/7b3f041d-e9be-4793-a7af-8614b5431a74%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%3Dje%3D38jGK9jcULmX1g2gQ-k7PGf0vZU%3DF8ndD9-Fj_28yg%40mail.gmail.com.

Re: [grpc-io] how to get reflected services and rpc interface in grpc-python?

['Lidi Zheng' via grpc.io]

I don't have a specific example for reflection.proto. It is a gRPC service.
All the messages are defined with comments.
The hard part is FileDescriptorProto, which is defined at
https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/descriptor.proto
.

On Mon, Apr 6, 2020 at 11:09 PM Louis Yang 
wrote:

> thanks, could you provide some example for using relection.proto?
>
> On Tuesday, 7 April 2020 06:51:56 UTC+8, Lidi Zheng wrote:
>>
>> There is a grpcio-reflection package that enables reflection services for
>> servers. See example:
>> https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_server_with_reflection.py
>> .
>>
>> For client-side checking services list, here is the proto definition for
>> service reflection API:
>> https://github.com/grpc/grpc/blob/master/src/proto/grpc/reflection/v1alpha/reflection.proto
>> You can get all the details in the descriptor proto.
>> Another option is using the CLI tool:
>> https://github.com/fullstorydev/grpcurl.
>>
>> On Sat, Apr 4, 2020 at 8:21 PM Louis Yang  wrote:
>>
>>>
>>> Like grpcox tool,
>>>
>>> Given a service endpoint: 1.2.3.4:50001, return the all services list
>>> and rpc api under these services
>>> is there an existing api for this in grpc-python?
>>>
>>> --
>>> 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/005f21b7-76ef-48fa-9be5-f270b52adf9b%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/51654a95-e257-42d1-a2b3-80e255ef74c8%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%3Djdp29R62sZrg9L%3DR3Hqr5kWFgVJ9bC2LZD4sWCuoPkP4Q%40mail.gmail.com.

Re: [grpc-io] how to get reflected services and rpc interface in grpc-python?

['Lidi Zheng' via grpc.io]

There is a grpcio-reflection package that enables reflection services for
servers. See example:
https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_server_with_reflection.py
.

For client-side checking services list, here is the proto definition for
service reflection API:
https://github.com/grpc/grpc/blob/master/src/proto/grpc/reflection/v1alpha/reflection.proto
You can get all the details in the descriptor proto.
Another option is using the CLI tool:
https://github.com/fullstorydev/grpcurl.

On Sat, Apr 4, 2020 at 8:21 PM Louis Yang 
wrote:

>
> Like grpcox tool,
>
> Given a service endpoint: 1.2.3.4:50001, return the all services list and
> rpc api under these services
> is there an existing api for this in grpc-python?
>
> --
> 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/005f21b7-76ef-48fa-9be5-f270b52adf9b%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%3DjdmynvYMvejt5KvwDGG0Dd7DxGoOaW5hGWJntN4kY1%2BEQ%40mail.gmail.com.

Re: [grpc-io] Re: Using google.cloud.ndb (in Python 3.6.6) getting RESOURCE_EXHAUSTED: gRPC message exceeds maximum size 4194304: 13208641 while trying to write data to Google Cloud Datastore

['Lidi Zheng' via grpc.io]

My bad, if you want to increase the maximum size of outbound messages, you
can set this channel argument "grpc.max_send_message_length

".
You can also find the example of how to set examples:
https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_client_with_options.py

On Fri, Feb 28, 2020 at 3:15 AM  wrote:

> Hi Lidi, thanks for your response.
> But from the message *gRPC message exceeds maximum size 4194304:
> 13208641  *it seems max allowed limit is 4mb and entire chunk size is
> 13mb.
> On Friday, February 28, 2020 at 12:02:38 AM UTC+5:30, Lidi Zheng wrote:
>>
>> gRPC has a 4GB hard limit for the size of message, and ProtoBuf has a 2GB
>> hard limit.
>>
>> I wonder what's the real size of the `chunks`, sys.getsizeof
>>  is not
>> accounting for all content in the container.
>>
>> If possible, can you break the data into multiple messages?
>>
>> On Thursday, February 27, 2020 at 6:11:52 AM UTC-8
>> sudipt...@decagames.com wrote:
>>
>>> Getting error in Python 3.6.6 where I am trying to write data using
>>> ndb.put_multi(chunks) where *ndb* is *google.cloud.ndb* from
>>> google-cloud-ndb==1.0.1 
>>>
>>>from google.cloud import ndb
>>>
>>> We are getting the following error while doing* ndb.put_multi(chunks)*.
>>> where we have sys.getsizeof(chunks) is 200 (*bytes)*
>>>
>>> [datastore] Feb 27, 2020 6:53:21 PM
 io.grpc.netty.NettyServerStream$TransportState deframeFailed

 [datastore] WARNING: Exception processing message

 [datastore] io.grpc.StatusRuntimeException: RESOURCE_EXHAUSTED: *gRPC
 message exceeds maximum size 4194304: 13208641*

 [datastore] at io.grpc.Status.asRuntimeException(Status.java:521)

 [datastore] at
 io.grpc.internal.MessageDeframer.processHeader(MessageDeframer.java:387)

 [datastore] at
 io.grpc.internal.MessageDeframer.deliver(MessageDeframer.java:267)

 [datastore] at
 io.grpc.internal.MessageDeframer.request(MessageDeframer.java:161)

 [datastore] at
 io.grpc.internal.AbstractStream$TransportState.requestMessagesFromDeframer(AbstractStream.java:205)

 [datastore] at
 io.grpc.netty.NettyServerStream$Sink$1.run(NettyServerStream.java:100)

 [datastore] at
 io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)

 [datastore] at
 io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)

 [datastore] at
 io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:474)

 [datastore] at
 io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:909)

 [datastore] at
 java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)

 [datastore] at
 java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

 [datastore] at java.base/java.lang.Thread.run(Thread.java:830)

>>>
>>> I am running datastore emulator in my local using gcloud beta emulators
>>> datastore start command.
>>>
>>> Thanks in advance for your help.
>>>
>> --
> 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/acbda9ff-5be0-40e4-ae96-39caecac4163%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%3Djd%3Dk7YkiAXbipP9NZyrcaVWwWTdHqjP0FtGUA_xiRP8hQ%40mail.gmail.com.

[grpc-io] Re: Using google.cloud.ndb (in Python 3.6.6) getting RESOURCE_EXHAUSTED: gRPC message exceeds maximum size 4194304: 13208641 while trying to write data to Google Cloud Datastore

['Lidi Zheng' via grpc.io]

gRPC has a 4GB hard limit for the size of message, and ProtoBuf has a 2GB 
hard limit.

I wonder what's the real size of the `chunks`, sys.getsizeof 
 is not 
accounting for all content in the container.

If possible, can you break the data into multiple messages?

On Thursday, February 27, 2020 at 6:11:52 AM UTC-8 sudipt...@decagames.com 
wrote:

> Getting error in Python 3.6.6 where I am trying to write data using 
> ndb.put_multi(chunks) where *ndb* is *google.cloud.ndb* from  
> google-cloud-ndb==1.0.1 
>
>from google.cloud import ndb
>
> We are getting the following error while doing* ndb.put_multi(chunks)*. 
> where we have sys.getsizeof(chunks) is 200 (*bytes)*
>
> [datastore] Feb 27, 2020 6:53:21 PM 
>> io.grpc.netty.NettyServerStream$TransportState deframeFailed
>>
>> [datastore] WARNING: Exception processing message
>>
>> [datastore] io.grpc.StatusRuntimeException: RESOURCE_EXHAUSTED: *gRPC 
>> message exceeds maximum size 4194304: 13208641*
>>
>> [datastore] at io.grpc.Status.asRuntimeException(Status.java:521)
>>
>> [datastore] at 
>> io.grpc.internal.MessageDeframer.processHeader(MessageDeframer.java:387)
>>
>> [datastore] at 
>> io.grpc.internal.MessageDeframer.deliver(MessageDeframer.java:267)
>>
>> [datastore] at 
>> io.grpc.internal.MessageDeframer.request(MessageDeframer.java:161)
>>
>> [datastore] at 
>> io.grpc.internal.AbstractStream$TransportState.requestMessagesFromDeframer(AbstractStream.java:205)
>>
>> [datastore] at 
>> io.grpc.netty.NettyServerStream$Sink$1.run(NettyServerStream.java:100)
>>
>> [datastore] at 
>> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
>>
>> [datastore] at 
>> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)
>>
>> [datastore] at 
>> io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:474)
>>
>> [datastore] at 
>> io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:909)
>>
>> [datastore] at 
>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>>
>> [datastore] at 
>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>>
>> [datastore] at java.base/java.lang.Thread.run(Thread.java:830)
>>
>
> I am running datastore emulator in my local using gcloud beta emulators 
> datastore start command.
>
> Thanks in advance for your help.
>

-- 
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/d4e183e1-63c0-461e-a49c-c9b23c0c36a5%40googlegroups.com.

Re: [grpc-io] [Python] GRPC Server performance bottleneck

['Lidi Zheng' via grpc.io]

I answered in SO. Let's continue the discussion in SO.

On Tue, Feb 11, 2020 at 9:58 PM  wrote:

>
> I have asked this question in SO
>
> https://stackoverflow.com/questions/60181972/python-grpc-server-performance-bottleneck
>
> but i just would like to try my luck in here as well...
>
>
> I have written a grpc server that contains multiple rpc services. Some are
> unary and some are server side streaming.
>
> It connects to a grpc kubernetes server so I am using the python
> kubernetes client to query the server
>
> Currently I am having some performance problems as I think if there are
> multiple request coming in that it buffers for every worker to finish up
> before it can serve the incoming request.
>
> def startServer():
> global server
> server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
> servicer_grpc.add_Servicer_to_server(Servicer(), server)
> server.add_insecure_port('[::]:' + str(port))
> server.start()
>
> My questions are:
>
>1.
>
>How can I improve my performance? Will adding more max_workers in the
>threadpoolexecutor helps?
>2.
>
>How can I diagnose the problem and isolate which is causing the
>slowdown?
>3.
>
>I am thinking if the size of the response matters in this case as I am
>streaming bytestring to the client. Is there a way to measure the size of
>the response or does it matter in python grpc?
>
> I would like to know how do you diagnose your python grpc server so that
> you would know where to improve?
>
> --
> 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/c305b3f7-f047-4d6a-b90b-eaa1bc2ae926%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%3DjdDwKsCGVYS-EvW%2B6H0y-1omhskVpKqbLJj4dBTn9Fexw%40mail.gmail.com.

Re: [grpc-io] Armv7 packages

['Lidi Zheng' via grpc.io]

gRPC Python currently doesn't build binary wheels for armv7 for 3.7 and
3.8. Contributions are welcomed!

On Mon, Dec 16, 2019 at 5:43 AM Szabolcs Bence  wrote:

> Hi,
>
> I'm not sure who to target with this message. Why there are no armv7
> packages for python 3.7 and 3.8?
> https://pypi.org/project/grpcio/#files
>
> Szabolcs
>
> --
> 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/CAGOyjRs9eN%3DmUfv%3D-s2rReC%2BSvHWJJQCPUesUFeAbR%3DvajqKSg%40mail.gmail.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%3DjeUSbmH-fDJh6oz_rSWij0mT%2B86%3DoM0jYUJyF1hUEOUww%40mail.gmail.com.

Re: [grpc-io] Re: Connecting to multiple servers from a single client

['Lidi Zheng' via grpc.io]

What's the down side of creating multiple channels in your case? Can you
describe more about your use case?

On Wed, Sep 18, 2019 at 10:53 AM Gautham Bhat 
wrote:

> I don't want to use the load balancing policy,  my use case is to connect
> to different systems. Is it possible to connect through single stub and
> channel?
>
> On Wed, Sep 18, 2019, 11:03 PM 'Lidi Zheng' via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> Yes. By "multiple servers", if you mean multiple backends of the same
>> service, then it is possible. You can achieve this by:
>> 1. Resolve the backend endpoint URL to multiple backend IP.
>> 2. Set the load balance policy to "round_robin".
>>
>> You can take a look at the C++ example
>> https://github.com/grpc/grpc/tree/master/examples/cpp/load_balancing.
>>
>> On Sunday, September 15, 2019 at 10:22:42 PM UTC-7, Gautham Bhat wrote:
>>>
>>>
>>> Hi All,
>>> I have an use case where a client connects to multiple servers, how can
>>> I achieve this? Is it possible to use single channel for multiple server
>>> connections ? Can someone please help. I am using C++.
>>>
>> --
>> 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/7da8f049-d820-401f-b331-50207adbd135%40googlegroups.com
>> <https://groups.google.com/d/msgid/grpc-io/7da8f049-d820-401f-b331-50207adbd135%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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%3Djcr7KTw%3DBDVTkY_6X0d3%2B6Swx_8q-%3Dv99nRZNV0DD4J3g%40mail.gmail.com.

[grpc-io] Re: Connecting to multiple servers from a single client

['Lidi Zheng' via grpc.io]

Yes. By "multiple servers", if you mean multiple backends of the same 
service, then it is possible. You can achieve this by:
1. Resolve the backend endpoint URL to multiple backend IP.
2. Set the load balance policy to "round_robin".

You can take a look at the C++ example 
https://github.com/grpc/grpc/tree/master/examples/cpp/load_balancing.

On Sunday, September 15, 2019 at 10:22:42 PM UTC-7, Gautham Bhat wrote:
>
>
> Hi All, 
> I have an use case where a client connects to multiple servers, how can I 
> achieve this? Is it possible to use single channel for multiple server 
> connections ? Can someone please help. I am using C++.
>

-- 
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/7da8f049-d820-401f-b331-50207adbd135%40googlegroups.com.

Re: [grpc-io] Re: grpcio wheel build

['Lidi Zheng' via grpc.io]

Hi Ioannis,

This error doesn't look like a bug in the installation process.
This failure is in the compilation of grpcio-tools package.
Can you check the working directory for your IDE, and the relative path of
that file?
It seems somewhere in the settings is wrong.

Lidi

On Thu, Aug 22, 2019 at 1:08 AM Ioannis Vogiatzis Oikonomidis <
ioannis.vogiatzisoikonomi...@ansys.com> wrote:

> Yes the Core build succeeds.
>
>
>
> The command that fails is the following (it is running under a build agent)
>
> $(Build.BinariesDirectory)\python\CPython\$(PythonVersionShort)\winx64\Release\python\python.exe
> -VVV setup.py  --prefix=$(Build.SourcesDirectory) build_ext -c msvc -vvv ||
> goto :error
>
>
>
> Before calling the command I am modifying the PATH and adding the protobuf
> c-core build
>
> ** Visual Studio 2017 Developer Command Prompt v15.8.5
>
> ** Copyright (c) 2017 Microsoft Corporation
>
> **
>
> Environment initialized for: 'x64'
>
> Python 3.6.7 (heads/python_3.6.7_vs2017-dirty:cdc6a0e, May 28 2019,
> 15:50:17) [MSC v.1910 64 bit (AMD64)]
>
> Python 3.6.7 (heads/python_3.6.7_vs2017-dirty:cdc6a0e, May 28 2019,
> 15:50:17) [MSC v.1910 64 bit (AMD64)]
>
> Compiling grpc_tools\_protoc_compiler.pyx because it changed.
>
> Cythonizing grpc_tools\_protoc_compiler.pyx
>
> C:\Dev\tfs_agent\_work\57\b\python\CPython\3_6\winx64\Release\python\lib\site-packages\Cython\Compiler\Main.py:369:
> FutureWarning: Cython directive 'language_level' not set, using 2 for now
> (Py2). This will change in a later release! File:
> C:\Dev\tfs_agent\_work\57\s\tools\distrib\python\grpcio_tools\grpc_tools\_protoc_compiler.pyx
>
>   tree = Parsing.p_module(s, pxd, full_module_name)
>
> Traceback (most recent call last):
>
>   File "setup.py", line 209, in 
>
> package_data=package_data(),
>
>   File "setup.py", line 155, in package_data
>
> shutil.copy(source, target)
>
>   File
> "C:\Dev\tfs_agent\_work\57\b\python\CPython\3_6\winx64\Release\python\lib\shutil.py",
> line 241, in copy
>
> copyfile(src, dst, follow_symlinks=follow_symlinks)
>
>   File
> "C:\Dev\tfs_agent\_work\57\b\python\CPython\3_6\winx64\Release\python\lib\shutil.py",
> line 120, in copyfile
>
> with open(src, 'rb') as fsrc:
>
> FileNotFoundError: [Errno 2] No such file or directory:
> 'third_party\\protobuf\\src\\google\\protobuf\\wrappers.proto'
>
>
>
>
>
> *From:* 'Lidi Zheng' via grpc.io 
> *Sent:* Wednesday, 21 August 2019 22:45
> *To:* grpc.io 
> *Subject:* Re: [grpc-io] Re: grpcio wheel build
>
>
>
> Did the C-Core build succeed? Can you provide specific command and logs?
>
> On Wednesday, August 21, 2019 at 12:40:11 PM UTC-7, Ioannis Vogiatzis
> Oikonomidis wrote:
>
> Yes I did. The files are there.I checked.
>
> I more or less copy pasted the build scripts from the links
> --
>
> *From:* 'Lidi Zheng' via grpc.io 
> *Sent:* Wednesday, August 21, 2019 8:06:17 PM
> *To:* grpc.io 
> *Subject:* [grpc-io] Re: grpcio wheel build
>
>
>
> Did you pull in the submodules?
>
>
>
> git submodule update --init
>
> It looks like those third_party files are missing.
>
> On Friday, August 16, 2019 at 8:28:19 AM UTC-7, ioannis.vogia...@ansys.com
> wrote:
>
> I am trying to build grpcio against an already build protobuf version
>
>
>
> I am first building grpc core according to these instructions
>
>
> https://github.com/grpc/grpc/blob/e6cd312346655d9a936acfb97927dbcd35615623/test/distrib/cpp/run_distrib_test_cmake.bat
>
>
>
>
> then I am moving on to the wheel build according to these instructions
>
>
> https://github.com/grpc/grpc/blob/7f32b96e3d9093dff6f0584ad605a2f10a744ec8/tools/run_tests/artifacts/build_artifact_python.bat
>
>
>
> However the build keeps failing (with or without cython) with the
> following error
>
> [Errno 2] No such file or directory:
> 'third_party\\protobuf\\src\\google\\protobuf\\wrappers.proto'
>
>
>
> My build tooldchain is the following:
>
> - MSVC 2017
>
> - Python 3.6
>
> - setuptools  40.8.0
>
> - cython 0.29.13
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "grpc.io" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/grpc-io/brh7Jj7Dso0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> grp...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid

Re: [grpc-io] Re: grpcio wheel build

['Lidi Zheng' via grpc.io]

Did the C-Core build succeed? Can you provide specific command and logs?

On Wednesday, August 21, 2019 at 12:40:11 PM UTC-7, Ioannis Vogiatzis 
Oikonomidis wrote:
>
> Yes I did. The files are there.I checked. 
> I more or less copy pasted the build scripts from the links 
> --
> *From:* 'Lidi Zheng' via grpc.io >
> *Sent:* Wednesday, August 21, 2019 8:06:17 PM
> *To:* grpc.io >
> *Subject:* [grpc-io] Re: grpcio wheel build 
>  
> Did you pull in the submodules? 
>
> git submodule update --init
>
> It looks like those third_party files are missing.
>
> On Friday, August 16, 2019 at 8:28:19 AM UTC-7, ioannis.vogia...@ansys.com 
> wrote: 
>>
>> I am trying to build grpcio against an already build protobuf version 
>>
>> I am first building grpc core according to these instructions 
>>
>> https://github.com/grpc/grpc/blob/e6cd312346655d9a936acfb97927dbcd35615623/test/distrib/cpp/run_distrib_test_cmake.bat
>>  
>>
>> then I am moving on to the wheel build according to these instructions 
>>
>> https://github.com/grpc/grpc/blob/7f32b96e3d9093dff6f0584ad605a2f10a744ec8/tools/run_tests/artifacts/build_artifact_python.bat
>>
>> However the build keeps failing (with or without cython) with the 
>> following error
>> [Errno 2] No such file or directory: 
>> 'third_party\\protobuf\\src\\google\\protobuf\\wrappers.proto'
>>
>> My build tooldchain is the following:
>> - MSVC 2017
>> - Python 3.6
>> - setuptools  40.8.0
>> - cython 0.29.13
>>
>> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "grpc.io" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/grpc-io/brh7Jj7Dso0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> grp...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/grpc-io/cd77608f-6628-40bd-a852-ce147e681738%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/grpc-io/cd77608f-6628-40bd-a852-ce147e681738%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/b6ba10d0-5005-44c9-b36f-bb023bbb%40googlegroups.com.

[grpc-io] Re: grpcio wheel build

['Lidi Zheng' via grpc.io]

Did you pull in the submodules?

git submodule update --init

It looks like those third_party files are missing.

On Friday, August 16, 2019 at 8:28:19 AM UTC-7, ioannis.vogia...@ansys.com 
wrote:
>
> I am trying to build grpcio against an already build protobuf version
>
> I am first building grpc core according to these instructions 
>
> https://github.com/grpc/grpc/blob/e6cd312346655d9a936acfb97927dbcd35615623/test/distrib/cpp/run_distrib_test_cmake.bat
>  
>
> then I am moving on to the wheel build according to these instructions 
>
> https://github.com/grpc/grpc/blob/7f32b96e3d9093dff6f0584ad605a2f10a744ec8/tools/run_tests/artifacts/build_artifact_python.bat
>
> However the build keeps failing (with or without cython) with the 
> following error
> [Errno 2] No such file or directory: 
> 'third_party\\protobuf\\src\\google\\protobuf\\wrappers.proto'
>
> My build tooldchain is the following:
> - MSVC 2017
> - Python 3.6
> - setuptools  40.8.0
> - cython 0.29.13
>
>

-- 
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/cd77608f-6628-40bd-a852-ce147e681738%40googlegroups.com.

Re: [grpc-io] gRFC L58: Async API for gRPC Python

['Lidi Zheng' via grpc.io]

wait on the future in the sync version by default.
>> >>>>>> - As a user, we have come to learn that writing streaming RPCs
>> with coroutine generator based iterators is super painful today and ideally
>> you want to just call send and receive from the context API.
>> >>>>>> - The gRFC does not address how flow control would interact with
>> async. Please note that proper gRPC support requires these two
>> simultaneously: (1) you should be able to have a pending sending recv and
>> send op simultaneously. (2) gRPC C-core enforces the rule of at most a
>> single pending read op and a single pending write op.
>> >>>>>>
>> >>>>>> Other things of note that are potentially unrelated but can
>> probably be taken away in an opportunity for change:
>> >>>>>> - I don't think we should feel constrained with the current
>> Java-in-Python-abstract-class mess status-quo. Idiomatic Python can simply
>> return a conforming object without necessarily inheriting from abstract
>> classes in __init__.py.
>> >>>>>
>> >>>>>
>> >>>>> +1
>> >>>>>
>> >>>>>> - The server-side interceptor API current can modify which path
>> can be called and potentially rewrite it. That feature is detrimental for
>> high performance servers. It would be great to think about it.
>> >>>>>> - The client-side channel subscribe design should support a
>> "subscribe only once" mechanism (instead of subscribe never ending till
>> unsubscribe) so that we can kill the additional polling thread. This
>> matches with the C-core API model better.
>> >>>>>>
>> >>>>>> The gRFC is long, so there are likely additional things, but this
>> should be good to get some brainstorming going. Can we separate the general
>> async model from each API minutia? I don't think we should carry over each
>> API element without revisiting it carefully. I hope we don't rush through
>> this. You don't get many chances to naturally do a clean redesign like this.
>> >>>>>
>> >>>>>
>> >>>>> A point that we also missed out was coexistence with other
>> (asyncio) event loop. Both client and server side. Not sure if this needs
>> to be first class, but we should consider making this possible.
>> >>>>>
>> >>>>>
>> >>>>>> On Tuesday, July 23, 2019 at 12:06:31 AM UTC+2, Kailash Sethuraman
>> wrote:
>> >>>>>>>
>> >>>>>>> Hooray!
>> >>>>>>>
>> >>>>>>> Some comments:
>> >>>>>>>
>> >>>>>>> "Granularity per channel, per server level". Can you please
>> clarify? Does this mean that a server cannot have 2 or services, some async
>> and others sync? If so, what about pre-packaged services like healthcheck?
>> It will also be a hurdle for easy and gradual adoption of the async API
>> into servers and organizations.
>> >>>>>>>
>> >>>>>>> Will running functions in executors be fully supported? It is a
>> common pattern to run sync tasks in executors on the asyncio event loop
>> using
>> https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.run_in_executor.
>> The executors can be process or thread pools, will both be supported out of
>> the box?
>> >>>>>>>
>> >>>>>>> grpc.aio.Call functions return asyncio.Future, but
>> grpc.ServerContext.send_initial_metadata returns a Task object. Could you
>> please elaborate on the rationale here?
>> >>>>>>>
>> >>>>>>> grpc.aio.channel_ready_future not returning a future, but a
>> coroutine. This can be surprising.
>> >>>>>>>
>> >>>>>>> asyncio Exceptions ( will they be mapped to gRPC Errors where
>> possible)? While the RFC states that the RPCError exceptions will be the
>> same, it does not speak to how
>> >>>>>>> https://docs.python.org/3/library/asyncio-exceptions.html are
>> mapped, if at all.
>> >>>>>>>
>> >>>>>>> There is a comparison between the current gRPC API and the
>> proposed, but it might be valuable to do a similar take from the asyncio
>> perspective -- what are the functions/facilities that will be unavailable
>> with the gRPC async API and how can the similar actions be performed. Eg:
>> asyncio.* functions such as gather,shield, wait_for, wait, etc
>> >>>>>>>
>> >>>>>>> - It would be very nice if the gRFC could include the full API,
>> given that this is a new package, and list functions that will be exported
>> ( ie: added to  __all__)
>> >>>>>>>
>> >>>>>>> Thanks!
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Mon, Jul 22, 2019 at 1:49 PM 'Lidi Zheng' via grpc.io <
>> grp...@googlegroups.com> wrote:
>> >>>>>>>>
>> >>>>>>>> Hi gRPC users,
>> >>>>>>>>
>> >>>>>>>> This proposal is about adding a new set of Async IO native API
>> to gRPC Python, which solves concurrency issues and performance issues for
>> gRPC Python.
>> >>>>>>>> The new API will be isolated with current API, so the migration
>> can happen gradually.
>> >>>>>>>>
>> >>>>>>>> gRFC:
>> https://github.com/lidizheng/proposal/blob/grpc-python-async-api/L58-python-async-api.md
>> >>>>>>>> PR for the gRFC: https://github.com/grpc/proposal/pull/155
>> >>>>>>>>
>> >>>>>>>> Comments and suggestions are welcomed!
>> >>>>>>>>
>> >>>>>>>> Lidi Zheng
>> >>>>>>>>
>> >>>>>>>> --
>> >>>>>>>> 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/92d5e57f-332a-4e48-bdb2-ccc4d515a5bf%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/641a8416-63c3-48af-999e-006c6f4f67c1%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/CAFEPE9Qv_OxHU%2Bp_%2BO7Sx5DAgfAm7DMEk7F6ua9giAoA5Bk03A%40mail.gmail.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/CAM963G1%3DaqxYEcmBPfNXts9NA%2BPESKDjWA0P1acHbgV94aBgtw%40mail.gmail.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%3Dje6ZcEYH78B6fjRz%3DTG9WH3c0m%3Dh%2B5NZ_WO2q%3DxcB0TSQ%40mail.gmail.com.

Re: [grpc-io] gRFC L58: Async API for gRPC Python

['Lidi Zheng' via grpc.io]

e the use case of "subscribe only once"?
> >>>> Thanks to `asyncio`, the `grpc.aio` version doesn't need the polling
> thread.
> >>>>
> >>>> 8. Separate gRFC for each API
> >>>> This gRFC won't be merged until all APIs are implemented.
> >>>> There are plenty of time for us to discuss the details.
> >>>>
> >>>> ---
> >>>>
> >>>> I'll ping the thread once I have resolved all your comments.
> >>>> Thanks again for commenting ;)
> >>>>
> >>>> Lidi Zheng
> >>>>
> >>>>
> >>>> On Mon, Jul 22, 2019 at 6:04 PM Kailash Sethuraman 
> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Jul 22, 2019 at 7:32 PM mehrdad via grpc.io <
> grpc-io@googlegroups.com> wrote:
> >>>>>>
> >>>>>> Thanks for the gRFC. It's certainly a lot to digest. I also
> recommend trying to revisit some of the poorly designed APIs and not simply
> support/replicate everything under the async model.
> >>>>>>
> >>>>>> Without going into the implementation, I have a few key concerns:
> >>>>>>
> >>>>>> - The grpc.aio namespace as a user-facing thing that users would
> import would be terrible.
> >>>>>
> >>>>>
> >>>>> I am not so sure of this -- I think that separating into a new
> namespace for a future API offers an opportunity for a clean break without
> too much change to the current API or behavior and is least surprising for
> the user.
> >>>>>
> >>>>> It avoids  sprawl in the existing module.
> >>>>>
> >>>>> It means no complications from the need to be compatible with python
> 2.
> >>>>>
> >>>>> In Asyncio, a similar approach was taken with asyncio.Queue.
> >>>>>
> >>>>>
> >>>>>> Considering going-forward this will hopefully be the default, we
> should try making it work under the grpc module as much as possible. I
> think for the most part we can do that and there aren't that many technical
> reasons they could not coexist under the same namespace. (RpcMethodHandler
> could add a new attribute `async` for example, that makes the machinery
> invoke the handler and assume it's an async implementation, for instance,
> or server could have a new add_async_rpc_handlers method). On the channel
> side, the async methods could easily live side-by-side, leaving no reason
> to have it under a separate namespace/object.
> >>>>>> - I'd like to echo Kailash's comment as well, which is we probably
> want to be able to host non-async servicers under an existing async server.
> As the testing section admits, this should not be too hard to emulate. In
> fact, it is probably ideal to just build everything on asyncio and simply
> wait on the future in the sync version by default.
> >>>>>> - As a user, we have come to learn that writing streaming RPCs with
> coroutine generator based iterators is super painful today and ideally you
> want to just call send and receive from the context API.
> >>>>>> - The gRFC does not address how flow control would interact with
> async. Please note that proper gRPC support requires these two
> simultaneously: (1) you should be able to have a pending sending recv and
> send op simultaneously. (2) gRPC C-core enforces the rule of at most a
> single pending read op and a single pending write op.
> >>>>>>
> >>>>>> Other things of note that are potentially unrelated but can
> probably be taken away in an opportunity for change:
> >>>>>> - I don't think we should feel constrained with the current
> Java-in-Python-abstract-class mess status-quo. Idiomatic Python can simply
> return a conforming object without necessarily inheriting from abstract
> classes in __init__.py.
> >>>>>
> >>>>>
> >>>>> +1
> >>>>>
> >>>>>> - The server-side interceptor API current can modify which path can
> be called and potentially rewrite it. That feature is detrimental for high
> performance servers. It would be great to think about it.
> >>>>>> - The client-side channel subscribe design should support a
> "subscribe only once" mechanism (instead of subscribe never ending till
> unsubscribe) so that we can kill the additional polling thread. This
> matches with the C-

Re: [grpc-io] Re: How can I do custom authentication in python?

['Lidi Zheng' via grpc.io]

If you are looking for metadata extensions, can you take a look at this
Python example:
https://github.com/grpc/grpc/tree/master/examples/python/auth

On Wed, Aug 14, 2019 at 2:29 AM  wrote:

> Hi,
> Will this help if client wants to custom verify the server
> certificate. Is there any sample?
>
> Client Side: create your own credentials with the credentials metadata
> plugin API:
> https://github.com/grpc/grpc/blob/master/include/grpc/grpc_security.h#L292
>
>
>
> On Sunday, May 22, 2016 at 1:20:43 PM UTC+5:30, Yan Yan wrote:
>>
>> How could I use them in python and C++? Any sample code? Thx.
>>
>> https://github.com/grpc/grpc/issues/2059
>>
>> jboeuf  commented 2 days ago
>> 
>>
>> We now have APIs to do this:
>>
>>1.
>>
>>Client Side: create your own credentials with the credentials
>>metadata plugin API:
>>
>>https://github.com/grpc/grpc/blob/master/include/grpc/grpc_security.h#L292
>>2.
>>
>>Server Side interceptor: auth metadata processor:
>>
>>https://github.com/grpc/grpc/blob/master/include/grpc/grpc_security.h#L383
>>
>>
>>
>> On Friday, May 20, 2016 at 8:35:58 PM UTC+8, Yan Yan wrote:
>>>
>>> How can I do this kind of authentication for each connection?
>>> How can I do this kind of authentication for each call?
>>> Where do I put that if(inputUsername == dbUsername && inputPassword ==
>>> dbPassword) statement? And return a boolean?
>>> Can I do it without encryption? I understand that plain text is
>>> insecure. Thx.
>>>
>>> - authDb.txt
>>> user01,password01
>>> user02,password02
>>>
>>> I have read these.
>>>
>>>
>>> http://www.grpc.io/docs/guides/auth.html#extending-grpc-to-support-other-authentication-mechanisms
>>>
>>> http://www.grpc.io/grpc/cpp/classgrpc_1_1_metadata_credentials_plugin.html
>>> http://www.grpc.io/grpc/python/grpc.beta.html
>>> https://groups.google.com/forum/#!topic/grpc-io/iLHgWC8o8UM
>>>
>>> https://groups.google.com/forum/#!searchin/grpc-io/authentication/grpc-io/LP94S3UF8bU/bLfFV2RGEgAJ
>>>
>>> --
> 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/cc5a118d-196b-486f-8a37-99f94f438ebc%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%3Djc%3D7_iZcKzqr9v4mbJyVbV55hdUYr885Ey8%3Dr%3Dr7h9hrQ%40mail.gmail.com.

Re: [grpc-io] gRFC L58: Async API for gRPC Python

['Lidi Zheng' via grpc.io]

e user.
>>>
>>> It avoids  sprawl in the existing module.
>>>
>>> It means no complications from the need to be compatible with python 2.
>>>
>>> In Asyncio, a similar approach was taken with asyncio.Queue.
>>>
>>>
>>> Considering going-forward this will hopefully be the default, we should
>>>> try making it work under the grpc module as much as possible. I think for
>>>> the most part we can do that and there aren't that many technical reasons
>>>> they could not coexist under the same namespace. (RpcMethodHandler could
>>>> add a new attribute `async` for example, that makes the machinery invoke
>>>> the handler and assume it's an async implementation, for instance, or
>>>> server could have a new add_async_rpc_handlers method). On the channel
>>>> side, the async methods could easily live side-by-side, leaving no reason
>>>> to have it under a separate namespace/object.
>>>> - I'd like to echo Kailash's comment as well, which is we probably want
>>>> to be able to host non-async servicers under an existing async server. As
>>>> the testing section admits, this should not be too hard to emulate. In
>>>> fact, it is probably ideal to just build everything on asyncio and simply
>>>> wait on the future in the sync version by default.
>>>> - As a user, we have come to learn that writing streaming RPCs with
>>>> coroutine generator based iterators is super painful today and ideally you
>>>> want to just call send and receive from the context API.
>>>> - The gRFC does not address how flow control would interact with async.
>>>> Please note that proper gRPC support requires these two simultaneously: (1)
>>>> you should be able to have a pending sending recv and send op
>>>> simultaneously. (2) gRPC C-core enforces the rule of at most a single
>>>> pending read op and a single pending write op.
>>>>
>>>> Other things of note that are potentially unrelated but can probably be
>>>> taken away in an opportunity for change:
>>>> - I don't think we should feel constrained with the current
>>>> Java-in-Python-abstract-class mess status-quo. Idiomatic Python can simply
>>>> return a conforming object without necessarily inheriting from abstract
>>>> classes in __init__.py.
>>>>
>>>
>>> +1
>>>
>>> - The server-side interceptor API current can modify which path can be
>>>> called and potentially rewrite it. That feature is detrimental for high
>>>> performance servers. It would be great to think about it.
>>>> - The client-side channel subscribe design should support a "subscribe
>>>> only once" mechanism (instead of subscribe never ending till unsubscribe)
>>>> so that we can kill the additional polling thread. This matches with the
>>>> C-core API model better.
>>>>
>>>> The gRFC is long, so there are likely additional things, but this
>>>> should be good to get some brainstorming going. Can we separate the general
>>>> async model from each API minutia? I don't think we should carry over each
>>>> API element without revisiting it carefully. I hope we don't rush through
>>>> this. You don't get many chances to naturally do a clean redesign like 
>>>> this.
>>>>
>>>
>>> A point that we also missed out was coexistence with other (asyncio)
>>> event loop. Both client and server side. Not sure if this needs to be first
>>> class, but we should consider making this possible.
>>>
>>>
>>> On Tuesday, July 23, 2019 at 12:06:31 AM UTC+2, Kailash Sethuraman wrote:
>>>>>
>>>>> Hooray!
>>>>>
>>>>> Some comments:
>>>>>
>>>>> "Granularity per channel, per server level". Can you please clarify?
>>>>> Does this mean that a server cannot have 2 or services, some async and
>>>>> others sync? If so, what about pre-packaged services like healthcheck? It
>>>>> will also be a hurdle for easy and gradual adoption of the async API into
>>>>> servers and organizations.
>>>>>
>>>>> Will running functions in executors be fully supported? It is a common
>>>>> pattern to run sync tasks in executors on the asyncio event loop using
>>>>> https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.run_in_executor.
>>&g

[grpc-io] Re: errno showing 11 or 22 for createChannel(secure and Insecure) and for SayHello

['Lidi Zheng' via grpc.io]

The message is received. The code you provide didn't show how the "errno" 
is assigned.
Please refer to 
https://github.com/grpc/grpc/tree/master/examples/cpp/helloworld to see how 
to build a gRPC application.

On Tuesday, July 30, 2019 at 10:27:08 PM UTC-7, toran...@gmail.com wrote:
>
>
> helloworld]# ./greeter_client
> Error no 11, error string Resource temporarily unavailableGreeter 
> received: Hello world
> helloworld]#
>   GreeterClient greeter(grpc::CreateChannel(
>   "localhost:50051", grpc::InsecureChannelCredentials()));
>   std::string user("world");
>   std::string reply = greeter.SayHello(user);
>   printf("Error no %d, error string %s", errno, strerror(errno));
>   std::cout << "Greeter received: " << reply << std::endl;
>
> Is this expected behavior ?
>

-- 
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/81c76504-4bd4-43a4-8353-106ca7f47e89%40googlegroups.com.

[grpc-io] Re: restconf over GRPC

['Lidi Zheng' via grpc.io]

RESTCONF is based on HTTP/1.1, and gRPC is based on HTTP/2.
It will be challenging to integrate those two.

On Saturday, July 27, 2019 at 12:02:50 PM UTC-7, Pratibha Pruno Xavier 
wrote:
>
> Hi experts,
>
>  Is it possible to provide restconf endpoint over GRPC ? I am looking for 
> such solution for micro-service architecture. Primarily we looking for 
> restconf to leverage yang data modelling.
>
> Any clues or pointers on its feasibility would be really helpful.
>

-- 
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/e7d06dd4-d919-4192-8d2a-aea863a49ac7%40googlegroups.com.

[grpc-io] Re: Why increasing max_workers from 1 to any number reduce concurrency in Python gRPC

['Lidi Zheng' via grpc.io]

In short, because of GIL (https://wiki.python.org/moin/GlobalInterpreterLock
).

The `max_workers` flag is meant for IO intensive tasks.
If you are reading from a database or calling an API in your handler, you 
should observe performance increase as you increase `max_workers`.

Unfortunately, for CPU-bound tasks. The more thread workers you spawned in 
gRPC will result in more GIL contentions, and slow the whole process down.
Also, due to some legacy issue, the synchronization overhead between 
threads is quite significant.

If you DO CARE about Python server performance, please help me by posting 
issue in GitHub! https://github.com/grpc/grpc/issues
So the priority of improving Python server performance can raise.

On Saturday, July 20, 2019 at 3:02:56 AM UTC-7, alireza hoseini wrote:
>
> I have used the below sample code to run the server:
>
> self.server = grpc.server(futures.ThreadPoolExecutor(max_workers=1)), 
> maximum_concurrent_rpcs=3000)
>
> Some unnecessary codes are removed for better readability. I have used ghz 
>  to load test my gRPC server:
>
> ghz --insecure --total=1000 --proto my_proto.proto --call my_proto.XServer
> .GetUserById -d '{"user_id": "5d32d36bec68e90844d88ae7"}' 0.0.0.0:9000
>
> Summary:
>   Count: 1000
>   Total: 1.05 s
>   Slowest: 66.93 ms
>   Fastest: 5.59 ms
>   Average: 51.43 ms
> *  Requests/sec: 948.35*
>
> Response time histogram:
>   5.586 [1] |
>   11.721 [3] |
>   17.856 [4] |
>   23.990 [4] |
>   30.125 [4] |
>   36.260 [5] |
>   42.395 [6] |
>   48.530 [11] |∎
>   54.665 [870] |
>   60.799 [84] |
>   66.934 [8] |
>
> Latency distribution:
>   10% in 49.43 ms 
>   25% in 50.32 ms 
>   50% in 51.82 ms 
>   75% in 53.61 ms 
>   90% in 54.61 ms 
>   95% in 55.38 ms 
>   99% in 59.97 ms 
>
> Status code distribution:
>   [OK]   1000 responses   
>
>
> But when I increase *max_workers *to 2 I get RPS of around 700 and if I 
> increase *max_workers* I reach to 600 RPS and lower. Why this behavior 
> happens?
>
> My understanding is that max_workers increase workers that need to get the 
> job done I have one worker then it will be served far more slowly. Why this 
> happens? Shouldn't max_workers increase RPS? 
>

-- 
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/14f4585d-c8e2-4d97-87b3-9a5d588845b6%40googlegroups.com.

Re: [grpc-io] gRFC L58: Async API for gRPC Python

['Lidi Zheng' via grpc.io]

;>> the box?
>>>
>>> grpc.aio.Call functions return asyncio.Future, but
>>> grpc.ServerContext.send_initial_metadata returns a Task object. Could you
>>> please elaborate on the rationale here?
>>>
>>> grpc.aio.channel_ready_future not returning a future, but a coroutine.
>>> This can be surprising.
>>>
>>> asyncio Exceptions ( will they be mapped to gRPC Errors where possible)?
>>> While the RFC states that the RPCError exceptions will be the same, it does
>>> not speak to how
>>> https://docs.python.org/3/library/asyncio-exceptions.html are mapped,
>>> if at all.
>>>
>>> There is a comparison between the current gRPC API and the proposed, but
>>> it might be valuable to do a similar take from the asyncio perspective --
>>> what are the functions/facilities that will be unavailable with the gRPC
>>> async API and how can the similar actions be performed. Eg: asyncio.*
>>> functions such as gather,shield, wait_for, wait, etc
>>>
>>> - It would be very nice if the gRFC could include the full API, given
>>> that this is a new package, and list functions that will be exported ( ie:
>>> added to  __all__)
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
>>> On Mon, Jul 22, 2019 at 1:49 PM 'Lidi Zheng' via grpc.io <
>>> grp...@googlegroups.com> wrote:
>>>
>>>> Hi gRPC users,
>>>>
>>>> This proposal is about adding a new set of Async IO native API to gRPC
>>>> Python, which solves concurrency issues and performance issues for gRPC
>>>> Python.
>>>> The new API will be isolated with current API, so the migration can
>>>> happen gradually.
>>>>
>>>> gRFC:
>>>> https://github.com/lidizheng/proposal/blob/grpc-python-async-api/L58-python-async-api.md
>>>> PR for the gRFC: https://github.com/grpc/proposal/pull/155
>>>>
>>>> Comments and suggestions are welcomed!
>>>>
>>>> Lidi Zheng
>>>>
>>>> --
>>>> 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/92d5e57f-332a-4e48-bdb2-ccc4d515a5bf%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/grpc-io/92d5e57f-332a-4e48-bdb2-ccc4d515a5bf%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>> 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/641a8416-63c3-48af-999e-006c6f4f67c1%40googlegroups.com
>> <https://groups.google.com/d/msgid/grpc-io/641a8416-63c3-48af-999e-006c6f4f67c1%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CAFEPE9Qv_OxHU%2Bp_%2BO7Sx5DAgfAm7DMEk7F6ua9giAoA5Bk03A%40mail.gmail.com
> <https://groups.google.com/d/msgid/grpc-io/CAFEPE9Qv_OxHU%2Bp_%2BO7Sx5DAgfAm7DMEk7F6ua9giAoA5Bk03A%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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%3DjeeVoykNbkEpiSP-xAHn4Vx%2BmSVUoWhYRTgPtG4V9uYUQ%40mail.gmail.com.

Re: [grpc-io] Re: Pushback in unidirectional streaming RPC's

['Lidi Zheng' via grpc.io]

Internally, we are running ASAN test on Python tests.

If you are using Bazel, it would be as simple as --config=ASAN.
If not... then it can be challenging indeed.

The test is about 'GRPC_ARG_PER_RPC_RETRY_BUFFER_SIZE' which seems not
directly related to your case.
If the buffer is not consumed in chttp2 parser, I don't think it will do
another round of tcp_read for that channel.

Can this memory leak be observed in simpler cases?



On Fri, Jul 19, 2019 at 1:03 PM Yonatan Zunger  wrote:

> I have no idea what would be involved in attaching ASAN to Python, and
> suspect it may be "exciting," so I'm trying to see first if gRPC has any
> monitoring capability around its buffers.
>
> One thing I did notice while reading through the codebase was unittests
> like this one
> 
>  about
> exceeding buffer sizes -- that does seem to trigger an ABORTED response,
> but the test was fairly hard to understand (not much commenting there...).
> Am I right in thinking that if this 4MB buffer is overflowed, that's
> somehow going to happen?
>
> On Fri, Jul 19, 2019 at 12:59 PM Lidi Zheng  wrote:
>
>> Hi Yonatan,
>>
>> In gRPC Python side, the consumption of message is sequential, and won't
>> be kept in memory.
>> If you recall the batch operations, only if a message is sent to
>> application, will gRPC Python start another RECV_MESSAGE operation.
>> It's unlikely that the problem resided in Python space.
>>
>> In C-Core space, AFAIK for each TCP read, the size is 4MiB
>> 
>>  per
>> channel.
>> I think we have flow control both in TCP level and HTTP2 level.
>>
>> For debugging, did you try to use ASAN? For channel arg, I can only find
>> "GRPC_ARG_TCP_READ_CHUNK_SIZE" and "GRPC_ARG_MAX_RECEIVE_MESSAGE_LENGTH"
>> that might be related to your case.
>>
>> Lidi Zheng
>>
>> On Fri, Jul 19, 2019 at 12:48 PM Yonatan Zunger  wrote:
>>
>>> Maybe a more concrete way of asking this question: Let's say we have a
>>> Python gRPC client making a response-streaming request to some gRPC server.
>>> The server starts to stream back responses. If the client fails to consume
>>> data as fast as the server generates it, I'm trying to figure out where the
>>> data would accumulate, and which memory allocator it would be using.
>>> (Because Python heap profiling won't see calls to malloc())
>>>
>>> If I'm understanding correctly:
>>>
>>> * The responses are written by the server to the network socket at the
>>> server's own speed (no pushback controlling it);
>>> * These get picked up by the kernel network device on the client, and
>>> get pulled into userspace ASAP by the event loop, which is in the C layer
>>> of the gRPC client. This is stored in a grpc_byte_buffer and builds up
>>> there.
>>> * The Python client library exposes a response iterator, which is
>>> ultimately a _Rendezvous object; its iteration is implemented in
>>> _Rendezvous._next(), which calls cygrpc.ReceiveMessageOperation, which is
>>> what drains data from the grpc_byte_buffer and passes it to the protobuf
>>> parser, which creates objects in the Python memory address space and
>>> returns them to the caller.
>>>
>>> This means that if the client were to drain the iterator more slowly,
>>> data would accumulate in the grpc_byte_buffer, which is in the C layer and
>>> not visible to (e.g.) Python heap profiling using the PEP445 malloc hooks.
>>>
>>> If I am understanding this correctly, is there any way (without doing a
>>> massive amount of plumbing) to monitor the state of the byte buffer, e.g.
>>> with some gRPC debug parameter? And is there any mechanism in the C layer
>>> which limits the size of this buffer, doing something like failing the RPC
>>> if the buffer size exceeds some threshold?
>>>
>>> Yonatan
>>>
>>> On Thu, Jul 18, 2019 at 5:27 PM Yonatan Zunger  wrote:
>>>
 Hi everyone,

 I'm trying to debug a mysterious memory blowout in a Python batch job,
 and one of the angles I'm exploring is that this may have to do with the
 way it's reading data. This job is reading from bigtable, which is
 ultimately fetching the actual data with a unidirectional streaming "read
 rows" RPC. This takes a single request and returns a sequence of data
 chunks, the higher-level client reshapes this into an iterator over the
 individual data cells, and those are consumed by the higher-level program,
 so that the next response proto is consumed once the program is ready to
 parse it.

 Something I can't remember about gRPC internals: What, if anything, is
 the pushback mechanism in unidirectional streaming? In the zero-pushback
 case, it would seem that a server could yield results at any speed, which
 would be accepted by the client and stored in gRPC's internal buffers until
 it got read by the client code, which 

Re: [grpc-io] Re: Pushback in unidirectional streaming RPC's

['Lidi Zheng' via grpc.io]

Hi Yonatan,

In gRPC Python side, the consumption of message is sequential, and won't be
kept in memory.
If you recall the batch operations, only if a message is sent to
application, will gRPC Python start another RECV_MESSAGE operation.
It's unlikely that the problem resided in Python space.

In C-Core space, AFAIK for each TCP read, the size is 4MiB

per
channel.
I think we have flow control both in TCP level and HTTP2 level.

For debugging, did you try to use ASAN? For channel arg, I can only find
"GRPC_ARG_TCP_READ_CHUNK_SIZE" and "GRPC_ARG_MAX_RECEIVE_MESSAGE_LENGTH"
that might be related to your case.

Lidi Zheng

On Fri, Jul 19, 2019 at 12:48 PM Yonatan Zunger  wrote:

> Maybe a more concrete way of asking this question: Let's say we have a
> Python gRPC client making a response-streaming request to some gRPC server.
> The server starts to stream back responses. If the client fails to consume
> data as fast as the server generates it, I'm trying to figure out where the
> data would accumulate, and which memory allocator it would be using.
> (Because Python heap profiling won't see calls to malloc())
>
> If I'm understanding correctly:
>
> * The responses are written by the server to the network socket at the
> server's own speed (no pushback controlling it);
> * These get picked up by the kernel network device on the client, and get
> pulled into userspace ASAP by the event loop, which is in the C layer of
> the gRPC client. This is stored in a grpc_byte_buffer and builds up there.
> * The Python client library exposes a response iterator, which is
> ultimately a _Rendezvous object; its iteration is implemented in
> _Rendezvous._next(), which calls cygrpc.ReceiveMessageOperation, which is
> what drains data from the grpc_byte_buffer and passes it to the protobuf
> parser, which creates objects in the Python memory address space and
> returns them to the caller.
>
> This means that if the client were to drain the iterator more slowly, data
> would accumulate in the grpc_byte_buffer, which is in the C layer and not
> visible to (e.g.) Python heap profiling using the PEP445 malloc hooks.
>
> If I am understanding this correctly, is there any way (without doing a
> massive amount of plumbing) to monitor the state of the byte buffer, e.g.
> with some gRPC debug parameter? And is there any mechanism in the C layer
> which limits the size of this buffer, doing something like failing the RPC
> if the buffer size exceeds some threshold?
>
> Yonatan
>
> On Thu, Jul 18, 2019 at 5:27 PM Yonatan Zunger  wrote:
>
>> Hi everyone,
>>
>> I'm trying to debug a mysterious memory blowout in a Python batch job,
>> and one of the angles I'm exploring is that this may have to do with the
>> way it's reading data. This job is reading from bigtable, which is
>> ultimately fetching the actual data with a unidirectional streaming "read
>> rows" RPC. This takes a single request and returns a sequence of data
>> chunks, the higher-level client reshapes this into an iterator over the
>> individual data cells, and those are consumed by the higher-level program,
>> so that the next response proto is consumed once the program is ready to
>> parse it.
>>
>> Something I can't remember about gRPC internals: What, if anything, is
>> the pushback mechanism in unidirectional streaming? In the zero-pushback
>> case, it would seem that a server could yield results at any speed, which
>> would be accepted by the client and stored in gRPC's internal buffers until
>> it got read by the client code, which could potentially cause a large
>> memory blowout if the server wrote faster than the client read. Is this in
>> fact the case? If so, is there any good way to instrument and detect if
>> it's happening? (Some combination of gRPC debug flags, perhaps) If not, is
>> there some pushback mechanism I'm not thinking of?
>>
>> (Alas, I can't change the protocol in this situation; the server is run
>> by someone else)
>>
>> Yonatan
>>
> --
> 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/CAFk%3DnbT16yfxQ_%2BUkudCAkaADECw-XRbqvtC4u%3DbaEQ_Rv9VAA%40mail.gmail.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%3DjdsOi9prtxQSrphufdbXd%2BkKwzfMw9b%2BMLH1OfsbwKFEg%40mail.gmail.com.

[grpc-io] gRFC L54: Adding a "wait_for_termination" API for Python server

['Lidi Zheng' via grpc.io]

gRFC: 
https://github.com/lidizheng/proposal/blob/python-wait/L54-python-server-wait.md
---

In short, Python server only provided a non-blocking "start" function and 
didn't provide a method to prevent main thread from exiting.
This gRFC is trying to introduce a simple method named 
"wait_for_termination" which will block until the server is 
stopped/terminated.

Feel free to comment :)

-- 
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/922063f2-ed6e-4bb6-a4b3-c860f776cdc5%40googlegroups.com.

[grpc-io] Re: How to debug Intermittent StatusCode.UNAVAILABLE error

['Lidi Zheng' via grpc.io]

Hi,

gRPC provides environmental variables that enables trace log.

The simplest pair will be "GRPC_VERBOSITY=debug" and "GRPC_TRACE=all".
For more finer granularity, please check 
https://github.com/grpc/grpc/blob/master/doc/environment_variables.md.

Lidi Zheng


On Wednesday, June 12, 2019 at 7:00:16 AM UTC-7, zheco...@gmail.com wrote:
>
> Hi all,
>
> My gRPC client raised this error
>
> ...
> File "/home/work/code/venv/site-packages/grpc/_channel.py", line 466, in 
> _end_unary_response_blocking
> raise _Rendezvous(state, None, None, deadline)
> _Rendezvous: <_Rendezvous of RPC that terminated with:
> status = StatusCode.UNAVAILABLE
> details = "OS Error"
> debug_error_string= 
> "{"created":"@1560255578.803770511","description":"Error received from 
> peer","file":"src/core/lib/surface/call.cc","file_line":1036,"grpc_message":"OS
>  
> Error","grpc_status":14}"
>
> It says "Error received from peer", so my server send this status. And it 
> also says "OS Error".
>
> How can inspect what is going on in my server when it says "OS Error"? I 
> expected some startup options or environment variables.
>
> 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/938c4e5b-8ef7-419f-9255-c73679d20837%40googlegroups.com.

Re: [grpc-io] Python custom authentication

['Lidi Zheng' via grpc.io]

Sorry for the confusion. I create a PR to add documentation 
https://github.com/grpc/grpc/pull/19234.

About the motivation, this behavior is enforced by gRPC C-Core. Core team 
decided to raise the security bar. Under insecure Channel, attackers can 
simply sniff your packets and steal your credentials, or simply re-play 
them.
So, they think it would be better to prevent them in the first place.


On Thursday, May 23, 2019 at 3:02:25 PM UTC-7, adul...@gmail.com wrote:
>
> Thank you for the response! 
>
> And yes, later I also tried to create a secure channel with SSL certs 
> used. In that case, I was able to pass creds from the client and read them 
> on the server. Can't say that I understand the motivation for such 
> behavior... 
>
>
> On Thursday, May 23, 2019 at 9:24:37 AM UTC-7, Colin Versteeg wrote:
>>
>> My understanding is that GRPC is opinionated in this space - because the 
>> channel is insecure, it doesn't allow credentials to be sent, to limit 
>> MITM. 
>>
>> I don't recall if it doesn't populate it on the request side, or just 
>> doesn't allow you to access it on the Server side. You can check which one 
>> by using Wireshark to inspect the communication to determine which.
>>
>> If you're trying to test locally and will eventually deploy with SSL, can 
>> use a self signed certificate with ssl_channel_credentials to test this, 
>> passing the cert as the root. 
>> Another option, if you really want to send credentials in plain-text, 
>> would be to just add the token as a random metadata field 
>> (stub.getAllSnippets(req, metadata=[("Authorization", "Token")]), and add 
>> an interceptor in your server which expects invocation_metadata.
>>
>>
>> --
>> *From:* grp...@googlegroups.com  on behalf of 
>> adul...@gmail.com 
>> *Sent:* Wednesday, May 22, 2019 6:25 PM
>> *To:* grpc.io
>> *Subject:* [grpc-io] Python custom authentication 
>>  
>>
>> What is the right way of passing the call credentials when using an 
>> insecure channel? 
>>
>> I have this client code:
>>
>> channel = grpc.insecure_channel('localhost:50051')
>> stub = snippets_pb2_grpc.SnippetsStub(channel)
>> request = snippets_pb2.SnippetsRequest()
>> code_snippets = stub.GetAllSnippets(
>> request,
>> credentials=access_token_call_credentials('my_token')
>> )
>>
>> With this, I can't access  provided credentials on the server side. Tried 
>> both: * context.auth_content()* (returns empty dict) and 
>> *context.invocation_metadata()* (doesn't have any token keys).
>>
>> With the same result I've also tried to extend the *grpc.AuthMetadataPlugin 
>> *class and work this way:
>>
>> class UsernamePasswordCallCredentials(grpc.AuthMetadataPlugin):
>> """Metadata wrapper for raw access token credentials."""
>>
>> def __init__(self, username, password):
>> self._username = username
>> self._password = password
>>
>> def __call__(self, context, callback):
>> basic_auth = "Basic %s" % base64.b64encode("%s:%s" % 
>> (self._username, self._password))
>> metadata = (('authorization', basic_auth),)
>> callback(metadata, None)
>>
>> call_creds = 
>> metadata_call_credentials(UsernamePasswordCallCredentials('my_name', 
>> 'my_password'))
>>
>>
>> channel = grpc.insecure_channel('localhost:50051')
>> stub = snippets_pb2_grpc.SnippetsStub(channel)
>> request = snippets_pb2.SnippetsRequest()
>> code_snippets = stub.GetAllSnippets(
>> request,
>> credentials=call_creds
>> )
>>
>> -- 
>> 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/83c57d08-50e3-4333-a53d-36921da2add1%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/94204105-190f-403e-8a0a-e9a312538158%40googlegroups.com.

Re: [grpc-io] Python gRPC (client) has support for async/await, or still use threading

['Lidi Zheng' via grpc.io]

AsyncIO support is in the top of the road map of gRPC Python team. The past
discussion can be found here -> https://github.com/grpc/grpc/issues/6046.
Currently, gRPC Python only support multi-threading, and forking on
client-side.

*From: *
*Date: *Thu, May 9, 2019 at 2:47 AM
*To: *grpc.io

As the title suggests, I can't determine whether async/await support has
> made it into Python gRPC (client) yet.
>
> I have seen numerous other threads about this (no pun intended), but
> nothing concrete as to what is supported.
>
> --
> 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/8f425c3e-dd69-4937-ac5a-25b539116f3a%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%3DjfTSmoqu2o4K6%2BZP1Acjfqz42G4DRSw92OnkkyCZ-%2Bt_A%40mail.gmail.com.

Re: [grpc-io] [Python] Why are interceptors executed in reverse order?

['Lidi Zheng' via grpc.io]

The Python interceptor design doc has the description about the execution
order ->
https://github.com/grpc/proposal/blob/master/L13-python-interceptors.md#client-side-implementation


On Tue, Apr 30, 2019 at 3:25 PM benkarl via grpc.io <
grpc-io@googlegroups.com> wrote:

>
> This is from the comments on the grpc.intercept_channel method:
> https://github.com/grpc/grpc/blob/f6c090863431b606700440d674eaca5948cffa73/src/python/grpcio/grpc/__init__.py#L1692
>
> And here's the implementation, showing the list on inputs is reversed:
> https://github.com/grpc/grpc/blob/f6c090863431b606700440d674eaca5948cffa73/src/python/grpcio/grpc/_interceptor.py#L508
>
> Just curious because it isn't very intuitive to me that they are given
> control in reverse order that they are provided.
>
> --
> 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 post to this group, send email to grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/4c7ce9ab-39ab-41a2-95f3-fe595719d6df%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAMC1%3Djc2LO5R_R2sqohS5nJo_1nETDSigVEyN1q9h6T7rZ%3DOTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] gRPC not dropping disconnected channel

['Lidi Zheng' via grpc.io]

AFAIK, the transparent retries is not fully implemented.

The feature you want probably is "wait_for_ready
". In
case of TRANSIENT_FAILURE (server not available temporarily), it will
automatically wait for the channel become READY again without failing. Read
more

about
wait for ready.

Lidi Zheng

On Mon, Apr 15, 2019 at 11:41 AM Manatsawin Hanmongkolchai <
manatsa...@gmail.com> wrote:

> Thank you for your answer Lidi and Sidhartha,
>
> I've updated the code in GitHub repository to gracefully stop server.
> Unfortunately, the same problem still occurs.
> Previously I also have tested the same issue using Python client and a
> Go server (stopping by manually ctrl+c the server) which also has the
> same problem.
>
> In proposal A6 section "Transparent Retries" mentions that in case of
> RPC failure which RPC never leaves the client, it will be retried
> automatically.
> I've confirmed using Wireshark that the RPC never got sent out in the
> wire, and there is only 2 outgoing calls (no retry).
> I'm not sure whether the proposal is implemented or I have to set a
> settings somewhere?
>
> On Tue, Apr 16, 2019 at 1:17 AM Lidi Zheng  wrote:
> >
> > gRPC Python server can be closed by "server.stop()".
> >
> > Underlying, the gRPC Python server has a background polling thread. The
> deallocation of the server object is not directly terminating the polling
> thread since there is no way to interrupt thread in Python. So, during the
> server deallocation, it will set a destruction flag, and if the polling
> thread sees the flag it will terminate itself. It's possible that there are
> some lag before the server completely shuts down. To eliminate this issue,
> we recommend you close the server explicitly by "server.stop()" which will
> block until the server is completely shut down.
> >
> > Lidi Zheng
> >
> > On Mon, Apr 15, 2019 at 11:09 AM Sidhartha Thota 
> wrote:
> >>
> >> This is known issue afaik. May be your issue is related to this one:
> https://github.com/grpc/grpc/issues/9767
> >>
> >> If the connection is down the session will not be re-useful but channel
> is always useful. Here session is individual RPC/Streaming RPC call. So,
> when session is in progress and connection is down then session cannot be
> restored. Channel is different and maintains connection with other end
> (here server) and retries to connect periodically so it takes time to
> reconnect to to server.
> >>
> >>
> >>
> >> On Mon, Apr 15, 2019 at 8:49 AM  wrote:
> >>>
> >>> Steps to reproduce
> >>>
> >>> 1. Start server
> >>> 2. Send a client RPC to server
> >>> 3. Restart server
> >>> 4. Using the same client, send another RPC. The call will fail
> >>> 5. Send another RPC, this call will success
> >>>
> >>> Also I found that if the server is leave stopped for a long time
> before starting up again, the call in step 5 will return "channel is in
> state TRANSIENT_FAILURE" as well.
> >>>
> >>> Example code: https://github.com/whs/grpc-repro
> >>> (Install from requirements.txt then run main.py)
> >>>
> >>> Expected result
> >>>
> >>> All call should success.
> >>>
> >>> Tested with Python grpcio==1.19.0 server/client and with go-grpc
> server. I tried setting grpc.max_connection_age_grace_ms,
> grpc.max_connection_age_ms, grpc.max_connection_idle_ms,
> grpc.keepalive_time_ms, grpc.keepalive_permit_without_calls but they
> doesn't seems to help.
> >>>
> >>> From my own investigation, I believe that gRPC channels doesn't drop
> closed channels and tries to send calls in closed channel. There is also
> TCP RST sent.
> >>>
> >>> --
> >>> 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 post to this group, send email to grpc-io@googlegroups.com.
> >>> Visit this group at https://groups.google.com/group/grpc-io.
> >>> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/e8465f2b-96f1-4ad1-816f-ee6521595179%40googlegroups.com
> .
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> >>
> >> --
> >> Thanks,
> >> Sidhartha Thota.
> >>
> >> --
> >> 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 post to this group, send email to grpc-io@googlegroups.com.
> >> Visit this group at https://groups.google.com/group/grpc-io.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/CALguN-Gg0iiDSEUrO-VEOuGu5Mhemc9bZVqxqi_BcY7-pc%3DQWg%40mail.gmail.com
> .
> >> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are 

Re: [grpc-io] gRPC not dropping disconnected channel

['Lidi Zheng' via grpc.io]

gRPC Python server can be closed by "server.stop()".

Underlying, the gRPC Python server has a background polling thread. The
deallocation of the server object is not directly terminating the polling
thread since there is no way to interrupt thread in Python. So, during the
server deallocation, it will set a destruction flag, and if the polling
thread sees the flag it will terminate itself. It's possible that there are
some lag before the server completely shuts down. To eliminate this issue,
we recommend you close the server explicitly by "server.stop()" which will
block until the server is completely shut down.

Lidi Zheng

On Mon, Apr 15, 2019 at 11:09 AM Sidhartha Thota 
wrote:

> This is known issue afaik. May be your issue is related to this one:
> https://github.com/grpc/grpc/issues/9767
>
> If the connection is down the session will not be re-useful but channel is
> always useful. Here session is individual RPC/Streaming RPC call. So, when
> session is in progress and connection is down then session cannot be
> restored. Channel is different and maintains connection with other end
> (here server) and retries to connect periodically so it takes time to
> reconnect to to server.
>
>
>
> On Mon, Apr 15, 2019 at 8:49 AM  wrote:
>
>> Steps to reproduce
>>
>> 1. Start server
>> 2. Send a client RPC to server
>> 3. Restart server
>> 4. Using the same client, send another RPC. The call will fail
>> 5. Send another RPC, this call will success
>>
>> Also I found that if the server is leave stopped for a long time before
>> starting up again, the call in step 5 will return "channel is in state
>> TRANSIENT_FAILURE" as well.
>>
>> Example code: https://github.com/whs/grpc-repro
>> (Install from requirements.txt then run main.py)
>>
>> Expected result
>>
>> All call should success.
>>
>> Tested with Python grpcio==1.19.0 server/client and with go-grpc server.
>> I tried
>> setting grpc.max_connection_age_grace_ms, grpc.max_connection_age_ms, 
>> grpc.max_connection_idle_ms, grpc.keepalive_time_ms, 
>> grpc.keepalive_permit_without_calls
>> but they doesn't seems to help.
>>
>> From my own investigation, I believe that gRPC channels doesn't drop
>> closed channels and tries to send calls in closed channel. There is also
>> TCP RST sent.
>>
>> --
>> 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 post to this group, send email to grpc-io@googlegroups.com.
>> Visit this group at https://groups.google.com/group/grpc-io.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/grpc-io/e8465f2b-96f1-4ad1-816f-ee6521595179%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Thanks,
> Sidhartha Thota.
>
> --
> 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 post to this group, send email to grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/CALguN-Gg0iiDSEUrO-VEOuGu5Mhemc9bZVqxqi_BcY7-pc%3DQWg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAMC1%3DjdAO13aORdiXSv2R%3DVYRmTHQHkd9Di3nXztKwYSPvQfwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: Python Rendezvous exception when running python server, python client and C++ client on the same PC

['Lidi Zheng' via grpc.io]

Hi Alex,

I'm glad to see the problem is finally going away. Sorry that I can't track
down this issue in Windows.
And there are many possibilities to cause that behavior, might related to
underlying file descriptors, the garbage collections, fork+exec issue.
I don't have an answer.

In addition, the details you posted here is more than enough to file a bug
report.
It would be great if you can submit an issue in Github where we can revisit
this issue when we got resources.
https://github.com/grpc/grpc/issues/new

Thanks,
Lidi Zheng



On Tue, Apr 2, 2019 at 3:38 AM Alejandro Villagrán 
wrote:

> Hi,
>
> The subprocess is finishing OK, almost immediately as it's not doing
> anything apart from printing a message to the console. "subprocess.call"
> returns a status code 0. So everything should be fine on that side.
> Not 100% sure what you meant with tracing the lifecycle of the channel. I
> called grpc.Channel.subscribe to print the different states of the channel
> used:
>
> *def stateChange(conn):*
> *   print conn*
>
> *class GRPCStub(object):*
> *   def __init__(self):*
> *  self.channel = grpc.insecure_channel('127.0.0.1:50051
> ')*
> *  self.channel.subscribe(stateChange)*
> *  self.stub = Test_pb2_grpc.GRPCTestStub(self.channel)*
>
> With that call to subscribe, the exception is no longer thrown. The
> channel starts IDLE and then changes to READY as soon as the first grpc
> call is made and stays like that for the rest of the program.
>
> It'd be interesting if you could reproduce it on your end to see what's
> really happening under the bonnet. Why would that call to
> grpc.Channel.subscribe will prevent the exception from being raised?
>
> Thanks,
> Alex.
>
> On Mon, 1 Apr 2019 at 22:32, Lidi Zheng  wrote:
>
>> Hi Alex,
>>
>> From the log, I found the error is located at client-side. The gRPC
>> client sends reset stream frame with error code 2 indicating internal
>> error, and its channel state somehow becomes SHUTDOWN.
>> Also, I tried your code in Linux, it works fine without any error. I had
>> another failed attempt to build the VS solution with 400+ errors...
>>
>> Although the root cause still remained unclear, the scope is reduced to
>> the gRPC client behavior on Windows. To dig deeper into the bug, I think
>> one have to trace if the "subprocess" finishes and the life cycle of
>> channel.
>>
>> Lidi Zheng
>>
>> On Mon, Apr 1, 2019 at 7:55 AM Alejandro Villagrán 
>> wrote:
>>
>>> Hi Lidi,
>>>
>>> I've set those environment variables you mentioned and I've attached the
>>> log files (serverlog.txt and clientlog.txt).
>>> Since I reported this issue, I've upgrade the Python version of gRPC, so
>>> the attached log files were created with grpcio 1.19.0
>>>
>>> Do they give you any hint as to what could be wrong?
>>>
>>> Thanks,
>>> Alex.
>>>
>>> On Thu, 28 Mar 2019 at 17:07, Alejandro Villagrán 
>>> wrote:
>>>
 Hi Lidi,

 In the last version of the code I attached, I don't use CherryPy
 anymore so the issue cannot come from there. Eric said that fork handlers
 are not registered on Windows so he ruled out that option too.
 Unfortunately I haven't got access to a Linux machine and I'm not
 familiar enough with Linux to be able to recreate the issue there.

 I did use turn on the debug trace a few weeks ago but I couldn't see
 anything obvious. I'll find time to enable them again and share the logs
 with you.

 Thanks,
 Alex.

 On Thu, 28 Mar 2019 at 16:55, Lidi Zheng  wrote:

> My apologies Alex. There are other stuff keep come up and consumed my
> time. I'm not a Windows expert, it will take me a long time to setup the
> compilation environment for gRPC in Windows with debugger. And I failed to
> find a Windows expert to debug your issue.
> Eric has mentioned that the breakage can be caused by either fork
> handlers registration or CherryPy. Do you think you can migrate the
> reproduce case to Linux, if the root cause is the software? It would be
> much easier to debug.
> Also, have you tried to turn on the debug trace in gRPC by setting 
> environmental
> variables
> 
> "*GRPC_VERBOSITY*" to "*DEBUG*", and "*GRPC_TRACE*" to "
> *api,channel,connectivity_state*"? They might produce useful
> information for us to identify the problem.
>
> Thanks,
> Lidi Zheng
>
> On Thu, Mar 28, 2019 at 3:47 AM Alejandro Villagrán <
> negral...@gmail.com> wrote:
>
>> Hi Lidi,
>>
>> Did you manage to reproduce the issue?
>>
>> Thanks,
>> Alex.
>>
>> On Tue, 19 Mar 2019 at 01:06, Lidi Zheng  wrote:
>>
>>> Hi Alex,
>>>
>>> Thank you for providing the reproduce code. I will spin up a Windows
>>> machine to investigate this error.
>>> If I'm able to find something useful, I'll let you know.
>>>

Re: [grpc-io] Re: Python Rendezvous exception when running python server, python client and C++ client on the same PC

['Lidi Zheng' via grpc.io]

Hi Alex,

>From the log, I found the error is located at client-side. The gRPC client
sends reset stream frame with error code 2 indicating internal error, and
its channel state somehow becomes SHUTDOWN.
Also, I tried your code in Linux, it works fine without any error. I had
another failed attempt to build the VS solution with 400+ errors...

Although the root cause still remained unclear, the scope is reduced to the
gRPC client behavior on Windows. To dig deeper into the bug, I think one
have to trace if the "subprocess" finishes and the life cycle of channel.

Lidi Zheng

On Mon, Apr 1, 2019 at 7:55 AM Alejandro Villagrán 
wrote:

> Hi Lidi,
>
> I've set those environment variables you mentioned and I've attached the
> log files (serverlog.txt and clientlog.txt).
> Since I reported this issue, I've upgrade the Python version of gRPC, so
> the attached log files were created with grpcio 1.19.0
>
> Do they give you any hint as to what could be wrong?
>
> Thanks,
> Alex.
>
> On Thu, 28 Mar 2019 at 17:07, Alejandro Villagrán 
> wrote:
>
>> Hi Lidi,
>>
>> In the last version of the code I attached, I don't use CherryPy anymore
>> so the issue cannot come from there. Eric said that fork handlers are not
>> registered on Windows so he ruled out that option too.
>> Unfortunately I haven't got access to a Linux machine and I'm not
>> familiar enough with Linux to be able to recreate the issue there.
>>
>> I did use turn on the debug trace a few weeks ago but I couldn't see
>> anything obvious. I'll find time to enable them again and share the logs
>> with you.
>>
>> Thanks,
>> Alex.
>>
>> On Thu, 28 Mar 2019 at 16:55, Lidi Zheng  wrote:
>>
>>> My apologies Alex. There are other stuff keep come up and consumed my
>>> time. I'm not a Windows expert, it will take me a long time to setup the
>>> compilation environment for gRPC in Windows with debugger. And I failed to
>>> find a Windows expert to debug your issue.
>>> Eric has mentioned that the breakage can be caused by either fork
>>> handlers registration or CherryPy. Do you think you can migrate the
>>> reproduce case to Linux, if the root cause is the software? It would be
>>> much easier to debug.
>>> Also, have you tried to turn on the debug trace in gRPC by setting 
>>> environmental
>>> variables
>>> 
>>> "*GRPC_VERBOSITY*" to "*DEBUG*", and "*GRPC_TRACE*" to "
>>> *api,channel,connectivity_state*"? They might produce useful
>>> information for us to identify the problem.
>>>
>>> Thanks,
>>> Lidi Zheng
>>>
>>> On Thu, Mar 28, 2019 at 3:47 AM Alejandro Villagrán 
>>> wrote:
>>>
 Hi Lidi,

 Did you manage to reproduce the issue?

 Thanks,
 Alex.

 On Tue, 19 Mar 2019 at 01:06, Lidi Zheng  wrote:

> Hi Alex,
>
> Thank you for providing the reproduce code. I will spin up a Windows
> machine to investigate this error.
> If I'm able to find something useful, I'll let you know.
>
> Lidi Zheng
>
> On Mon, Mar 18, 2019 at 4:09 AM Alejandro Villagrán <
> negral...@gmail.com> wrote:
>
>> Hi Eric/Lidi,
>>
>> Yes, I'm running on Windows. I have now removed the CherryPy code and
>> I still get the exception.
>>
>> Please follow these steps to reproduce the issue:
>> - Unzip ReproduceGRPCIssue.zip
>> - Go to the BreakGRPC folder and compile BreakGRPC.sln. Make sure
>> BreakGRPC.exe is saved in BreakGRPC/x64/Release.
>> - Go to the Services/src folder and open two command prompts there.
>> - Run "python GRPCserver.py" in one command prompt.
>> - Run "python GRPCclient.py" in the other command prompt.
>>
>> You should see the exception on the client command prompt.
>>
>> Please let me know if you are still unable to reproduce the issue
>> with this version of the code.
>>
>> Thanks,
>> Alex.
>>
>> On Mon, 4 Mar 2019 at 17:04, Eric Gribkoff 
>> wrote:
>>
>>> +Lidi Zheng , who will be available for any
>>> follow-up questions (it will be easier for him to notice your questions 
>>> if
>>> you include his email address on the "to:" line)
>>>
>>> Hi Alex,
>>>
>>> Sorry for the delay. I was not able to reproduce the problem; it
>>> looks like you are running on Windows, in which case gRPC's fork 
>>> handlers
>>> are not registered/run, so those shouldn't be the cause here . Since the
>>> reproduction example also uses CherryPy websockets, it's quite possible 
>>> the
>>> issue stems from that software rather than the gRPC stack - we'd likely
>>> need a reproduction case that only uses gRPC, without the websockets, 
>>> to be
>>> able to help debug this further.
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>> On Mon, Mar 4, 2019 at 2:36 AM Alex  wrote:
>>>
 Hi Eric,

 Just wondering if you had time to run my attached example 

Re: [grpc-io] Re: Python Rendezvous exception when running python server, python client and C++ client on the same PC

['Lidi Zheng' via grpc.io]

My apologies Alex. There are other stuff keep come up and consumed my time.
I'm not a Windows expert, it will take me a long time to setup the
compilation environment for gRPC in Windows with debugger. And I failed to
find a Windows expert to debug your issue.
Eric has mentioned that the breakage can be caused by either fork handlers
registration or CherryPy. Do you think you can migrate the reproduce case
to Linux, if the root cause is the software? It would be much easier to
debug.
Also, have you tried to turn on the debug trace in gRPC by setting
environmental
variables
 "
*GRPC_VERBOSITY*" to "*DEBUG*", and "*GRPC_TRACE*" to "
*api,channel,connectivity_state*"? They might produce useful information
for us to identify the problem.

Thanks,
Lidi Zheng

On Thu, Mar 28, 2019 at 3:47 AM Alejandro Villagrán 
wrote:

> Hi Lidi,
>
> Did you manage to reproduce the issue?
>
> Thanks,
> Alex.
>
> On Tue, 19 Mar 2019 at 01:06, Lidi Zheng  wrote:
>
>> Hi Alex,
>>
>> Thank you for providing the reproduce code. I will spin up a Windows
>> machine to investigate this error.
>> If I'm able to find something useful, I'll let you know.
>>
>> Lidi Zheng
>>
>> On Mon, Mar 18, 2019 at 4:09 AM Alejandro Villagrán 
>> wrote:
>>
>>> Hi Eric/Lidi,
>>>
>>> Yes, I'm running on Windows. I have now removed the CherryPy code and I
>>> still get the exception.
>>>
>>> Please follow these steps to reproduce the issue:
>>> - Unzip ReproduceGRPCIssue.zip
>>> - Go to the BreakGRPC folder and compile BreakGRPC.sln. Make sure
>>> BreakGRPC.exe is saved in BreakGRPC/x64/Release.
>>> - Go to the Services/src folder and open two command prompts there.
>>> - Run "python GRPCserver.py" in one command prompt.
>>> - Run "python GRPCclient.py" in the other command prompt.
>>>
>>> You should see the exception on the client command prompt.
>>>
>>> Please let me know if you are still unable to reproduce the issue with
>>> this version of the code.
>>>
>>> Thanks,
>>> Alex.
>>>
>>> On Mon, 4 Mar 2019 at 17:04, Eric Gribkoff 
>>> wrote:
>>>
 +Lidi Zheng , who will be available for any
 follow-up questions (it will be easier for him to notice your questions if
 you include his email address on the "to:" line)

 Hi Alex,

 Sorry for the delay. I was not able to reproduce the problem; it looks
 like you are running on Windows, in which case gRPC's fork handlers are not
 registered/run, so those shouldn't be the cause here . Since the
 reproduction example also uses CherryPy websockets, it's quite possible the
 issue stems from that software rather than the gRPC stack - we'd likely
 need a reproduction case that only uses gRPC, without the websockets, to be
 able to help debug this further.

 Thanks,

 Eric

 On Mon, Mar 4, 2019 at 2:36 AM Alex  wrote:

> Hi Eric,
>
> Just wondering if you had time to run my attached example and managed
> to reproduce the problem?
>
> Thanks,
> Alex.
>
> On Wednesday, February 20, 2019 at 7:04:51 PM UTC, Eric Gribkoff wrote:
>>
>> Can you post the code you're using to reproduce this error? If you're
>> using subprocess.Popen (or otherwise using fork+exec) to start the C++ 
>> grpc
>> client process, the C++ client itself cannot be interfering with the 
>> Python
>> process. Something could be going wrong in the gRPC core fork handlers,
>> however - you can try running with the environment variable
>> `GRPC_ENABLE_FORK_SUPPORT=0` to disable this feature and see if it fixes
>> the issue.
>>
>> Also, in your step 5 you note that the C++ client isn't communicating
>> with the server. If you remove the fork+exec of a C++ subprocess
>> altogether, do you still see this intermittent exception in the Python
>> client?
>>
>> Eric
>>
>> On Wed, Feb 20, 2019 at 6:57 AM Alex  wrote:
>>
>>> I should add that the Python client application which owns the
>>> Python grpc client is the one that runs the C++ grpc client as a 
>>> subprocess
>>> in case that makes a difference.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "grpc.io" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to grpc-io+u...@googlegroups.com.
>>> To post to this group, send email to grp...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/grpc-io.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/b323fac3-978b-47c1-b1fa-555c2f62b544%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You 

Re: [grpc-io] Re: Python server not respecting timeout?

['Lidi Zheng' via grpc.io]

Your second post has a tiny typo I think. To pass a Python function as
parameter, you don't need the parentheses:

context.add_callback(context.cancel)

Also, the callbacks added to the context will only execute after the gRPC
termination. By that time, the "context.cancel" will be a no-op.

About your first question regarding to deadline. The deadline exceeded in
client-side will cancel the server-side request, but it is not cancelled
automatically since there is no (legit) way in Python to terminate a
running thread. If you would like to terminate your server task, please
explicitly check the "is_active()" function in servicer context.

Hope this will answer your questions :)






On Tue, Mar 19, 2019 at 10:32 AM  wrote:

> In addition, it seems like the callback functionality should be able
> handle this through something like this ...
>
> Server pseudo-code:
>
> def Server(self, request_iterator, context):
> context.add_callback(context.cancel())
> for request in request_iterator:
> pass
>
> for _ in range(10):
> time.sleep(1)
>
> print(context.is_active())
> print('still running!')
> return test_pb2.Response()
>
> ... however, this immediately cancels the RPC, which seems to disagree
> with the intended behavior described in the documentation:
> https://grpc.io/grpc/python/grpc.html#grpc.RpcContext.add_callback
>
> On Tuesday, March 19, 2019 at 9:48:53 AM UTC-7, liburdi...@gmail.com
> wrote:
>>
>> I want to verify some behavior in the Python code -- are timeouts only
>> respected while receiving requests and not after requests have been
>> received (but RPC is not finished)? Here's an example that uses a
>> client-streaming RPC:
>>
>> Server pseudo-code:
>>
>> def Server(self, request_iterator, context):
>> for request in request_iterator:
>> pass
>>
>> for _ in range(10):
>> time.sleep(1)
>>
>> print(context.is_active())
>> print('still running!')
>> return test_pb2.Response()
>>
>>
>> Client pseudo-code:
>>
>> def yielder():
>> for _ in range(20):
>> yield test_pb2.Request()
>>
>> stub = test_pb2_grpc.TestStub(channel)
>> response = stub.Server(yielder(), timeout=5)
>> print(response)
>>
>>
>> What happens is that the server will receive all the requests streams and
>> while performing an operation, the timeout will pass and context will be
>> inactive -- however, the RPC never aborts (i.e. the server will print
>> 'still running!'). Is this intended behavior? I would expect that the
>> server to stop processing after the timeout has elapsed.
>>
> --
> 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 post to this group, send email to grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/a9d19d24-75d0-459f-ac51-c15a4d02422e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAMC1%3Djd_T4rr8owP4tu23-30RZXsqYAd16b0a2UhK8T_o3%3D9tA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: Python Rendezvous exception when running python server, python client and C++ client on the same PC

['Lidi Zheng' via grpc.io]

Hi Alex,

Thank you for providing the reproduce code. I will spin up a Windows
machine to investigate this error.
If I'm able to find something useful, I'll let you know.

Lidi Zheng

On Mon, Mar 18, 2019 at 4:09 AM Alejandro Villagrán 
wrote:

> Hi Eric/Lidi,
>
> Yes, I'm running on Windows. I have now removed the CherryPy code and I
> still get the exception.
>
> Please follow these steps to reproduce the issue:
> - Unzip ReproduceGRPCIssue.zip
> - Go to the BreakGRPC folder and compile BreakGRPC.sln. Make sure
> BreakGRPC.exe is saved in BreakGRPC/x64/Release.
> - Go to the Services/src folder and open two command prompts there.
> - Run "python GRPCserver.py" in one command prompt.
> - Run "python GRPCclient.py" in the other command prompt.
>
> You should see the exception on the client command prompt.
>
> Please let me know if you are still unable to reproduce the issue with
> this version of the code.
>
> Thanks,
> Alex.
>
> On Mon, 4 Mar 2019 at 17:04, Eric Gribkoff 
> wrote:
>
>> +Lidi Zheng , who will be available for any follow-up
>> questions (it will be easier for him to notice your questions if you
>> include his email address on the "to:" line)
>>
>> Hi Alex,
>>
>> Sorry for the delay. I was not able to reproduce the problem; it looks
>> like you are running on Windows, in which case gRPC's fork handlers are not
>> registered/run, so those shouldn't be the cause here . Since the
>> reproduction example also uses CherryPy websockets, it's quite possible the
>> issue stems from that software rather than the gRPC stack - we'd likely
>> need a reproduction case that only uses gRPC, without the websockets, to be
>> able to help debug this further.
>>
>> Thanks,
>>
>> Eric
>>
>> On Mon, Mar 4, 2019 at 2:36 AM Alex  wrote:
>>
>>> Hi Eric,
>>>
>>> Just wondering if you had time to run my attached example and managed to
>>> reproduce the problem?
>>>
>>> Thanks,
>>> Alex.
>>>
>>> On Wednesday, February 20, 2019 at 7:04:51 PM UTC, Eric Gribkoff wrote:

 Can you post the code you're using to reproduce this error? If you're
 using subprocess.Popen (or otherwise using fork+exec) to start the C++ grpc
 client process, the C++ client itself cannot be interfering with the Python
 process. Something could be going wrong in the gRPC core fork handlers,
 however - you can try running with the environment variable
 `GRPC_ENABLE_FORK_SUPPORT=0` to disable this feature and see if it fixes
 the issue.

 Also, in your step 5 you note that the C++ client isn't communicating
 with the server. If you remove the fork+exec of a C++ subprocess
 altogether, do you still see this intermittent exception in the Python
 client?

 Eric

 On Wed, Feb 20, 2019 at 6:57 AM Alex  wrote:

> I should add that the Python client application which owns the Python
> grpc client is the one that runs the C++ grpc client as a subprocess in
> case that makes a difference.
>
> --
> You received this message because you are subscribed to the Google
> Groups "grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to grpc-io+u...@googlegroups.com.
> To post to this group, send email to grp...@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/b323fac3-978b-47c1-b1fa-555c2f62b544%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "grpc.io" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to grpc-io+unsubscr...@googlegroups.com.
>>> To post to this group, send email to grpc-io@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/grpc-io.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/af4d55fa-a5e0-4e3f-a5ad-9cb62378703d%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAMC1%3Dje6r4_s-J_YCQf9Mvo7t%2B57k3SCH4sdY7PFPdYhBwgWQA%40mail.gmail.com.
For more options, visit 

Re: [grpc-io] Python gRPC cancel unary-stream call from client side

['Lidi Zheng' via grpc.io]

Can you try “stream.cancel()”? The “cancel()” method is available for both
client context and server context. See *class *grpc.*RpcContext in *
*https://grpc.io/grpc/python/grpc.html#client-side-context
.*

On Thu, Mar 14, 2019 at 23:54 Mark Nuttall-Smith 
wrote:

> Hi,
>
> Using Python gRPC, I would like to be able to cancel a long-running
> unary-stream call from the client side, when a `threading.Event` is set.
>
> def application(stub: StreamsStub, event: threading.Event):
> stream = stub.Application(ApplicationStreamRequest())
> try:
> for resp in stream:
> print(resp)
> except grpc.RpcError as e:
> print(e)
>
> For the time being I am cancelling the stream using the `channel.close()`
> method, but of course this closes all connections rather than just this
> stream.
>
> Could someone suggest how I can use the event to cancel the stream
> iterator?
>
> Thanks, Mark
>
> (cross post from SO:
> https://stackoverflow.com/questions/55160210/python-grpc-cancel-unary-stream-call-from-client-side
> )
>
> --
> 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 post to this group, send email to grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/2b7ed001-d5b9-452b-b4dd-fbcb905687b3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAMC1%3DjcE6VKNWsmx90d--qsSFcc5c1U4_Xy%3D8mSWLsauk3ueGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Kill server task if client disconnects? (python)

['Lidi Zheng' via grpc.io]

That's kind of unfortunate, the server-side fork support seems not
happening soon. Here is the issue #16001
 to track the progress of
server-side fork support.
Please left a comment in that PR, if this feature is critical for you.
Hopefully, its prioritization can be increased.

On Thu, Feb 28, 2019 at 5:49 PM Josh Liburdi 
wrote:

> Agreed that my problem goes beyond the scope of gRPC, I was mostly curious
> if you had any creative ideas for handling this (and thanks for the ones
> you shared). The only thing, I think, gRPC could do to help in these cases
> is allow RPCs to be handled by processes and not threads.
>
> On Thu, Feb 28, 2019 at 5:30 PM lidiz via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> You question is beyond gRPC framework, and one cannot interrupt thread
>> has been a headache for Python (and programming languages with
>> multi-threading) for a long time.
>>
>> Alternatively, you could:
>>
>> 1) Have the server thread instead of sleep for a complete 5 minute, you
>> can break it down to like 1 second and check for termination flag. The
>> termination flag can be flipped by other threads.
>> 2) If the job you run can be ran with "subprocess", then it will be
>> easier to control its life cycle.
>> 3) Wrap your job with Python one of "Future" implementation.
>> 4̶)̶ ̶I̶n̶v̶o̶k̶e̶ ̶C̶P̶y̶t̶h̶o̶n̶ ̶C̶ ̶A̶P̶I̶
>> ̶P̶y̶T̶h̶r̶e̶a̶d̶S̶t̶a̶t̶e̶_̶S̶e̶t̶A̶s̶y̶n̶c̶E̶x̶c̶
>> .̶
>>
>>
>>
>> On Thursday, February 28, 2019 at 5:14:18 PM UTC-8, Josh Liburdi wrote:
>>>
>>> That is a good example of using the callback! Where I get stuck is the
>>> first example you mentioned, cancelling the running job. A simulation of my
>>> problem would be to have the server perform a very long task (e.g. 5 minute
>>> sleep call); in those cases, I would need the callback to interrupt/cancel
>>> that sleep call. Usually I would handle this with signals and setting an
>>> explicit timer in the server process, but (from what I’ve seen and read)
>>> signals cannot be used in threads.
>>>
>>> On Thu, Feb 28, 2019 at 4:48 PM lidiz via grpc.io <
>>> grp...@googlegroups.com> wrote:
>>>
>> I wrote an example about the "add_callback" API last December after
 reading this thread: https://github.com/grpc/grpc/pull/17551. But I
 haven't really push to merge that pull request.
 You can add your special logic in the server-side callback, like cancel
 the running job, log metrics, and other stuff.
 Please take a look at the example, and let me know if it failed to
 solve your question.


 On Thursday, February 28, 2019 at 4:32:07 PM UTC-8,
 liburdi...@gmail.com wrote:
>
> Out of curiosity, can anyone show an example of how add_callback can
> be used to interrupt the server-side process? I have the same problem as
> the OP for my application -- server-side can run for a very long time and
> if the client times out, then I need the server to cancel immediately. 
> I've
> tried a variety of techniques, but I cannot get the callback function to
> stop the server-side call.
>
> On Tuesday, December 18, 2018 at 12:51:23 PM UTC-8, vbp...@gmail.com
> wrote:
>>
>> Ah; thanks--we're having to use subprocess.Popen in a few cases
>> anyway.  I'll try that and see what we can do.  Thanks for the note on
>> "grpc within grpc"; that may simplify some things too.
>>
>> On Tuesday, December 18, 2018 at 1:07:00 PM UTC-6, Eric Gribkoff
>> wrote:
>>>
>>>
>>>
>>> On Tue, Dec 18, 2018 at 10:45 AM  wrote:
>>>
 Thanks, Eric.  That makes some degree of sense, although there are
 a few cases we still won't be able to deal with, I suspect (and we may 
 have
 trouble later anyway... in some cases our server program has to shell 
 out
 to run a separate program, and if that runs into the fork trouble and 
 can't
 be supported by GRPC we may be stuck with a very clanky REST
 implementation).


>>> Sorry, I should have been more precise in my earlier response: you
>>> are fine to use fork+exec (e.g., subprocess.Popen) to run a separate
>>> program in a new shell. (Caveat: we had a bug
>>>  that may cause problems
>>> even with fork+exec when using Python3. The fix is now merged and will 
>>> be
>>> in the next release; our nightly builds will also include the fix 
>>> ~tomorrow
>>> if you are hitting this issue). The issues on the server-side with fork
>>> arise when using libraries that fork and, rather than exec'ing a new
>>> program, continue to run the original program in the child process, 
>>> e.g.,
>>> Python's multiprocessing module.
>>>
>>>
>>>
 Hmm, quite a pickle.  I can see I'll be playing with a bunch of 

Re: [grpc-io] Scala to Python using gRPC

['Lidi Zheng' via grpc.io]

Hi S Sathish Babu,

In that case, you want to keep your main thread alive after you dispatched
your premises. I presume in Scala the "Future" works fine with
"Thread.sleep"? If so, you may block your main thread by explicitly calling
"Thread.sleep" at the end of your main function, and your premises will be
executed asynchronously.

Cheers,
Lidi Zheng

On Wed, Jan 30, 2019 at 8:07 PM S SATHISH BABU 
wrote:

> Hello Lidi Zheng,
>
> Thanks for the response. As you said,using "Await.ready" or "Await.block"
> will block the program and return me the result. In my case, I want it to
> execute asynchronously. There should be no blocking. Let the server return
> the response when it has finished computing. Is that possible?
>
> Regards,
> S Sathish Babu
>
> On Wednesday, 30 January 2019 23:37:04 UTC+5:30, Lidi Zheng wrote:
>>
>> Hello,
>>
>> The Scala client is exiting too quick that the future is not yet
>> completed. You may use "Await.ready" or "Await.result" to explicitly block
>> the program.
>>
>> Cheers,
>> Lidi Zheng
>>
>> On Tue, Jan 29, 2019 at 10:58 PM S SATHISH BABU 
>> wrote:
>>
>>> Hello,
>>> I am making a communication between my Scala gRPC client and python
>>> gRPC server. My issue is when I make a blocking call from scala client, my
>>> request is handled. But in case of asynchronous stub, the request is not
>>> delivered at all. Can anyone help me out with this?.
>>>
>>> Python gRPC server code
>>>
>>> from gRPC2 import message_pb2, message_pb2_grpc
>>> import grpc
>>> from concurrent import futures
>>> import time
>>>
>>>
>>> class HandlerServicer(message_pb2_grpc.HandlerServicer):
>>>
>>> def request_handler(self, request, context):
>>> print('Received request:', request, request.request_message)
>>> response = 'Reponse'
>>> time.sleep(10)
>>> return message_pb2.Response(response_message=response)
>>>
>>>
>>> handler_server = grpc.server(futures.ThreadPoolExecutor())
>>> message_pb2_grpc.add_HandlerServicer_to_server(HandlerServicer(), 
>>> handler_server)
>>> handler_server.add_insecure_port("[::]:{}".format(5000))
>>>
>>> print('Starting server...')
>>> handler_server.start()
>>> try:
>>> while True:
>>> time.sleep(60*60*60)
>>> except KeyboardInterrupt:
>>> print('Stopping server...')
>>> handler_server.stop(0)
>>>
>>>
>>> Scala gRPC client code:
>>>
>>> import io.grpc.ManagedChannelBuilder
>>> import message._
>>>
>>> import scala.concurrent.Future
>>> import scala.concurrent.ExecutionContext
>>>
>>> object HandlerClient extends App {
>>>
>>>   val channel = ManagedChannelBuilder.forAddress("localhost", 
>>> 5000).usePlaintext().build()
>>>   val request = Request("Request")
>>>   implicit val ec = ExecutionContext.global
>>>
>>>   // Making a Async call
>>>   val stub = HandlerGrpc.stub(channel)
>>>   val future = stub.requestHandler(request)
>>>   future onComplete println
>>> }
>>>
>>>
>>>
>>> Proto file:
>>>
>>> syntax = "proto3";
>>>
>>> service Handler{
>>> rpc request_handler(Request) returns (Response){}
>>> }
>>>
>>> message Request{
>>> string request_message = 1;
>>> }
>>>
>>> message Response{
>>> string response_message = 1;
>>> }
>>>
>>>
>>> Thanks,
>>> S Sathish Babu
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "grpc.io" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to grpc-io+u...@googlegroups.com.
>>> To post to this group, send email to grp...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/grpc-io.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/grpc-io/4ce6fa34-b5a5-49d0-9296-b6c25cdc33ae%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to grpc-io+unsubscr...@googlegroups.com.
> To post to this group, send email to grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/2000128c-39d2-44ea-82f0-e9c5af3ed07e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view 

Re: [grpc-io] Scala to Python using gRPC

['Lidi Zheng' via grpc.io]

Hello,

The Scala client is exiting too quick that the future is not yet completed.
You may use "Await.ready" or "Await.result" to explicitly block the program.

Cheers,
Lidi Zheng

On Tue, Jan 29, 2019 at 10:58 PM S SATHISH BABU 
wrote:

> Hello,
> I am making a communication between my Scala gRPC client and python
> gRPC server. My issue is when I make a blocking call from scala client, my
> request is handled. But in case of asynchronous stub, the request is not
> delivered at all. Can anyone help me out with this?.
>
> Python gRPC server code
>
> from gRPC2 import message_pb2, message_pb2_grpc
> import grpc
> from concurrent import futures
> import time
>
>
> class HandlerServicer(message_pb2_grpc.HandlerServicer):
>
> def request_handler(self, request, context):
> print('Received request:', request, request.request_message)
> response = 'Reponse'
> time.sleep(10)
> return message_pb2.Response(response_message=response)
>
>
> handler_server = grpc.server(futures.ThreadPoolExecutor())
> message_pb2_grpc.add_HandlerServicer_to_server(HandlerServicer(), 
> handler_server)
> handler_server.add_insecure_port("[::]:{}".format(5000))
>
> print('Starting server...')
> handler_server.start()
> try:
> while True:
> time.sleep(60*60*60)
> except KeyboardInterrupt:
> print('Stopping server...')
> handler_server.stop(0)
>
>
> Scala gRPC client code:
>
> import io.grpc.ManagedChannelBuilder
> import message._
>
> import scala.concurrent.Future
> import scala.concurrent.ExecutionContext
>
> object HandlerClient extends App {
>
>   val channel = ManagedChannelBuilder.forAddress("localhost", 
> 5000).usePlaintext().build()
>   val request = Request("Request")
>   implicit val ec = ExecutionContext.global
>
>   // Making a Async call
>   val stub = HandlerGrpc.stub(channel)
>   val future = stub.requestHandler(request)
>   future onComplete println
> }
>
>
>
> Proto file:
>
> syntax = "proto3";
>
> service Handler{
> rpc request_handler(Request) returns (Response){}
> }
>
> message Request{
> string request_message = 1;
> }
>
> message Response{
> string response_message = 1;
> }
>
>
> Thanks,
> S Sathish Babu
>
> --
> 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 post to this group, send email to grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/4ce6fa34-b5a5-49d0-9296-b6c25cdc33ae%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAMC1%3DjfORqABJ5-pkxGeRxKME%3DYr_w89s%2BRDoHoiKYbDEkRqWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: python quick start "hello world" example fails

['Lidi Zheng' via grpc.io]

Hi Ankit,

Thanks for providing the trace log. I will look into it and update if I
found anything.

Lidi Zheng

On Fri, Nov 9, 2018 at 3:04 PM  wrote:

> here is server log; i killed server at the end by cntrl+c
>
> I1109 15:02:26.154260194   13636 ev_epoll1_linux.cc:116] grpc epoll
> fd: 3
> D1109 15:02:26.154434159   13636 ev_posix.cc:169]Using polling
> engine: epoll1
> D1109 15:02:26.154530558   13636 dns_resolver.cc:338]Using native
> dns resolver
> I1109 15:02:26.155007186   13636 init.cc:153]
> grpc_init(void)
> I1109 15:02:26.155213454   13636 completion_queue.cc:474]
> grpc_completion_queue_create_internal(completion_type=0, polling_type=0)
> I1109 15:02:26.155388910   13636 init.cc:153]
> grpc_init(void)
> I1109 15:02:26.155498555   13636 server.cc:994]
> grpc_server_create((nil), (nil))
> I1109 15:02:26.155608844   13636 server.cc:979]
> grpc_server_register_completion_queue(server=0x10423b0, cq=0x10e4590,
> reserved=(nil))
> I1109 15:02:26.156318834   13636 server_chttp2.cc:34]
> grpc_server_add_insecure_http2_port(server=0x10423b0, addr=[::]:50051)
> I1109 15:02:26.156495695   13636 socket_utils_common_posix.cc:310]
> TCP_USER_TIMEOUT not supported for this platform
> I1109 15:02:26.156648253   13636 init.cc:153]
> grpc_init(void)
> I1109 15:02:26.156761086   13636 completion_queue.cc:474]
> grpc_completion_queue_create_internal(completion_type=0, polling_type=1)
> I1109 15:02:26.156907935   13636 server.cc:979]
> grpc_server_register_completion_queue(server=0x10423b0, cq=0x10b5210,
> reserved=(nil))
> I1109 15:02:26.157128476   13636 server.cc:1089]
>  grpc_server_start(server=0x10423b0)
> I1109 15:02:26.157323173   13636 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10b5210, deadline=gpr_timespec { tv_sec:
> 1541804546, tv_nsec: 157310009, clock_type: 1 }, reserved=(nil))
> I1109 15:02:26.158580160   13636 init.cc:153]
> grpc_init(void)
> I1109 15:02:26.158879985   13636 init.cc:153]
> grpc_init(void)
> I1109 15:02:26.159027389   13636 call_details.cc:31]
>  grpc_call_details_init(cd=0x7fdfe3e076d0)
> I1109 15:02:26.159205197   13636 metadata_array.cc:29]
>  grpc_metadata_array_init(array=0x7fdfe3dd52f0)
> I1109 15:02:26.159393998   13636 server.cc:1417]
>  grpc_server_request_call(server=0x10423b0, call=0x7fdfe3dc85e0,
> details=0x7fdfe3e076d0, initial_metadata=0x7fdfe3dd52f0,
> cq_bound_to_call=0x10e4590, cq_for_notification=0x10e4590,
> tag=0x7fdfe3dd52c0)
> I1109 15:02:26.159928640   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804546, tv_nsec: 359917975, clock_type: 1 }, reserved=(nil))
> I1109 15:02:26.360656578   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804546, tv_nsec: 560638312, clock_type: 1 }, reserved=(nil))
> I1109 15:02:26.561583802   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804546, tv_nsec: 761562116, clock_type: 1 }, reserved=(nil))
> I1109 15:02:26.763345769   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804546, tv_nsec: 963336198, clock_type: 1 }, reserved=(nil))
> I1109 15:02:26.965018149   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804547, tv_nsec: 165008451, clock_type: 1 }, reserved=(nil))
> I1109 15:02:27.165804716   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804547, tv_nsec: 365797710, clock_type: 1 }, reserved=(nil))
> I1109 15:02:27.367464272   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804547, tv_nsec: 567454529, clock_type: 1 }, reserved=(nil))
> I1109 15:02:27.569251508   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804547, tv_nsec: 769241829, clock_type: 1 }, reserved=(nil))
> I1109 15:02:27.771057300   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804547, tv_nsec: 971047705, clock_type: 1 }, reserved=(nil))
> I1109 15:02:27.971863679   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804548, tv_nsec: 171853865, clock_type: 1 }, reserved=(nil))
> I1109 15:02:28.172670779   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804548, tv_nsec: 372661066, clock_type: 1 }, reserved=(nil))
> I1109 15:02:28.374448318   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec:
> 1541804548, tv_nsec: 574438418, clock_type: 1 }, reserved=(nil))
> I1109 15:02:28.576239230   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, 

Re: [grpc-io] gRFC L42 Adding wait-for-ready semantics

['Lidi Zheng' via grpc.io]

Thanks for your input. It's always good to know the reasoning for each
language's implementation.

On Thu, Oct 18, 2018 at 8:22 AM Eric Anderson  wrote:

> On Wed, Oct 17, 2018 at 6:00 PM Lidi Zheng  wrote:
>
>> Do you know why Python version doesn't have the a subset config class?
>>
>
> It wasn't a requirement. It wasn't even that important during Java's
> design.
>
> Should this feature be implemented in that way?
>>
>
> Unclear. In the design process I'd default to following in the footsteps
> of timeout. However, it is possible that the "use named arguments" doesn't
> scale well to many options and if that is becoming a risk then you may
> consider alternatives. I don't know the Python API well enough to say.
>
> It seems that will be inconsistent with previous `timeout` variable.
>>
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAMC1%3DjctyPr57QJ3azBZFOHHiZSjVQHVb7zJ-dzRXjmgWcCKiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.