Forum: NGINX EY Load balancer - Does this work with the newest dev version?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Asif A. (Guest)
on 2009-03-17 10:58
(Received via mailing list)
Just checking if the EY load balancer has been tested with the latest
development version..

regards

Asif A.
Ryan Dahl (Guest)
on 2009-03-17 20:49
(Received via mailing list)
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/afccd5...


ry
Jauder H. (Guest)
on 2009-04-18 02:57
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/afccd5...
>
>
> ry
Jb j. (Guest)
on 2009-04-28 11:40
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/afccd5...
>
>
> ry
Ryan Dahl (Guest)
on 2009-04-28 14:14
(Received via mailing list)
> 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/afccd5...
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.
Maxim D. (Guest)
on 2009-04-28 16:28
(Received via mailing list)
Hello!

On Tue, Apr 28, 2009 at 12:05:44PM +0200, Ryan Dahl wrote:

> 
http://github.com/ry/nginx-ey-balancer/blob/afccd5...
> 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.
Ryan Dahl (Guest)
on 2009-04-28 17:09
(Received via mailing list)
> 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?
This topic is locked and can not be replied to.