Just checking if the EY load balancer has been tested with the latest
development version…
regards
Asif A.
The patch for 0.6.34 can be applied to 0.7.42. It passes all of the
unit tests, which are rather complete, but I don’t know of anyone
using it in the wild.
Igor: would be nice if this patch could get merged. It just allows one
to delay connecting to a backend by returning NGX_BUSY from the
peer.init callback in an upstream module. Seems to work well.
http://github.com/ry/nginx-ey-balancer/blob/afccd5c15e10257e675fb56715dd7d63bfcf4ffc/patches/nginx-0.6.34.patch
ry
Igor,
I would like to second the request to get this merged in as well as the
upstream hash module. Thanks.
–Jauder
Ryan Dahl wrote:
The patch for 0.6.34 can be applied to 0.7.42. It passes all of the
unit tests, which are rather complete, but I don’t know of anyone
using it in the wild.Igor: would be nice if this patch could get merged. It just allows one
to delay connecting to a backend by returning NGX_BUSY from the
peer.init callback in an upstream module. Seems to work well.
http://github.com/ry/nginx-ey-balancer/blob/afccd5c15e10257e675fb56715dd7d63bfcf4ffc/patches/nginx-0.6.34.patchry
I don’t suppose you could restructure things so that only the module is
needed. The upstream-fair patch seems to get away without having to
patch nginx source.
I don’t think it is possible to achieve the request queuing
functionality without modifying Nginx’s source. The patch is a small
change and does not affect how other modules work - it would be nice
if it could be merged.
Igor:
http://github.com/ry/nginx-ey-balancer/blob/afccd5c15e10257e675fb56715dd7d63bfcf4ffc/patches/nginx-0.6.34.patch
It adds a new return value, NGX_BUSY, for the peer.init() callback in
upstream modules. In the case of this, the module can itself decide to
when to call ngx_http_upstream_connect() - until then the request
hangs.
Igor,
Just wanted to add another voice in getting the patch part merged in.
There’s no burning need to get the module part merged in but saving from
having to patch each time would be nice. Besides, it would be nice to
have more than one option for balancing.
Ry,
I don’t suppose you could restructure things so that only the module is
needed. The upstream-fair patch seems to get away without having to
patch nginx source.
–J
Ryan Dahl wrote:
The patch for 0.6.34 can be applied to 0.7.42. It passes all of the
unit tests, which are rather complete, but I don’t know of anyone
using it in the wild.Igor: would be nice if this patch could get merged. It just allows one
to delay connecting to a backend by returning NGX_BUSY from the
peer.init callback in an upstream module. Seems to work well.
http://github.com/ry/nginx-ey-balancer/blob/afccd5c15e10257e675fb56715dd7d63bfcf4ffc/patches/nginx-0.6.34.patchry
From architectural point of view it shouldn’t be returned from
peer.init() but instead from peer.get(). Â It’s not easy to
implement this for peer.get() though - that’s probably why
peer.init() was used instead.
I think it’s okay to do this on a per-module basis. It’s like saying
“this upstream module is going to decide itself when requests get
connected to backends”. I agree that returning NGX_BUSY from
peer.init() is not the best way to signal this. Perhaps, instead,
adding a flag to ngx_http_upstream_srv_conf_t would be acceptable?
Hello!
On Tue, Apr 28, 2009 at 12:05:44PM +0200, Ryan Dahl wrote:
http://github.com/ry/nginx-ey-balancer/blob/afccd5c15e10257e675fb56715dd7d63bfcf4ffc/patches/nginx-0.6.34.patch
It adds a new return value, NGX_BUSY, for the peer.init() callback in
upstream modules. In the case of this, the module can itself decide to
when to call ngx_http_upstream_connect() - until then the request
hangs.
From architectural point of view it shouldn’t be returned from
peer.init() but instead from peer.get(). It’s not easy to
implement this for peer.get() though - that’s probably why
peer.init() was used instead.
Basically the above patch is a “quick hack” and I don’t think it
should be merged.
Maxim D.