| Commit message (Collapse) | Author | Age |
|\
| |
| | |
Fix a number of spelling errors.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A process may fork after invoking grpc_init() and use gRPC in the child
if and only if the child process first destroys all gRPC resources
inherited from the parent process and invokes grpc_shutdown().
Subsequent to this, the child will be able to re-initialize and use
gRPC. After fork, the parent process will be able to continue to use
existing gRPC resources such as channels and calls without interference
from the child process.
To facilitate gRPC Python applications meeting the above constraints,
gRPC Python will automatically destroy and shutdown all gRPC Core
resources in the child's post-fork handler, including cancelling
in-flight calls (see detailed design below). From the client's
perspective, the child process is now free to create new channels and
use gRPC.
|
|/ |
|
| |
|
|
|
|
|
| |
Follow-up on the additions in #15992. Pad the grpcio Python package
with necessary BUILD files along with 2 simple tests.
|
| |
|
|
|
|
|
|
| |
The Beta API has been unsupported for a while and
we plan to disable the flaky tests in the Beta API
as we see them before we entirely remove it.
|
|\
| |
| |
| |
| | |
nathanielmanistaatgoogle/generic-rpc-handler-validation
Check conformance to grpc.GenericRpcHandler type.
|
|\ \
| | |
| | | |
Bump pylint to 1.9.2
|
| |/
|/| |
|
|\ \
| | |
| | | |
TLS session resumption support for Python clients.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/| |
|
|\ \
| | |
| | | |
Update logging in Python to use module-level logger.
|
| |/
|/|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| | |
All logging in Python so far was done with the root logger, resulting
in logs like: `ERROR:Exception calling application:`. With module-level
loggers, the logs will instead include the module in which the
exception is raised: `ERROR:grpc._server:Exception calling application:`
|
|/ |
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| | |
Initial Gevent Compatibility
|
| |
| |
| |
| |
| | |
Because some cpp code ends up leaking into cython, we change
the cython generator to generate cpp code.
|
| |
| |
| |
| | |
Relying on garbage collection to stop servers breaks with gevent.
|
|\ \
| |/
|/| |
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...
|
| |
|