-
Dridi Boukelmoune authored
Now that VCLs can be referenced, there are two different situations stalling the cooldown. The "cooling" one is kept for VCLs that have received a COLD event, and the "busy" one is introduced to wait for ongoing transactions. Basically, if there are transactions, the VCL is still active even though it's not *the* active VCL and should therefore be considered warm. This guarantees that WARM and COLD events are balanced, and also that a "busy" VCL doesn't need to warm up if it is set to warm again. The new VCL temperature engine looks like this: .----------W>---------------. | .--W>---. v init ---> cold --| |-- warm --. ^ ^ '---<C--' | | | | | | | '--- cooling <C--' | | ^ | | C | | | .---<---. | '--<C-- busy --| |--' '--->---' The transitions marked with a 'W' or a 'C' are the one dispatching WARM and COLD events respectively. Since the "busy" state is considered warm, VMODs should operate as such and backend creation remains possible.
57a5b9c7
Name |
Last commit
|
Last update |
---|---|---|
.. | ||
cache | ||
common | ||
hash | ||
http1 | ||
mgt | ||
proxy | ||
storage | ||
waiter | ||
Makefile.am | ||
Makefile.phk | ||
builtin.vcl | ||
flint.lnt | ||
flint.sh | ||
vclflint.lnt | ||
vclflint.sh |