uWSGI 1.9.4
Changelog 20130330
Bugfixes
fixed cache statistics exported by the stats subsystem (Łukasz Mierzwa)
fixed CoroEV bug in after_request (Tom Molesworth and John Berthels)
update cache items after a restore from persistent storage (Łukasz Mierzwa)
fixed signal handling in non-worker processes
fixed thundering herd in multiple mules setup
ported the cplusplus skeletal plugin to the new api
fixed uWSGI reloading when build as a shared library
New features
SmartOS official support
From now on, SmartOS is included in the officially supported operating systems
V8 initial support
The Lua previous suggestion for writing uWSGI routing rules and configurations, woke up lot of javascript users stating that javascriptitself could be a valid alternative. A V8 plugin is now available, supporting RPC, signal handlers and configurations. You need libv8 headers to build it:
- python uwsgiconfig.py --plugin plugins/v8
- var config = {};
- config['socket'] = [':3031', ':3032', ':3033'];
- config['master'] = true;
- config['processes'] = 3+1;
- config['module'] = 'werkzeug.testapp:test_app';
- config;
- uwsgi --plugin v8 --config foo.js
The previous example will allows you to write dynamic configs in javascript, while you can export javascript functions via the RPC subsystem:
- function part1(request_uri, remote_addr) {
- return '<h1>i am part1 for ' + request_uri + ' ' + remote_addr + "</h1>" ;
- }
- function part2(request_uri, remote_addr) {
- return '<h2>i am part2 for ' + request_uri + ' ' + remote_addr + "</h2>" ;
- }
- function part3(request_uri, remote_addr) {
- return '<h3>i am part3 for ' + request_uri + ' ' + remote_addr + "</h3>" ;
- }
- uwsgi_register_rpc('part1', part1);
- uwsgi_register_rpc('part2', part2);
- uwsgi_register_rpc('part3', part3);
- [uwsgi]
- plugin = v8
- v8-load = func.js
- cache2 = name=foobar,items=10
- http-socket = :9090
- route-run = addheader:Content-Type: text/html
- route-run = cache:key=pippo,name=foobar
- route-run = cachestore:key=pippo,name=foobar
- route-run = rpcnext:part1 ${REQUEST_URI} ${REMOTE_ADDR}
- route-run = rpcnext:part2 ${REQUEST_URI} ${REMOTE_ADDR}
- route-run = rpcnext:part3 ${REQUEST_URI} ${REMOTE_ADDR}
- route-run = break:
The previous example generates an HTTP response from 3 javascript functions and store it in the uWSGI cache.
Curious about rpcnext ?
The rpcnext routing action
We can already call rpc functions from the routing subsystem to generate response. With the rpcnext action (aliased as rpcblob too)you can call multiple rpc functions and assemble the return values in a single response.
Legion improvements
We are hardly working in stabilizing The uWSGI Legion subsystem The objective is have a rock-solid clustering implementation for uWSGI 2.0that you can use even from your applications.
The code in 1.9.4 has been refactored a bit by Łukasz Mierzwa to allow easier integration with external plugins.
A new “join” hook has been added, it is called as soon as a node becomes active part of a legion (read, it is part of a quorum).
Availability
uWSGI 1.9.4 will be available since 20130330 at this url