Tags: OddSource/pysoa
Tags
Released PySOA version 0.64.0 Changelog Details: - [MINOR] Respawn crashed workers when running in forking mode - By default, when running in forking mode, PySOA will respawn crashed workers. - If a worker crashes 3 times in 15 seconds or 8 times in 60 seconds, PySOA will give up and stop respawning that worker. - The new `--no-respawn` argument can disable this behavior if necessary. - If all workers crash too many times and PySOA runs out of workers, it exits (this is basically the existing behavior, except for the above-described respawning). - [MINOR] Add first functional tests and fix some bugs - Create a functional test environment using Docker/Docker Compose and a simple shell script. - Add an initial set of functional tests. - Fix several bugs regarding signal handling in the `Server`, server process forking, and file-watching auto-reloader: - If the server received several simultaneous signals (for example, if Ctrl+C is used), the signal handler could be invoked in parallel two or more times, resulting in, at best, forcefully-terminating the server and, at worst, that plus a bunch of concurrency errors. This is now fixed. - If server process forking was enabled or the file-watching auto-reloader was enabled, non-Ctrl+C signals (such as those from Docker when running within a container) were suppressed, meaning the server would not stop. - [PATCH] Re-organize all tests into `unit`, `integration`, and `functional` test modules
Released PySOA version 0.62.0 Changelog Details: - [MINOR] Switch to using Conformity's class schemas (all existing configurations are backwards compatible and will continue to work). - [MINOR] Deprecated `pysoa.server.settings.PolymorphicServerSettings` and `pysoa.client.settings.PolymorphicClientSettings`. The base `ServerSettings` and `ClientSettings` are now automatically polymorphic and you should use / inherit from those, instead. - [MINOR] Changed the default settings class in `Client.settings_class` from `PolymorphicClientSettings` to `ClientSettings`. - [MINOR] Changed the default settings class in `Server.settings_class` from `PolymorphicServerSettings` to `ServerSettings`. - [MAJOR] Refactored the schemas in `LocalClientTransportSchema`, `LocalServerTransportSchema`, `RedisTransportSchema`, `StubClientTransportSchema, and `MetricsSchema` to support the new Conformity class schemas. This breaking change is only a disruption if you are using these classes directly. However, this is unusual and you are probably not. This does not break configurations that were processed by these schemas. - [MAJOR] Deleted module `pysoa.common.schemas` and its classes `BasicClassSchema` and `PolymorphClassSchema`. This breaking change is only a disruption if you are using these classes directly. However, this is unusual and you are probably not. - [MINOR] Previously, when a `Settings` object failed to validate against the settings schema, it might have raised `ValueError`, Conformity's `ValidationError`, _or_ `Settings.ImproperlyConfigured`. Now it will _always_ raise _only_ `Settings.ImproperlyConfigured` when it fails to validate against the settings schema.