mirror of
https://github.com/varnishcache/varnish-cache.git
synced 2025-11-01 15:07:39 +00:00
Page:
VIP22: include backend connection in director lookup
Pages
Coverity scans
FAQ
Home
Maintenance branch commit guidelines
Release procedure
SLT inventory
VDD18Q3
VDD19Q3
VDD22Q2
VDD23Q3
VDD25Q2
VIP 17: Enable Unix domain sockets for listen and backend addresses
VIP 18: RST specification for code generation
VIP 19: Declare ENUM types in VCC for VMODs
VIP 23: Refactor VSL to support extracting structured data from "binary" log payloads
VIP 24: Hitpass turning into hitmiss after ttl
VIP 25: Inconsistent responses when VFP fails during streaming
VIP 26: limit private prefetch
VIP 27: Move some VCL variables to the catflap facility
VIP 30: bereq.body_filters
VIP11: Shared Memory revamp
VIP12: vmod polymorphism (for type conversions)
VIP13: VMOD versioning
VIP14: *.body access
VIP15: Specifying source address for outgoing sockets
VIP16: Retire parameters aliases
VIP1: PRIV_* visibility and lifetime control
VIP20: Varnish ABI and packaging
VIP22: include backend connection in director lookup
VIP29: VCL labels and backend.list ( r option etc.)
VIP2: VCL typed functions
VIP30: Plumbing: vcl_raw() and vcl_pipe()
VIP31: Backend connection queue
VIP32: VSL API and Unset headers
VIP33: Connection Pool Statistics
VIP33: Socket.* CLI commands
VIP34: Conservative map usage in shared memory
VIP35: Retire libvgz
VIP3: VCL implemented VMODS
VIP4: Restrict VMOD function call sites
VIP6: What does pipe mean in Varnish5?
VIP7: Least connection director
VIP8: No pipe in builtin.vcl in V5
VIP9: Expand VCL object support
Varnish Developer Days
Varnish Improvement Proposals
Varnish developer wiki
No results
Ref: https://github.com/varnishcache/varnish-cache/issues/2765
Synopsis
In directors, the lookup and connection step are separate. For some scenarios, having an atomic "choose backend and return a connection" operation is required.
Why?
- A director may return a backend which has
max_connectionsreached by the time the actual connection is made- as a special case, a 100% correct last connections director is not currently possible
- We need to (ab)use the retry mechanism as a workaround. If lookup of a backend and making a connection was an atomic operation, directors could guarantee to only hand out backends with a working connection.
How?
Ideas:
- change the director paradigm away from implementing a resolve function to implementing a gethdrs function where resolution, making the connection and getting the headers all must succeed, with the option for the director to try other backends upon failure
- seems to be the cleanest solution, but only works well in practice of all used directors implement gethdrs this way
- make the result of the resolve function a list of backends to try in order