| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
|
|
|
|
|
| |
* Add `abort_with_status` method in ServicerContext
* Add `Status` interface similar to the design of Details in interceptor
* Add 3 unit test cases for abort mechanism
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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
|
| |
|
|\
| |
| |
| |
| | |
nathanielmanistaatgoogle/generic-rpc-handler-validation
Check conformance to grpc.GenericRpcHandler type.
|
| | |
|
|/ |
|
|
|
|
|
|
| |
@nathanielmanistaatgoogle and I just had a good session helping me
figure out how to use this API correctly, and this rewording of the
documentation was the result.
|
| |
|
| |
|
| |
|
|
|
|
| |
Upgrade yapf version to 0.20.0 and reformat Python files.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
gRPC Python required RPCs terminating with non-OK status code to still
return a valid response value after calling set_code, even though the
response value was not supposed to be communicated to the client, and
returning None is considered a programming error.
This commit introduces an alternative mechanism to terminate RPCs by
calling the `abort` method on `ServicerContext` passed to the handler,
which raises an exception and signals to the gRPC runtime to abort the
RPC with the specified status code and details.
|
|
|
|
|
|
| |
Rather than allocating gRPC Core memory when instantiated and
retaining it until deleted, gRPC Python's credentials objects now
offer methods to create gRPC Core structures on demand.
|
| |
|
| |
|
|
|
|
| |
It was never itself a "call credentials" of any sort.
|
|
|
|
|
|
|
| |
"Do not make undocumented and unsupported use of one part of an API
from within the implementation of another part of the same API" is one
of the rules of Abstraction Club. Not sure if it's important enough to
be the first two rules, but it's up there.
|
| |
|
|
|
|
|
| |
I should have requested this during code review of bcf083fa9099e5c919
but it slipped my mind.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, a secure server is configured with SSL credentials during
initialization, and those credentials will be used for the lifetime of
the server. If the user wants the server to use new credentials, the
user has to restart the server, resulting in server downtime. This
change enables the user to optionally configure the server with a
"certificiate config fetcher," such that on every new client
connection, the server will call the config fetcher before performing
the handshake, allowing the user application to optionally specify new
certificate configuration for the server to use (the fetcher can
return a "no change" and the server continues to use its current
certificate configuration).
|
| |
|
| |
|
| |
|
|
|
|
| |
Contains squashed commits for several typo fixes and comments made during review.
|
|
|
|
| |
If the server is already serving max requests, return RESOURCE_EXHAUSTED
|
| |
|
| |
|
|
|
|
|
|
|
| |
In those places where we return an object that implements two
interfaces (let's say P and Q), consistently describe it as a "P-Q"
rather than once mentioning that it is a P and describing it as a "Q"
for the rest of prose.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Manual changes:
- Fixed use of Exception.message in _invalid_metadata_test.py
- Fixed merge of one_failed_as_unavailable in rpc_server_spec.rb
- Added "set -e" to generate_build_additions.sh
|
|\ \
| | |
| | | |
Revert "Add configurable exit grace periods and shutdown handlers"
|
| | |
| | |
| | |
| | |
| | | |
Uses dynamic loading to paper-over the negative effects of losing
namespace packages in the previous commit.
|
| | |
| | |
| | |
| | |
| | | |
Uses dynamic loading to paper-over the negative effects of losing
namespace packages in the previous commit.
|
| | | |
|
| | |
| | |
| | |
| | | |
ServicerContext.set_code takes a (grpc.)StatusCode, not an integer.
|
|\ \ \
| | | |
| | | | |
Allow handlers to hint at the services they export
|
| | | | |
|
| |/ /
|/| |
| | |
| | | |
This reverts commit 3045a379aa76ce9ee930f427daa4ee799b0162aa.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The server cleanup method is untested.
The join() function that exposes it is only called by the internals of threading.py, and we don't hold a reference to the server thread to explicitly join() it, and I'm not sure we should add a reference just for this purpose.
Moreover, the threading.py only calls join(None), the code path in question isn't even exercised by the internals of threading.py. Its just there to make sure we properly follow the join(timeout) semantics.
|
|\ \ \
| |/ /
|/| /
| |/ |
|