| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|\
| |
| |
| |
| | |
leifurhauks/py3_str_bytes_in_links_service_and_beta_server
Python 3: fix a bytes/str runtime issue
|
|\ \
| | |
| | | |
Add HTTP request parsing
|
|\ \ \
| | | |
| | | | |
Python: py3 compatibility for test runner & loader
|
|\ \ \ \
| | | | |
| | | | | |
Make unix sockets optional
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Make grpc-python ByteBuffer.bytes() linear
|
| |_|_|/ /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.)
|
|\ \ \ \
| | | | |
| | | | | |
removed uchannels
|
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \
| | | | |
| | | | | |
replace uses of iteritems with six.iteritems
|
| |/ / /
|/| | | |
|
|\ \ \ \
| | | | |
| | | | | |
make iterators python3-compatible
|
|\ \ \ \ \
| | | | | |
| | | | | | |
specify metaclasses in a py3-compatible way
|
|\ \ \ \ \ \ |
|
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Cleaned up installation/test requirement fetching
|
| |\ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Reintroduce flakiness flag for tests: lb_policies_test is inherently flaky and I don't have time to deflake this week
|
| | |\ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
Implemented compression level algorithms properly
|
| |/ / / / / / / /
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
re-used elsewhere)""
|
| |\ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
DocFixit: Add more troubleshooting details
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
elsewhere)"
|
| | |_|_|_|_|/ / /
| |/| | | | | | | |
|
| | |_|_|_|/ / /
| |/| | | | | | |
|
| | |_|_|_|_|/
| |/| | | | | |
|
| | |_|_|/ /
| |/| | | | |
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | |_|/ / /
| |/| | | | |
Don't use a pipe for output capturing in Python's test runner
|
| | | | | | |
|
| | | | | | |
|
|\| | | | | |
|
| |\ \ \ \ \
| | | |/ / /
| | |/| | | |
DocFixit: Python README
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
|\ \ \ \ \ \
| | |_|/ / /
| |/| | | | |
|
| | |\ \ \ \
| | |/ / / /
| |/| | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | |_|/ / /
| |/| | | | |
Don't hold the GIL when calling anything in core
|
| | | |\ \ \
| | |_|/ / /
| |/| | | | |
|
|\| | | | | |
|
| | | |_|/
| | |/| | |
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |\ \ \
| | | | |
| | | | | |
Remove tests for EventInvocation API that is going to be removed
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
| |/ / |
|
| |\ \
| | | |
| | | | |
Release GIL in queue __dealloc__
|
| |\ \ \
| | | | |
| | | | | |
Merge release-0_13 into master
|
| | | | | |
|