- 08 Jan, 2020 2 commits
-
-
Dridi Boukelmoune authored
Contrary to previous attempts this one takes a different route that is much more reliable and faster. First, it sets things up so that we can predicatbly lock varnish when it's trying to send the first (and only) part of the body. Instead of assuming a delay that is sometimes not enough under load, we wait for the timeout to show up in the log. We can't put the barrier in l1 or l2 because logexpect spec evaluation is eager, in order to cope with the VSL API. Because we bypass the cache, we can afford letting c1 bail out before completing the transaction, which is necessary because otherwise the second c1 run would take forever on FreeBSD that takes our request to limit the send buffer to 128 octets very seriously (on Linux we get around 4k). Because we use barriers, the send and receive buffers were bumped to 256 to ensure c1 doesn't fail (on FreeBSD) before it reaches barrier statements.
-
Dridi Boukelmoune authored
-
- 05 Jan, 2020 2 commits
-
-
Federico G. Schwindt authored
-
Federico G. Schwindt authored
-
- 03 Jan, 2020 2 commits
-
-
Dridi Boukelmoune authored
This reverts commit df9f3489. It succeeded in terms of determinism but there is another underlying bug to fix so it will be submitted again via #3178 instead.
-
Dridi Boukelmoune authored
The fetch may be interrupted before s1 has time to buffer the complete response.
-
- 02 Jan, 2020 3 commits
-
-
Dridi Boukelmoune authored
This test has been relying on SLT_Debug records from day one and now that we have SLT_Notice we could perpetuate this information and at the same time grant ourselves the freedom to explain each case and which parameters may be used to try to improve the situation.
-
Dridi Boukelmoune authored
I'm no longer able to time it out under load.
-
Dridi Boukelmoune authored
There was a race with the reuse of s1 and server -dispatch was the simplest way to also circumvent the race where varnish could retry before s1 would reach the next accept action. While at it, add coverage for the 503 case.
-
- 01 Jan, 2020 3 commits
-
-
Federico G. Schwindt authored
Apparently this is missing in sunos+gcc 4.7. While here tight things up a bit.
-
Dridi Boukelmoune authored
The previous tweak paid off, the problem is not an unexpected ReqAcct when this test fails, but a lack of logs during the check.
-
Federico G. Schwindt authored
-
- 31 Dec, 2019 2 commits
-
-
Dridi Boukelmoune authored
The test cases disabling the accept_filter parameter are those involving GET requests with a body that are meant to be cached, and one test case covering OOB data. The rest uses the POST method since the httpready filter will only let syntactically correct GET or HEAD methods pass to the application. Apparently FreeBSD's httpready filter considers that a GET request with a body is syntactically incorrect although this is not specifically said in the manual. The HTTP specification doesn't forbid such requests and they are hard to justify considering the semantics of GET and HEAD, but there are products in the wild relying on that. On the other hand GET\r\n\r\n isn't considered malformed, see r01881.vtc. We don't need the dataready filter on FreeBSD for listen addresses that expect a PROXY protocol header, the httpready filter will effectively work like that if the request doesn't look like a GET or a HEAD.
-
Dridi Boukelmoune authored
Trying to understand why I was seeing setsockopt fail on FreeBSD VTEST boxes and why it failed with an undocumented ENOENT I finally realized that I needed to kldload accf_http beforehand. The ENOENT errno was probably a result of accept_filter code not finding a kernel module for "httpready".
-
- 30 Dec, 2019 7 commits
-
-
Dridi Boukelmoune authored
I couldn't reproduce the failure reported by VTEST but hopefully this will shed some light next time it happens. Better diff with the --word-diff option.
-
Dridi Boukelmoune authored
The change in u00011.vtc is the result of having two commands starting with "pi", breaking auto-completion. Fortunately "pin\t" still does the trick.
-
Poul-Henning Kamp authored
-
Dridi Boukelmoune authored
It was a bit racy in the sense that the logs for c2 could be committed before the c1 logs. I hardened the expectations a bit in the process.
-
Dridi Boukelmoune authored
This adds the errno value to error logs for TCP fast open and accept filters. For FreeBSD errno is cleared prior to calling setsockopt with the hope that it will help understand if it's actually failing with an undocumented ENOENT. Speaking of documentation, the return value is either 0 or -1 for so there's no point in logging that.
-
Dridi Boukelmoune authored
Once all instances of a given test are started all of the remaining tests would free the test data structure, we needed another counter to keep track of ongoing tests so that only the last one to finish would do the single free.
-
Dridi Boukelmoune authored
-
- 29 Dec, 2019 7 commits
-
-
Guillaume Quintard authored
-
Guillaume Quintard authored
-
Guillaume Quintard authored
-
Guillaume Quintard authored
-
Guillaume Quintard authored
-
Guillaume Quintard authored
-
Guillaume Quintard authored
-
- 27 Dec, 2019 5 commits
-
-
Dridi Boukelmoune authored
This is only a matter of leaving the acceptor loop to always free the poolsock before returning from the function. This was initially done in only one place out of three, with no room to exit the accept inner loop in the absence of an incoming connection. With this we may have everything in place to drop the drop_pools debug flag. Refs 656982a5 Closes #3177
-
Dridi Boukelmoune authored
For those that aren't leaked on purpose, that is...
-
Dridi Boukelmoune authored
Upon failure, don't destroy the underlying director implementation. When the deletion code was split in c671bb66 in order to be reused in 61529854, it mistakenly included the director implementation. Instead, it's really the caller's job to tear down the backend if it couldn't be added. Since vbe_destroy operates on a director, it is split in two to avoid reintroducing the previous "undo" code duplication. Refs #3176
-
Dridi Boukelmoune authored
Otherwise at this point nothing is undone. And backend creation while a VCL is stuck in the COOLING state should be unlikely enough that we can assume the happy path by default. Refs #3176
-
Federico G. Schwindt authored
Fixed in 7ff636dc.
-
- 26 Dec, 2019 3 commits
-
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
When a VCL is in the COOLING state it is supposed to delete the director that was being added, but at the same time when a VBE backend fails to be added as a director it would also undo itself. This is in general a code path very hard to reach because either this happens in a worker and the opportunistic check always kicks in to hide the problem or this is done asynchronously (e.g. non-blocking lookups to create dynamic backends) and the race window is very small. In order to solve this the opportunistic check is skipped in VTC mode. The test coverage with vmod_debug is done synchronously to make things easier, but for this reason vbe_destroy can no longer expect to only run in the CLI thread. This is inspired by a similar patch by Martin for a different branch, since VRT_AddDirector deletes the backend upon failure, everything needs to be set up beforehand. We have to tolerate backend creation attempts in a COOLING VCL because in the asynchronous case the VCL temperature will change before COLD events are dispatched so there's no way to prevent a race. Closes #3176
-
Dridi Boukelmoune authored
Refs #3176
-
- 24 Dec, 2019 3 commits
-
-
Guillaume Quintard authored
if version is trunk, change it to the current date and add a flag file so that packages can be suffixed with -weekly/.weekly depending on the platform
-
Martin Blix Grydeland authored
VRT_delete_backend() sets be->cooled to non-zero as the only place where that is done. Assert that it is zero on entry as a check that VRT_delete_backend isn't called multiple times.
-
Martin Blix Grydeland authored
Several functions (VBE_Poll and vbe_destroy) tests be->cooled == 0 to determine which of the two lists backends and cool_backends a specific instance currently lives on. If the flag is in the process of being changed, then the wrong list head may be used and will result in strange bugs.
-
- 23 Dec, 2019 1 commit
-
-
Dridi Boukelmoune authored
We don't need randomness where we could have determinism.
-