| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
RpcError should be returned from the continuation intact,
not raised.
|
| |
|
|\
| |
| | |
Raise the exception while credential initialization
|
| | |
|
|\ \
| | |
| | | |
Remove beta module dependency from the Python Bazel package
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Beta code elements are going to get deprecated and
Bazel support is much newer, so Bazel users are
not supposed to accidentally depend on beta code
elements. Preventing Bazel from building and
including beta code elements makes our tests pass
without depending on beta in grpcio target and
helps avoid including that dependency accidentally
if you are using Bazel.
|
|\ \ \
| | |/
| |/| |
|
| |/ |
|
| | |
|
|\ \ |
|
| |/ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\ \
| | | |
| | | | |
The new gRPC Python documentation generator
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* Use templates instead of generating them every time
* Theme changed
* Add grpc_* modules
* APIs grouped
* No documentation for class members without docstring
* Add docstring for status code
|
| | |/
| | |
| | |
| | |
| | |
| | | |
* 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
|
| |\ \
| | | |
| | | | |
Add background about gRPC Python's building process on macOS
|
| | |/ |
|
| |\ \
| | | |
| | | | |
Add python monkey-patch for parallel build_ext compilation
|
| |\ \ \
| | | | |
| | | | | |
Replace pkg_resources with pkgutil.
|
| | |_|/
| |/| |
| | | |
| | | |
| | | | |
* Both server and client should be fine with utf-8 error messages now
* Adding an interop test: special status message
|
| |\ \ \
| | | | |
| | | | | |
Use gRPC thread model (i.e., pollset_set) in ALTS TSI implementation
|
| |\ \ \ \
| | | | | |
| | | | | | |
Channelz: Socket Tracks Addresses
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
pkg_resources (part of setuptools) is overkill for reading resource files. The standard library module pkgutil can do that just fine.
|
| | |/ / /
| |/| | | |
|
| |\ \ \ \
| | |_|/ /
| |/| | | |
Fix logging
|
| |\ \ \ \
| | | | | |
| | | | | | |
Handle missing globals in Python Channel destructors
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | |/
| | | |/|
| | | | |
| | | | | |
This reverts commit a20e2073c1c53cbdd81a4fb750982a0b13e0c24e.
|
| | | |/ |
|
| | | | |
|
| | | |
| | | |
| | | | |
* reduce possible contamination of environment variables
|
| | | |
| | | |
| | | |
| | | | |
* This commit failed `tools/run_tests/artifacts/build_artifact_csharp.sh`
* It doesn't make any sense!
|
| | | | |
|
| | |/
| |/| |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the last reference to a Python object is at module scope, when
its destructor is run before program termination it may find that
the globals it requires no longer exist. Destructors of objects
likely to be stored at module global scope need to check that
globals exist before attempting to use them, to avoid warnings
being printed by the Python interpreter.
See grpc#17004
|
| |\
| | |
| | | |
Health checking client
|
| | | |
|
| |/ |
|
| |
| |
| |
| |
| |
| | |
Also,
- Changes to extract grpclb_proto into its own build target
- Remove client_load_reporting_filter from xds plugin.
|
| |
| |
| |
| |
| |
| | |
* unit test included
* throw ValueError exception from Cython to Python
* prevent the deconstruction method from failing when Channel initialization failed
|
| | |
|
| |\
| | |
| | | |
Delete hpack lookup table
|
| | | |
|