aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/python/grpcio/grpc/_cython/_cygrpc
Commit message (Collapse)AuthorAge
* correctly name __dealloc__ methodGravatar Eric Gribkoff2019-01-09
|
* Free grpc_channel_args after creationGravatar Richard Belleville2018-12-27
|
* add tracking issueGravatar Eric Gribkoff2018-12-17
|
* Refactor server deallocationGravatar Eric Gribkoff2018-12-17
|
* Merge pull request #17460 from grpc/enable-censusGravatar Richard Belleville2018-12-11
|\ | | | | Add hooks for census context propagation
| * Add hooks for census context propagationGravatar Richard Belleville2018-12-11
| | | | | | | | | | | | Appease the yapf gods Reformat
* | Add max_results to ServerSocketsGravatar ncteisen2018-12-11
|/
* Merge pull request #17396 from ericgribkoff/creds_close_hangGravatar Eric Gribkoff2018-12-04
|\ | | | | credentials: call grpc_init/grpc_shutdown when created/destroyed
| * credentials: call grpc_init/grpc_shutdown when created/destroyedGravatar Eric Gribkoff2018-12-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #16971 from lidizheng/surface-exceptionsGravatar Lidi Zheng2018-12-03
|\ \ | |/ |/| | | Surface exceptions from Cython to Python as much as possible Fixed #16643
* | Merge pull request #17266 from lidizheng/python-channelzGravatar Lidi Zheng2018-11-29
|\ \ | | | | | | Channelz Python wrapper implementation
| * | Adopt reviewer's suggestionsGravatar Lidi Zheng2018-11-28
| | | | | | | | | | | | | | | | | | | | | * Correct the StatusCode * Format code * Use @staticmethod * Fix typo
| * | Channelz Python wrapper implementationGravatar Lidi Zheng2018-11-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| | * Surface exceptions from Cython to Python as much as possibleGravatar Lidi Zheng2018-11-27
| | |
* | | [cython] Declare symbols onceGravatar Ruslan Nigmatullin2018-11-26
| |/ |/|
* | Raise the exception while credential initializationGravatar Lidi Zheng2018-11-26
|/
* Use single NullHandler for whole libraryGravatar Richard Belleville2018-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Merge pull request #16919 from lidizheng/wait-for-readyGravatar Lidi Zheng2018-11-07
|\ | | | | Add wait-for-ready semantics
| * Add wait-for-ready semanticsGravatar Lidi Zheng2018-11-06
| | | | | | | | | | | | * 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
* | Merge pull request #16976 from benjaminp/remove-pkg_resourcesGravatar Lidi Zheng2018-11-05
|\ \ | |/ |/| Replace pkg_resources with pkgutil.
| * Replace pkg_resources with pkgutil.Gravatar Benjamin Peterson2018-11-01
| | | | | | | | pkg_resources (part of setuptools) is overkill for reading resource files. The standard library module pkgutil can do that just fine.
* | Add NullHandler to avoid warnings about no handlerGravatar Richard Belleville2018-10-30
| |
* | Revert "Configure module level loggers with basicConfig()"Gravatar Richard Belleville2018-10-30
|/ | | | This reverts commit a20e2073c1c53cbdd81a4fb750982a0b13e0c24e.
* fix Exception throw for invalid channel argsGravatar Lidi Zheng2018-10-14
| | | | | | * unit test included * throw ValueError exception from Cython to Python * prevent the deconstruction method from failing when Channel initialization failed
* Fix SSL channel credential when an argument is NoneGravatar Mehrdad Afshari2018-09-17
|
* Merge pull request #16378 from ghostwriternr/module-level-logger-fixGravatar Nathaniel Manista2018-09-06
|\ | | | | Configure module level loggers with basicConfig().
* | Check poll strategy in core fork handler and log error if unsupportedGravatar Eric Gribkoff2018-08-23
| |
* | Support tracking and closing fds post-fork in ev_poll_posixGravatar Eric Gribkoff2018-08-23
| | | | | | | | | | | | | | 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
* | Move _server_cert_config_fetcher_wrapper to credentials.pyx.pxiGravatar Mehrdad Afshari2018-08-22
| |
* | Python post-fork handler: exit if grpc shutdown failsGravatar Eric Gribkoff2018-08-22
| |
* | Support gRPC Python client-side fork with epoll1Gravatar Eric Gribkoff2018-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * Configure module level loggers with basicConfig()Gravatar Naresh2018-08-17
|/ | | | | | | | | | | 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().
* Replace is by == for a status comparisonGravatar Paul Petit2018-08-16
| | | | | | | 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.
* check if channel is closed before starting core opsGravatar Eric Gribkoff2018-08-09
|
* Add op index support for custom hooksGravatar Mehrdad Afshari2018-08-02
|
* Add low-level Cython debug/expansion hooksGravatar Mehrdad Afshari2018-08-02
|
* Add a matching _unwrap_grpc_argGravatar Mehrdad Afshari2018-07-31
|
* Add Cython functionality to directly wrap grpc_argGravatar Mehrdad Afshari2018-07-30
|
* Create verify_peer_options when creating ssl credentials in order to expose ↵Gravatar Ian Haken2018-06-12
| | | | | | a verification callback option. These options are not yet exposed to languages outside of core.
* Update grpc_gevent cython files to include .pxiGravatar Naresh2018-06-11
| | | | | | | 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.
* Merge pull request #14879 from santoshankr/python_ssl_session_cache_lruGravatar Nathaniel Manista2018-06-08
|\ | | | | TLS session resumption support for Python clients.
* \ Merge pull request #14557 from ghostwriternr/py-custom-loggerGravatar Nathaniel Manista2018-06-07
|\ \ | | | | | | Update logging in Python to use module-level logger.
| | * TLS session resumption support for Python clientsGravatar Santosh Ananthakrishnan2018-06-07
| |/ |/| | | | | | | | | | | | | 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.
* | Merge pull request #15666 from nathanielmanistaatgoogle/15662Gravatar Nathaniel Manista2018-06-07
|\ \ | | | | | | Retain references to channel arguments.
| * | Retain references to channel argumentsGravatar Nathaniel Manista2018-06-06
| | | | | | | | | | | | | | | This works around issue 15662 which is not as easy to implement as I would prefer it to be.
* | | Merge remote-tracking branch 'upstream/v1.12.x' into upmerge_changesGravatar kpayson642018-06-01
|\ \ \
| * | | Use gevent greenlets for metadata callbacksGravatar kpayson642018-05-31
| |/ /
| | * Update logging in Python to use module-level loggerGravatar Naresh2018-05-31
| |/ |/| | | | | | | | | | | 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:`
* | Surfaces debug_error_string to Python APIGravatar Noah Eisen2018-05-17
|/ | | | | In case of error, the user can access call.debug_error_string() which contains a string representation of error from the c core.
* Keep Core memory inside cygrpc.Channel objectsGravatar Nathaniel Manista2018-05-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-16 12:45:34 +0000