[grpc-io] Re: Why the trailer frame is needed for gRPC? Any luck on making it work with Amazon ALB?

gRPC Uses the trailer frame to send the status code, and is required. Any HTTP2/HTTP1.1 translation will need a mechanism to include the status code in the trailer. On Thursday, March 15, 2018 at 8:08:37 AM UTC-7, yz wrote: > > We tested gRPC on ALB for the past week, we have found out

[grpc-io] Re: Handshake in TLS

If you are using a singleton channel, you should only need to do the TLS handshake once, or if the channel needs to reconnect due to a connection timeout or disconnect. On Tuesday, March 20, 2018 at 3:34:12 PM UTC-7, b...@soliduslink.com wrote: > > We are using Java on standard Appengine.

[grpc-io] Re: Issues trying to build source code

Yes, the minimum libcares version supported is 1.11.0 . On Friday, February 16, 2018 at 12:14:38 PM UTC-8, Todd Defilippi wrote: > > I now I am getting a build error: > > [CXX] Compiling > src/core/ext/filters/client_channel/resolver/dns/c_ares/grpc_ares_wrapper.cc >

[grpc-io] Re: frequently the symbol lookup error is coming

Can you try upgrading to the latest gRPC (1.8.4 I believe) There have been significant changes to grpc_exec_ctx. On Wednesday, January 24, 2018 at 1:14:57 AM UTC-8, subhayu...@gmail.com wrote: > > ./greeter_server: symbol lookup error: /usr/local/lib/libgrpc++.so.1: > undefined symbol:

Re: [grpc-io] python grpc worker or thread setting

On Tue, Jan 9, 2018 at 6:24 PM, wrote: > Thanks for the reply. > As you said, I confirmed that it runs concurrently through the time.sleep > () function. > It seems to run concurrently internally. > However, adding the function below is not simultaneous. > I printed a pid, which

Re: [grpc-io] python grpc worker or thread setting

If you add a 3 second sleep to SayHello and then run python client.py & python client.py & python client.py & wait Does this command take 9 seconds? I would expect it to take 3. On Thu, Jan 4, 2018 at 7:19 PM, wrote: > my server.py code: > > > >

Re: [grpc-io] python grpc worker or thread setting

On Thu, Jan 4, 2018 at 6:25 PM, wrote: > Hi! I'm Heidi. > I'm trying to build an api with python. > I try to build with grpc. > Post the image file to grpc server. > The gprc server detects the object by deep-running the requested image > file. > > First question: How do I

Re: [grpc-io] Python grpc.metadata_call_credentials over insecure channel

I think there are other ways to accomplish what you are describing. Insecure channels still support custom metadata, which can be passed to stubs using the optional "metadata" field. Here is an example.

[grpc-io] Re: gRPC Python: Can the gRPC server be run in a per-fork worker model?

Apologies, I missed the last response. I've created an issue to track this. https://github.com/grpc/grpc/issues/13536 On Monday, November 27, 2017 at 10:16:00 PM UTC-8, ho...@danielvaldivia.com wrote: > > Hi Ken, > > Is there an issue to track the progress of this? > > On Tuesday, August 1,

Re: [grpc-io] Package grpcio with py2exe

I've never seen an error like this before, and without debug symbols I don't think I'll be able to provide any useful guidance. initcygrpc is the module initialization function, so this indicates gRPC is failing to even load. I would recommend getting guidance from py2exe on using binary package

Re: [grpc-io] Package grpcio with py2exe

Can you post the full exception? On Fri, Nov 17, 2017 at 5:32 PM, wrote: > Thanks Ken. > > Now I am able to run it sometimes. I tried attaching windbg and saw abor > exception for "cygrpc!initcygrpc+". So initcygrpc is failing for some > reason. > > On Friday, 17 November

Re: [grpc-io] Package grpcio with py2exe

This question might be better suited for a py2exe mailing list. I'm not sure if py2exe supports binary python packages. If it does (in a cross-compatible way), I would expect it to need to package multiple pip packages in the resulting exe. On Fri, Nov 17, 2017 at 12:15 PM,

Re: [grpc-io] Package grpcio with py2exe

Pip will choose a binary package from PyPI that matches your Python version/architecture. If you attempt to redistribute that package, it may not match the client's Python version/architecture. On Fri, Nov 17, 2017 at 11:51 AM, wrote: > I am not building from source. I am

Re: [grpc-io] Package grpcio with py2exe

I'm not familiar with py2exe, but we release separate binary packages for Windows 32 and 64 bit Python. If you are trying to build from source and distribute the binary package, I would expect some compatibility issues. On Fri, Nov 17, 2017 at 11:29 AM, wrote: > Hi there, >

Re: [grpc-io] grpc python library server streaming issue

This behavior is expected for a unary request/stream response rpc. If you want the service handler to loop over requests, you should use bidirectional streaming (stream request/ stream response). On Tue, Oct 31, 2017 at 3:09 PM, sam reddy wrote: > a simple grpc

Re: [grpc-io] Python: How are multiple server processes listening on the same port/fd?

The reason why the SO_REUSEADDR behavior is seen on OSX but not linux has to do with the binary packaging of gRPC Python. gRPC Python binary packages for linux are built against a "manylinux" platform that aims to be compatible with most linux distributions. As a result, it is compiled

[grpc-io] Re: How do I create custom proto types in the NodeJS implementation?

If you can serialize these object types to strings, and need to pack them into a protobuf message, you can put them in the protobuf as serialized strings. On Thursday, September 14, 2017 at 5:56:35 PM UTC-7, luc...@getsirena.com wrote: > > Hi! I'm trying to add support for 2 types that I need:

[grpc-io] Re: [core] Bug in tcp_do_read() in tcp_posix.c?

This got addressed in https://github.com/grpc/grpc/pull/12353, thanks! On Wednesday, August 30, 2017 at 10:22:02 PM UTC-7, tud...@gmail.com wrote: > > Hello, > > I found this by code inspection when debugging a (potential) memory leak > (or at least a huge increase in memory usage) under load. >

Re: [grpc-io] Python: How are multiple server processes listening on the same port/fd?

On Tue, Sep 5, 2017 at 6:07 AM, Amit Saha wrote: > > > On Tue, Sep 5, 2017 at 9:02 AM Amit Saha wrote: > >> On Tue, 5 Sep 2017 at 6:44 am, Ken Payson wrote: >> >>> gRPC Python sets the SO_REUSEADDR option on server sockets,

Re: [grpc-io] Python: How are multiple server processes listening on the same port/fd?

gRPC Python sets the SO_REUSEADDR option on server sockets, which allows multiple servers to bind to the same port. On Mon, Sep 4, 2017 at 5:58 AM, Amit Saha wrote: > Hey all, > > This is the relevant part of my server: > > def serve(): > server =

Re: [grpc-io] WaitForReady in python

There are a few ways to track channel state in Python. If you only want to block until it is connected, try grpc.channel_ready_future(channel).result() https://grpc.io/grpc/python/grpc.html#grpc.channel_ready_future On Fri, Aug 18, 2017 at 7:23 AM, Julian Gold

[grpc-io] Re: gRPC Python: Can the gRPC server be run in a per-fork worker model?

There is some work underway to support a prefork based process pool for Python. I'd recommend avoiding using fork altogether with gRPC until it is available. On Wednesday, July 19, 2017 at 11:20:24 PM UTC-7, bols...@lnc.jp wrote: > > Hello. > I need of process-based pooling. > > My use case is

Re: [grpc-io] How to run Python performance tests locally?

On Tue, Jun 13, 2017 at 5:43 PM, Gustavo Covas wrote: > Hello, > I'm interested in running the performance test suite for the Python > language locally. However, when running > tools/run_tests/run_performance_tests.py > -l python, the script usually fail with timeouts in some

[grpc-io] Re: Attention

What aspect of gRPC (language/use-case) are you interested in? That can help us figure out who would be the best to speak with. Ken On Sunday, March 12, 2017 at 10:57:13 AM UTC-7, Jens Carl Streibig wrote: > > Can we have a direct private discussion? > -- You received this message because

Re: [grpc-io] gRPC - Google's Summer of code

Thanks for pointing that out. I've submitted a request to have gRPC removed. Ken On Tuesday, March 21, 2017 at 11:12:33 AM UTC-7, Nathaniel Manista wrote: > > On Sun, Mar 19, 2017 at 5:34 PM, Mohamed Elqdusy > wrote: > >> I am a computer science student at Mansoura

Re: [grpc-io] forking child process in server causes client handshake failures

Are you calling any destructors in the forked process before exit? Destroying the server will call shutdown() on the underlying sockets, which will cause problems for the parent process. Ken On Tue, Mar 7, 2017 at 12:19 PM, AK wrote: > The forked child simply exits

Re: [grpc-io] grpc bidirectional stream with different messages

If you are using protobufs, the easiest way to approach this would be to use the oneof feature. Oneof allows you to specify a request type that is "one of" connectReq/cliMsg/serverMsgRes. Likewise, your response type can be

Re: [grpc-io] INTERNAL error in src/core/lib/iomgr/tcp_posix.c:340

In general, INTERNAL errors may be returned to the application, but unlike UNAVAILABLE are not retryable. The EPIPE issue you are seeing is a bug that was addressed here , and should be returned as an UNAVAILABLE error in the next release. On Tue, Jan

Re: [grpc-io] python gRPC: set max_message_length for server or listen port.

Currently this is not possible in Python. In the master branch , there is an options field that works in the same way, and you can set grpc .max_receive_message_length/grpc.max_send_message_length. This will be

Re: [grpc-io] using CallCredentials from Python

Call credentials can only be used on a secure channel. In your example, it should look something like: call_creds = grpc.metadata_call_credentials(UsernamePasswordCallCredential s("foo")) ssl_creds = grpc.ssl_channel_credentials() channel_creds = grpc.composite_channel_credentials(ssl_creds,

Re: [grpc-io] Stress test error: 'ignoring out of order new grpc_chttp2_stream request on server'

This looks like the same issue seen here: https://github.com/grpc/grpc/issues/7785 It was caused by concurrency issues in the http2 parser. I've verified that the issue is fixed in the master branch. On Thu, Nov 10, 2016 at 9:27 AM, Okke Hendriks wrote: > Hello, > > I