Added the ability to create channels from client_channel_factory. This
will be used by the grpclb code to create the channels to communicate
with the LB servers.
Before it was possible for precompiled binaries of the Cython layer to
be downloaded during a test run if the metadata of the host machine's
gRPC Python project matched the metadata of a file in cloud storage. Now
we disallow this, and fix a bug where the relevant environment variable
was ineffectual.
This extends the existing http parser to support requests as well as responses.
httpcli continues to exist and work as it has previously, though in the new
directory src/core/http (to reflect the fact the directory now contains code
relevant to parsing requests, which httpcli would not generally involve itself
in).
On python3, in grpc._links.service._Kernel._on_service_acceptance_event,
there is a runtime TypeError:
```
_on_service_acceptance_event
group, method = service_acceptance.method.split('/')[1:3]
TypeError: 'str' does not support the buffer interface
```
It is fixed by using a bytes literal (`b'/'`) instead of a string literal.
This exposed another issue in grpc.beta._server where an exception was being
raised with a bytes literal for a message (a string should be used instead.)
Currently ByteBuffer.bytes() reads from the underlying grpc byte_buffer
a slice at a time, and appends each to a Python string (bytes). In
Python strings are immutable, so appending creates a new string by
copying the previous data. This means the current implementation is
quadratic.
The effect is very noticeable when messages have repeated (or large)
string fields. We traced execution between two services and observed
that when the payload size approached 600kb, the receiving service took
~10s at full CPU to read a response that had taken fractions of a second
the send over the network.
This commit changes ByteBuffer.bytes() to use an intermediate bytearray,
instead of strings, for the in-progress bytes. Once all slices are
read, the buffer is converted to a string.
Since the default behavior is quite sane, support just calling ssl_channel_credentials() without explicitly specifying ssl_channel_credentials(None, None, None).
This changes the pattern ssl_channel_credentials(server_crt, None, None) to ssl_channel_credentials(server_crt)
Signed-off-by: Christian Svensson <blue@cmd.nu>
Apparently Python can call arbitrarily deallocation code whenever its
allocator is invoked, which can cause output from gRPC core to stderr,
which can happen on the thread that is emptying the stderr pipe, thus
causing the stderr pipe to deadlock on itself.
Both have to do with the test runner's handling of the tests. With one
it's the read thread somehow outliving the other threads (e.g. with
ctrl-C). The other is due to a filled OS-level pipe's buffer causing a
block while code is still holding the GIL in some gRPC core function. We
can't empty the buffer from Python because the GIL is held, and the OS
can't unblock because it's waiting for the buffer to get cleared:
deadlock.
Craig Tiller
itessier
Deepak Lukose
Yuchen Zeng
David Garcia Quintas
murgatroid99
Nicolas "Pixel" Noble
Masood Malekghassemi
Leifur Halldor Asgeirsson
Matthew Iselin
alex
Christian Svensson
Sree Kuchibhotla
ahedberg