| Commit message (Collapse) | Author | Age |
... | |
| |/
|/| |
|
| | |
|
|/
|
|
|
|
|
|
| |
This change adds an experimental ssl_session_cache_lru function to the
Python API that returns an encapsulated grpc_ssl_session_cache (#14483).
Python clients may use this object as an argument for the
grpc.ssl_session_cache channel option if they wish to cache and resume
TLS sessions with a server.
|
|
|
|
|
| |
In case of error, the user can access call.debug_error_string()
which contains a string representation of error from the c core.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This removes invocation-side completion queues from the _cygrpc API.
Invocation-side calls are changed to no longer share the same lifetime
as Core calls.
Illegal metadata is now detected on invocation rather than at the start
of a batch (so passing illegal metadata to a response-streaming method
will now raise an exception immediately rather than later on when
attempting to read the first response message).
It is no longer possible to create a call without immediately starting
at least one batch of operations on it. Only tests are affected by this
change; there are no real use cases in which one wants to start a call
but wait a little while before learning that the server has rejected
it.
It is now required that code above cygrpc.Channel spend threads on
next_event whenever events are pending. A cygrpc.Channel.close method
is introduced, but it merely blocks until the cygrpc.Channel's
completion queues are drained; it does not itself drain them.
Noteworthy here is that we drop the cygrpc.Channel.__dealloc__ method.
It is not the same as __del__ (which is not something that can be added
to cygrpc.Channel) and there is no guarantee that __dealloc__ will be
called at all or that it will be called while the cygrpc.Channel
instance's Python attributes are intact (in testing, I saw both in
different environments). This commit does not knowingly break any
garbage-collection-based memory management working (or "happening to
appear to work in some circumstances"), though if it does, the proper
remedy is to call grpc.Channel.close... which is the objective towards
which this commit builds.
|
|/
|
|
|
| |
This is no longer needed with the addition of a close() API that allows
clean shutdown.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
.received_cancelled was changed to .cancelled() in
81edf5ff9af2d90813773acb9c2793e1a4cd1057; this change should have been
a part of that change.
|
|\
| |
| | |
Revert "Verify early OK behavior"
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
| |
The Beta API has an execution date and RPC Framework is but a distant
memory.
This test is flaky with Python 3.5 on Windows! Some mysteries will just
have to remain unsolved...
|
|
|
|
|
|
|
|
|
|
| |
Looks like early OK support was implemented in
https://github.com/grpc/grpc/pull/14080 but
https://github.com/grpc/grpc/issues/7032 was not marked fixed at the
time.
Good thing it was just an idea on our Google Summer of Code ideas
page...
|
| |
|
|
|
|
|
|
|
|
|
| |
The thread that watches connectivity on the channel might not
pick up that the server has gone away before the request is
dispatched, and return UNAVAILABLE instead of reconnecting
prior to sending the request. The fundamental solution would
basically be enabling retries in C-core. For now, we opt to
sleep a second to deflake this particular test case.
|
|\
| |
| | |
Elide cygrpc.ChannelArg and cygrpc.ChannelArgs.
|
| | |
|
|\ \
| |/
|/| |
python: Context.abort should fail RPC even for StatusCode.OK
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
grpc.ServicerContext.abort is documented to always raise an exception
to terminate the RPC. The code argument "must not be StatusCode.OK."
However, if you do pass StatusCode.OK, the RPC terminates successfully
on the client side, but returns None.
_server.py: If the user accidentally passes StatusCode.OK, treat it as
StatusCode.UNKNOWN. This is what happens if the user accidentally
passes something that is not a StatusCode instance. Additionally
set details to ''.
_metadata_code_details_test.py: update test to verify the behavior of
abort with invalid codes.
|
|/ |
|
|
|
|
| |
Upgrade yapf version to 0.20.0 and reformat Python files.
|
|\
| |
| | |
Reform cygrpc.OperationTag and cygrpc.Event.
|
|\ \
| | |
| | |
| | | |
Upmerge v1.8.3 into master
|
| |/
| |
| |
| |
| |
| | |
Rather than single classes they are now broken up into class families
with each class containing only those fields and methods that are
needed in the context in which the class is used.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It is now a family of classes conforming to an interface rather than a
single class no single instance of which makes use of all behavior
scoped to the class.
It also now only uses gRPC Core memory for the time of a single batch
rather than for the entire lifetime of the instance.
|
| | |
|
|\ \
| |/
|/| |
Disable so_reuseport for Python tests
|
| | |
|
|/
|
|
|
|
| |
This restore unsupported, de facto behavior that was dropped in
80516e884a8cd03daaa1f4a40d2bb2 but that it turns out a lot of folks
have been using.
|
| |
|
| |
|
| |
|
|
|
|
| |
Rename call to response_iterator_call file-wide for response-streaming tests.
|
| |
|
|\
| |
| | |
Elide cygrpc.Operations.
|
| | |
|
|\|
| |
| | |
Streamline metadata in gRPC Python.
|
| | |
|
|/
|
|
|
|
|
|
|
|
| |
A GenericRpcHandler registered on a gRPC Server is not supposed to raise
an exception and if it does so it is considered a programming defect.
However, gRPC is supposed to respond to the client with an UNKNOWN
status code. Previously, this situation was left unhandled and the
client ended up receiving a response with CANCELLED status code.
This commit fixes the issue https://github.com/grpc/grpc/issues/13629.
|
|
|
|
|
|
| |
Rather than allocating gRPC Core memory when instantiated and
retaining it until deleted, gRPC Python's credentials objects now
offer methods to create gRPC Core structures on demand.
|
|
|
|
| |
It was never itself a "call credentials" of any sort.
|
|
|
|
|
| |
I should have requested this during code review of bcf083fa9099e5c919
but it slipped my mind.
|