Skip to content

Latest commit

 

History

History
117 lines (75 loc) · 3.39 KB

Changelog-1.9.4.rst

File metadata and controls

117 lines (75 loc) · 3.39 KB
Raw

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 javascript itself 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 :doc:`Legion` The objective is have a rock-solid clustering implementation for uWSGI 2.0 that 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

https://projects.unbit.it/downloads/uwsgi-1.9.4.tar.gz