- 15 Jan, 2024 4 commits
-
-
Poul-Henning Kamp authored
-
-
Poul-Henning Kamp authored
This should be a no-op on all contemporary UNIX implementations, but let's see what vtest tells us...
-
Poul-Henning Kamp authored
-
- 10 Jan, 2024 3 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
- 09 Jan, 2024 1 commit
-
-
Poul-Henning Kamp authored
It's amazing how long time it takes to find a delay of half a second...
-
- 08 Jan, 2024 3 commits
-
-
Nils Goroll authored
or rather, has been for some time now.
-
Nils Goroll authored
and document the default of the other methods. Ref #4036
-
Dridi Boukelmoune authored
There is a default value when the property is not implemented and has no callback. Fixes #4036
-
- 02 Jan, 2024 2 commits
-
-
Nils Goroll authored
of 08350519
-
Dridi Boukelmoune authored
Rawhide is not stable and we already have a job for the latest stable branch.
-
- 31 Dec, 2023 3 commits
-
-
Nils Goroll authored
The objiterate_f interface requires that OBJ_ITER_END be sent, preferrably with the last chunk of data, but at least after it.
-
Nils Goroll authored
It was not documented explicitly anywhere, but the len/wsl argument to STV_NewObject() is the amount of space to allocate for all OBJ_VARATTRs combined which are going to be written to this object. For now, these are OA_HEADERS and OA_VARY only (see include/tbl/obj_attr.h). So for one, there is no reason to force this argument be greater than zero when we know that no OBJ_VARATTRs are going to be set. Secondly, this might actually represent a minor shortcoming of the stevedore API, because the amount of space which a stevedore implementation actually needs might be larger than what the simple stevedores use. So for now, the semantics of this argument are, more specifically, "the equivalent of space for OBJ_VARATTRs as for simple storage". In practice, this probably does not matter much... But even before this clarification, the API was not used consistently: For the call from vrb_pull(), the maximum request body size (to cache) was used as the wsl argument, yet it has nothing to do with the object body size, it specifies the amount of space to allocate for variable sized object attributes (see above). For the call from cnt_synth(), a somehow arbitrary value of 1KB was used. In both cases, the amount of space actually required is zero, because the only attribute used on the objects created is OA_LEN, which is fixed and thus always present.
-
Nils Goroll authored
There are two sizeof calls here with the same semantics, make them the same.
-
- 27 Dec, 2023 3 commits
-
-
Nils Goroll authored
Initialize the private pointer directly, instead of indirectly via the request struct.
-
Nils Goroll authored
-
Nils Goroll authored
This is to prepare for reuse, but arguably the new home might actually be the better place?
-
- 21 Dec, 2023 2 commits
-
-
Nils Goroll authored
This reverts commit 2cae3597. See #4033
-
Nils Goroll authored
-
- 19 Dec, 2023 1 commit
-
-
Dridi Boukelmoune authored
-
- 11 Dec, 2023 9 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
for consistency with (struct busyobj).vfp_filter_list
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Nils Goroll authored
Struct vdp_ctx has wrk and vsl members, use these instead of req.
-
Nils Goroll authored
for improved greppability, cosistently name struct vdp_ctx * variables vdc.
-
Nils Goroll authored
-
- 07 Dec, 2023 1 commit
-
-
Nils Goroll authored
Ref 5583667f Ref #4013
-
- 06 Dec, 2023 2 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
- 05 Dec, 2023 6 commits
-
-
Nils Goroll authored
we need a signal if the fix is in
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Dridi Boukelmoune authored
The 503 synth and 500 minimal response status codes are too misleading in this context, where the failure is attributed to the client. Among existing 4XX status codes, this is the closest if we stretch the timeout definition to "didn't complete rapidly enough before the client went away".
-
Nils Goroll authored
When copying a stale object after a 304 revalidation, we iterated over it and allocated new storage for each storage segment. So, at best, we kept the fragmentation of the existing object, or made it even worse. This is particularly relevant when the existing object was created from a chunked response, in which case the original segments might have been particularly small and, consequently, many in number. Because we wait for the stale object to complete, we know the total length (OA_LEN) upfront, and can ask the storage serving the copy for exactly the right length. This is much more efficient, as fragmentation is lowered and the storage engine might make a much better allocation decision when it knows the full length rather than getting piecemeal requests. We implement the improved allocation scheme through additional state kept for the duration of the template object copy: struct vbf_objiter_priv holds the pointer to the newly created busy object, the total yet unallocated length (initialized to OA_LEN of the existing object) and pointer/length to the unused portion of the currently open segment, if any.
-
Nils Goroll authored
It is my understanding that the objtrimstore stevedore API function is only to be called once when the object is complete, which I believe is also in line with the comment on ObjExtend() that "The final flag must be set on the last call". If this understanding of the API is correct, we did not adhere to it in the fetch code when we made a copy of an existing stale object after a 304 response: There, we iterated over the stale object and did not set the final flag just once when the object was complete, but rather after each storage segment was copied. This commit fixes this, adds some pedentry to the simple storage and extends b00062.vtc to test this behavior specifically. On top, g6.vtc also triggered without the fix but the duplicate trim detection in place. This issue has originally surfaced in the SLASH/fellow storage where the trimstore function implicitly asserted to only be called once. Ref 115742b0 Ref https://gitlab.com/uplex/varnish/slash/-/issues/33
-