| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| | |
Run pylint test in Python 3
|
| | | |
|
| |/
|
|
|
|
|
|
| |
* Use latest pylint in Python 3.7 (they dropped support for PY2)
* Make latest pylint happy
* Forced to upgrade to shellcheck 0.4.4
* Make shellcheck 0.4.4 happy
* Adopt reviewers' advice to reduce global disabled rules
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
* 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
|
| |\
| |
| | |
Fix logging
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This reverts commit a20e2073c1c53cbdd81a4fb750982a0b13e0c24e.
|
| |/
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
* 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().
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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().
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Upgrade yapf version to 0.20.0 and reformat Python files.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
More lint.
|
| |\ \
| | |
| | | |
Lint progress.
|
| | |/ |
|
| | | |
|
| |\ \
| | |
| | | |
Lint fixes.
|
| | |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In _server.py start_server_batch_result is removed because
start_server_batch can only ever fail as a result of a programming
defect in gRPC Python and not the application. This differs from some
analogous-appearing points in _channel.py where the result of
start_client_batch is checked because at those points it is possible
for a failure to indicate a programming defect on the part of the
application.
|
| |\ \
| |/
|/| |
Upmerge from 1.1.x
|
| | | |
|
| | |
| |
| |
| | |
This allows inspecting c-level properties of the call after completion.
|
| | |
| |
| |
| |
| | |
This brings gRPC Python into conformance with the recommendation in
https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md.
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
Lidi Zheng
Richard Belleville
Lidi Zheng
Eric Gribkoff
Richard Belleville
Stuart Bishop
Nathaniel Manista
Naresh
Mehrdad Afshari
Mehrdad Afshari
Noah Eisen
kpayson64
Jan Tattermusch
Michael Lumish
David Garcia Quintas
Masood Malekghassemi