| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
* Both server and client should be fine with utf-8 error messages now
* Adding an interop test: special status message
|
| | |
|
| |
|
|
| |
This reverts commit a20e2073c1c53cbdd81a4fb750982a0b13e0c24e.
|
| |
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
|
|
|
|
| |
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:`
|
| |
|
|
|
| |
This is no longer needed with the addition of a close() API that allows
clean shutdown.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The fix is more of an elision and the code in the changed area is
reflowed.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This impacts the following APIs:
Metadata: Key is always a str, Value is bytes for binary metadata,
str otherwise
Call Details: str type
gRPC method: str type
hostname/target: str type
|
| | |
|
| |
|
|
|
|
|
| |
When the Python Interpreter exits, it first attempts to join any
outstanding threads. This is problematic if a server is created
as a top-level variable or referenced by a reference cycle, as join()
will hang. This adds cleanup behavior to the server thread's join().
|
| |
|
|
|
|
|
|
| |
Notable Changes:
-Convert all str types to byte types at cython layer (ascii encoding)
-Use six for packages that have different names in Python2/Python3
-By default, unit tests are compiled/run in Python2.7 and Python3.4
-Ensure MACOSX_BUILD_TARGET is at least 10.7
|
| |
|
Richard Belleville
Lidi Zheng
Naresh
kpayson64
Nathaniel Manista
Jan Tattermusch
Masood Malekghassemi