| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
|\
| |
| | |
Add hooks for census context propagation
|
| |
| |
| |
| |
| |
| | |
Appease the yapf gods
Reformat
|
|/ |
|
|\
| |
| | |
credentials: call grpc_init/grpc_shutdown when created/destroyed
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This addresses https://github.com/grpc/grpc/issues/17001. Prior to
https://github.com/grpc/grpc/pull/13603, our credentials cython objects
used grpc_initi() and grpc_shutdown() on creation and destruction. These are
now managed differently, but the grpc_init() and grpc_shutdown() calls
are still required. See the MetadataCredentialsPluginWrapper in C++,
which extends the GrpcLibraryCodegen class to ensure that grpc_init()
and grpc_shutdown() are called appropriately.
Without this, we can deadlock when a call to grpc.Channel#close()
triggers grpc_shutdown() to block and wait for all timer threads to
finish: one of these timer threads may end up unreffing the subchannel
and triggering grpc_call_credentials_unref, which will jump back into
Cython and hang when it tries to reacquire the GIL.
|
|\ \
| |/
|/|
| | |
Surface exceptions from Cython to Python as much as possible
Fixed #16643
|
|\ \
| | |
| | | |
Channelz Python wrapper implementation
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Correct the StatusCode
* Format code
* Use @staticmethod
* Fix typo
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Expose the C-Core API in Cython layer
* Handle the object translation
* Create a separate package for Channelz specifically
* Handle nullptr and raise exception if seen one
* Translate C++ Channelz unit tests
* Adding 5 more invalid query unit tests
Adding peripheral utility for grpcio-channelz package
* Add to `pylint_code.sh`
* Add to Python build script
* Add to artifact build script
* Add to Bazel
* Add to Sphinx module list
|
| | | |
|
| |/
|/| |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was trying to get a feel for what the rest of the python ecosystem
does with its logging, so I looked into the top few libraries on pypi:
urllib3 maintains a logger for not quite every module, but for each
one that does heavy lifting. The logger name is `__name__`, and no
handlers are registered for any module-level loggers, including
NullHandler. Their documentation spells out how to configure logging
for the library.
They explicitly configure a library root-level logger called `urllib3`
to which they attach a `NullHandler`. This addresses the "no handlers
could be found" problem.
Their tests explicitly configure handlers, just like ours do.
scrapy is more hands-on. It provides a configuration module for its
logging and a whole document on how to handle logging with scrapy. It
looks like log.py's whole reason for existence is making sure that a
handler is attached to to the scrapy handler at startup.
I think the extra complexity here is because scrapy also offers a CLI,
so there has to be some way to configure logging without resorting to
writing python, so I felt we didn't need to resort to this added
complexity.
---
Based on all of the libraries I've looked at, I think our current
approach is reasonable. The one change I would make is to explicitly
configure a `grpc` logger and to only attach a `NullHandler` to it
instead of putting the burden on the author of each new module to
configure it there.
With this change, I have
- Configured a logger in each module that cares about logging
- Removed all NullHandlers attached to module-level loggers
- Explicitly configured a `grpc` logger with a `NullHandler` attached
Resolves: #16572
Related: #17064
|
|\
| |
| | |
Add wait-for-ready semantics
|
| |
| |
| |
| |
| |
| | |
* Include unit tests to test default behaviour, disable behaviour, enable behaviour of the wait-for-ready mechanism
* Import flags constants from grpc_types.h
* Use WaitGroup to wait for TRANSIENT_FAILURE state in unit test
|
|\ \
| |/
|/| |
Replace pkg_resources with pkgutil.
|
| |
| |
| |
| | |
pkg_resources (part of setuptools) is overkill for reading resource files. The standard library module pkgutil can do that just fine.
|
| | |
|
|/
|
|
| |
This reverts commit a20e2073c1c53cbdd81a4fb750982a0b13e0c24e.
|
|
|
|
|
|
| |
* unit test included
* throw ValueError exception from Cython to Python
* prevent the deconstruction method from failing when Channel initialization failed
|
| |
|
|\
| |
| | |
Configure module level loggers with basicConfig().
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This extends gRPC Python's fork compatibility to Mac OS, which does not support
epoll
The changes are a no-op if fork support is disabled
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
|
|
|
| |
Module level loggers were introduced to gRPC Python in 06e1683, but
missed configuring these, leading to 'No handler found for module'
errors. Using the root logger implicitly calls basicConfig() which does
the basic configuration for the logging system by creating a
StreamHandler with a default Formatter and adding it to the logger. But
this is not the case for module level loggers.
Fix this issue by explicitly calling logging.basicConfig().
|
|
|
|
|
|
|
| |
This worked fine with CPython, but the condition
was always evaluated to False with Pypy, causing
bugs down the road.
Tested with Pypy 6.0.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
a verification callback option.
These options are not yet exposed to languages outside of core.
|
|
|
|
|
|
|
| |
All files under `grpc/_cython/_cygrpc` in grpcio Python package
are used as include files and thus have a .pxi file extension.
grpc_gevent implementation was added in 1bfff8e, but didn't include the
.pxi file extension. Update these file names.
|
|\
| |
| | |
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.
|
|\ \
| | |
| | | |
Retain references to channel arguments.
|
| | |
| | |
| | |
| | |
| | | |
This works around issue 15662 which is not as easy to implement as I
would prefer it to be.
|
|\ \ \ |
|
| |/ / |
|
| |/
|/|
| |
| |
| |
| |
| | |
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.
|
| |
|