Questions on backend allocations
dridi at varni.sh
Fri Jun 12 11:28:07 CEST 2015
I will try to wrap up the model I was suggesting on IRC.
For starters, I refer to dynamic backends as *native* backends (ones
you can see in varnishstat) managed by a VMOD instead of VCL.
We agreed that even though a VMOD lifespan can exceed the lifespan of
a VCL, a dynamic backend cannot survive its VCL. For this reason I
find VCL objects compelling for VMOD writers, because VMODs merely
allocate/free objects, while VCLs manage/use them.
One wouldn't be required to tie dynamic backends to an object, but
they would have to keep track of the per-VCL resources themselves.
For cold/warm state, I'm all for passing the events to VMODs (if the
event specifies which VCL is sending the event) or even better to
objects (since they *are* managed by a VCL).
Allowing VMODs to follow the cold/warm state on their own resources
Putting all this together:
- VCLs own static backends
- VMODs should own dynamic backends
- Objects are the best candidates to manage dynamic backends
- VCLs should only send events to things it manages:
static resources, objects (not sure about VMODs)
- VMODs *can* propagate events to backends
Of course the last bullet point means more work for VMOD writers, but
in most cases it's probably just walking a data structure and forwarding
the event to each item.
It also has the advantage of not introducing order issues, and allowing
VMODs to override the VCL warm/cold state policy.
The first bullet point on the other hand means only *minor* modifications
are needed in Varnish to enable that.
 but what happens on vmod_tour, stays on vmod_tour
On Thu, Jun 11, 2015 at 11:16 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> I've been pop'ing stack and come back down to this old topic.
More information about the varnish-dev