- 04 Sep, 2018 11 commits
-
-
Nils Goroll authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
Most of the heavy lifting by: slink Fixes: #2760, #2754, #2654
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
require new bytes to be received.
-
Poul-Henning Kamp authored
-
Dridi Boukelmoune authored
Refs 9804794a
-
Poul-Henning Kamp authored
Partial fix for #2654 and #2754
-
- 03 Sep, 2018 8 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
The syntax is expect <skip> <vxid> <tag> <regex> Also remove some bogus .*$ from regexen (waving to @slimhazard)
-
Nils Goroll authored
return(pass) from vcl_recv does not take a duration argument
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
Fix vmodtool with python3
-
Bernhard M. Wiedemann authored
Without this patch, it did TypeError: Unicode-objects must be encoded before hashing Fixes: #2436
-
Poul-Henning Kamp authored
I belive this makes our builds reproducible. Fixes: #2436
-
- 31 Aug, 2018 1 commit
-
-
Pål Hermunn Johansen authored
Fixes: #2753
-
- 30 Aug, 2018 4 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
For tests which do not require new connections for repetitions (for example because of possible error conditions), this reduces run time and the number of required ephemeral ports. The latter is a real issue when running many vtcs in parallel which each run many repetitions of the same test (for example to check for possible race conditions). When ephemeral ports are exhausted, seemingly unrelated issues like the following can be observed: ---- c1010 14.0 Failed to open 127.0.0.1 59763: (null) **** v1 1.8 vsl| 0 CLI - Wr 300 65 Listen failed on socket '127.0.0.1:33328': Address already in use **** v1 1.8 vsl| 0 CLI - EOF on CLI connection, worker stops An argument could be made that UDS does not suffer from the port exhaustion issue and thus such tests could be migrated to UDS. Yet also for this case the run time point remains, plus deliberately testing many iterations on a single connection could have its own merits.
-
Nils Goroll authored
Tests 20ab2abc
-
Poul-Henning Kamp authored
-
- 29 Aug, 2018 3 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
... and fail the VCL unless successful. Providing the PRIVs to vmods is a core function, so error handling should happen outside vmods. Besides being safe, this initialization can be more efficient than previous code for PRIVs used frequently within the same subroutine. An alternative approach would be to initialize all privs once per task / top request, but unless all privs are actually used in a VCL, this approach could impose significant overhead, both in terms of time and memory. By initializing privs once per sub, we impose overhead for privs which are referenced but not actually used in a subroutine, but not for all of the vcl. Fixes #2708
-
Poul-Henning Kamp authored
-
- 28 Aug, 2018 10 commits
-
-
Poul-Henning Kamp authored
per-task PRIVs. Fixes: #2749
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
the purpose of VRT_priv_task()
-
Federico G. Schwindt authored
-
Federico G. Schwindt authored
-
Poul-Henning Kamp authored
Previously we used various heuristics (test TCP connection) to avoid the reschedule if the req was abandonned while on the waiting list. We also subjected the rescheduling to pool-queue limits like any new request. This was all safe because we knew we could clean up the request state cheaply, even if it was somewhat cumbersome. Now vmods can have per-task PRIV's and we have no idea what it will cost us (stack, time, etc) to clean them up, so we cannot burden J.Random Request who happens to rush the waiting list with the burden. Fix this by always rescheduling, not subject to pool-queue limits, and eliminate all the special-casing for exceeded limits, including the debug feature to force a rescheduling failure and two tests exercising it. As a side effect of this, requests on the waiting list gets a "business class upgrade" over newly arriving requests when there are no worker threads available. Given that these requests arrived earlier, and we already performed work on them, this seems only fair. Forced to pay proper attention by: slink
-
Nils Goroll authored
works around #2297
-
Nils Goroll authored
-
Dridi Boukelmoune authored
-
Poul-Henning Kamp authored
-
- 27 Aug, 2018 3 commits
-
-
Dridi Boukelmoune authored
-
Nils Goroll authored
-
Nils Goroll authored
Fixes #2746
-