Welcome! Log In Create A New Profile

Advanced

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

July 11, 2024 03:18PM
Do you happen to know if there remains any gap in obvious capability
provided by a module like jdomain compared to this?

Perhaps it would be worth checking to ensure nothing obvious is not
implemented?

The one that I see is the ability to control if a resolution is IPv4, IPv6
or mixed. Is this something that would be useful for this feature?

On Fri, 12 Jul 2024 at 02:40, Aleksei Bavshin <a.bavshin@nginx.com> wrote:

> On 7/9/2024 9:22 AM, Roman Arutyunyan wrote:
> > Hi,
> >
> > On Mon, Jul 08, 2024 at 06:20:58PM +0400, Roman Arutyunyan wrote:
> >> Hi,
> >>
> >> On Thu, Jun 13, 2024 at 03:28:56PM -0700, Aleksei Bavshin wrote:
> >>> # HG changeset patch
> >>> # User Ruslan Ermilov <ru@nginx.com>
> >>> # Date 1392462754 -14400
> >>> # Sat Feb 15 15:12:34 2014 +0400
> >>> # Node ID 56aeae9355df8a2ee07e21b65b6869747dd9ee45
> >>> # Parent 02e9411009b987f408214ab4a8b6b6093f843bcd
> >>> Upstream: re-resolvable servers.
> >>>
> >>> Specifying the upstream server by a hostname together with the
> >>> "resolve" parameter will make the hostname to be periodically
> >>> resolved, and upstream servers added/removed as necessary.
> >>>
> >>> This requires a "resolver" at the "http" configuration block.
> >>>
> >>> The "resolver_timeout" parameter also affects when the failed
> >>> DNS requests will be attempted again. Responses with NXDOMAIN
> >>> will be attempted again in 10 seconds.
> >>>
> >>> Upstream has a configuration generation number that is incremented each
> >>> time servers are added/removed to the primary/backup list. This number
> >>> is remembered by the peer.init method, and if peer.get detects a change
> >>> in configuration, it returns NGX_BUSY.
> >>>
> >>> Each server has a reference counter. It is incremented by peer.get and
> >>> decremented by peer.free. When a server is removed, it is removed from
> >>> the list of servers and is marked as "zombie". The memory allocated by
> >>> a zombie peer is freed only when its reference count becomes zero.
> >>>
> >>> Re-resolvable servers utilize timers that also hold a reference. A
> >>> reference is also held while upstream keepalive caches an idle
> >>> connection.
> >>>
> >>> Co-authored-by: Roman Arutyunyan <arut@nginx.com>
> >>> Co-authored-by: Sergey Kandaurov <pluknet@nginx.com>
> >>> Co-authored-by: Vladimir Homutov <vl@nginx.com>
> >
> > [..]
> >
> >>> diff --git a/src/http/ngx_http_upstream_round_robin.h
> b/src/http/ngx_http_upstream_round_robin.h
> >>> --- a/src/http/ngx_http_upstream_round_robin.h
> >>> +++ b/src/http/ngx_http_upstream_round_robin.h
> >>> @@ -14,8 +14,23 @@
> >>> #include <ngx_http.h>
> >>>
> >>>
> >>> +typedef struct ngx_http_upstream_rr_peers_s
> ngx_http_upstream_rr_peers_t;
> >>> typedef struct ngx_http_upstream_rr_peer_s
> ngx_http_upstream_rr_peer_t;
> >>>
> >>> +
> >>> +#if (NGX_HTTP_UPSTREAM_ZONE)
> >>> +
> >>> +typedef struct {
> >>> + ngx_event_t event; /* must be first */
> >>> + ngx_uint_t worker;
> >
> > Missed this last time. This field should be removed since all resolving
> is in
> > worker #0.
>
> Unfortunately, that would break the ABI compatibility between OSS and
> Plus. Replacing the field with yet another NGX_COMPAT_BEGIN isn't any
> better than leaving it in the opensource code.
>
> >
> >>> + ngx_str_t name;
> >>> + ngx_http_upstream_rr_peers_t *peers;
> >>> + ngx_http_upstream_rr_peer_t *peer;
> >>> +} ngx_http_upstream_host_t;
> >>> +
> >>> +#endif
> >>> +
> >>> +
> >>> struct ngx_http_upstream_rr_peer_s {
> >>> struct sockaddr *sockaddr;
> >>> socklen_t socklen;
> >>> @@ -46,7 +61,12 @@ struct ngx_http_upstream_rr_peer_s {
> >>> #endif
> >>>
> >>> #if (NGX_HTTP_UPSTREAM_ZONE)
> >>> + unsigned zombie:1;
> >>
> >> I suggest declaring this as in other similar places:
> >>
> >> ngx_uint_t zombie; /* unsigned zombie:1;
> */
> >>
> >>> +
> >>> ngx_atomic_t lock;
> >>> + ngx_uint_t id;
> >>
> >> This field is not used in open source nginx and should not be added or
> assigned.
> >>
> >>> + ngx_uint_t refs;
> >>> + ngx_http_upstream_host_t *host;
> >>> #endif
> >>>
> >>> ngx_http_upstream_rr_peer_t *next;
> >
> > [..]
> >
> > --
> > Roman Arutyunyan
> > _______________________________________________
> > nginx-devel mailing list
> > nginx-devel@nginx.org
> > https://mailman.nginx.org/mailman/listinfo/nginx-devel
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-devel
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
Subject Author Views Posted

[PATCH 0 of 9] Upstream: re-resolvable servers.

Aleksei Bavshin 311 June 13, 2024 06:30PM

[PATCH 1 of 9] Upstream: re-resolvable servers

Aleksei Bavshin 71 June 13, 2024 06:30PM

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

Roman Arutyunyan 59 July 08, 2024 10:22AM

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

Roman Arutyunyan 60 July 09, 2024 12:24PM

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

Aleksei Bavshin 58 July 11, 2024 12:42PM

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

splitice 111 July 11, 2024 03:18PM

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

Aleksei Bavshin 80 July 11, 2024 03:44PM

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

splitice 101 July 11, 2024 04:00PM

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

Aleksei Bavshin 63 July 11, 2024 04:34PM

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

splitice 130 July 11, 2024 05:06PM

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

Aleksei Bavshin 61 July 09, 2024 04:22PM

Re: [PATCH 1 of 9] Upstream: re-resolvable servers

Roman Arutyunyan 66 July 10, 2024 11:44AM

[PATCH 2 of 9] Stream: re-resolvable servers

Aleksei Bavshin 65 June 13, 2024 06:30PM

[PATCH 3 of 9] Upstream: construct upstream peers from DNS SRV records

Aleksei Bavshin 67 June 13, 2024 06:30PM

[PATCH 4 of 9] Core: inheritance of non-reusable shared memory zones

Aleksei Bavshin 55 June 13, 2024 06:32PM

Re: [PATCH 4 of 9] Core: inheritance of non-reusable shared memory zones

Roman Arutyunyan 46 July 08, 2024 10:24AM

[PATCH 5 of 9] Upstream: pre-resolve servers on reload

Aleksei Bavshin 58 June 13, 2024 06:32PM

[PATCH 6 of 9] Upstream: per-upstream resolver

Aleksei Bavshin 56 June 13, 2024 06:32PM

Re: [PATCH 6 of 9] Upstream: per-upstream resolver

Roman Arutyunyan 59 July 08, 2024 11:18AM

[PATCH 7 of 9] Upstream: copy upstream zone DNS valid time during config reload

Aleksei Bavshin 57 June 13, 2024 06:32PM

Re: [PATCH 7 of 9] Upstream: copy upstream zone DNS valid time during config reload

Roman Arutyunyan 53 July 08, 2024 11:08AM

[PATCH 8 of 9] Upstream: disable re-resolve functionality on Windows

Aleksei Bavshin 88 June 13, 2024 06:34PM

Re: [PATCH 8 of 9] Upstream: disable re-resolve functionality on Windows

Roman Arutyunyan 55 July 10, 2024 09:18AM

Re: [PATCH 8 of 9] Upstream: disable re-resolve functionality on Windows

Roman Arutyunyan 53 July 11, 2024 02:52AM

Re: [PATCH 8 of 9] Upstream: disable re-resolve functionality on Windows

Aleksei Bavshin 50 July 11, 2024 12:26PM

[PATCH 9 of 9] Tests: upstream configuration tests with re-resolvable servers

Aleksei Bavshin 70 June 13, 2024 06:34PM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 127
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready