- 01 Mar, 2023 4 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
It seems to have caused confusion regarding the relation between io_uring and the fellow memory cache, which exists only to the extent that io_uring manages IO in and out of it.
-
Nils Goroll authored
-
Nils Goroll authored
Previous code would only deliver fully received segments even if a busy object was being written to by the backend side (streaming). I guess at some point before the public release I must have thought about this and decided that streaming only completed segments should be acceptable at least to begin with, but I overlooked the fact that the previous implementation could lead to short body writes due to a lack of coordination between the writing and reading side. This commit introduces proper streaming support, also within busy segments. In particular, this should also solve an issue reported by @tomazz75 on gitlab where no body was sent at all. This problem could lead to the client stalling on a wait for body data which never came. The nature of this problem was a race condition, which I was only able to reproduce on my system with the following patch to favor the race: diff --git a/src/fellow_cache.c b/src/fellow_cache.c index 3073b35..c9d9a4e 100644 --- a/src/fellow_cache.c +++ b/src/fellow_cache.c @@ -3338,6 +3338,9 @@ fellow_busy_obj_getspace(struct fellow_busy *fbo, size_t *sz, uint8_t **ptr) assert(*sz > 0); AN(ptr); + // XXX DEBUG + usleep(10000); + CHECK_OBJ_NOTNULL(fbo->fc, FELLOW_CACHE_MAGIC); CHECK_OBJ_NOTNULL(fbo->fc->tune, STVFE_TUNE_MAGIC); max = (size_t)1 << fbo->fc->tune->chunk_exponent; This fix survived 1000 calls to the respective test case: /tmp/bin/varnishtest \ -Dlibvmod_slash=/tmp/lib/varnish/vmods/libvmod_slash.so \ src/vtc/fellow_c00093.vtc \ -n 1000 -j 20 Thank you to @tomazz75 for reporting the bug and help with additional information to track it down. Fixes #2
-
- 28 Feb, 2023 4 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
The next segment might not be available yet when we try to read ahead.
-
Nils Goroll authored
Should fix this assertion failure during shutdown for the most part (draining a storage still is not guaranteed to succeed): Assert error in LRU_Free(), storage/storage_lru.c line 77: Condition((((&lru->lru_head)->vtqh_first == ((void*)0))) != 0) not true.
-
- 27 Feb, 2023 3 commits
-
-
Nils Goroll authored
Avoid users accidentally running into a file being created where block devices would normally live. Motivated by #2
-
Nils Goroll authored
-
Nils Goroll authored
I had missed to move these when I changed the locking scheme of rewrites before the public release, and I find it curious that my test systems did not complain. Anyway, fixes #1
-
- 24 Feb, 2023 1 commit
-
-
Nils Goroll authored
-
- 06 Feb, 2023 2 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
-