]> git.ipfire.org Git - thirdparty/squid.git/commit
REQMOD stuck when adapted request (body) is not forwarded (#1966)
authorAlex Rousskov <rousskov@measurement-factory.com>
Tue, 31 Dec 2024 17:27:40 +0000 (17:27 +0000)
committerSquid Anubis <squid-anubis@squid-cache.org>
Tue, 31 Dec 2024 18:01:31 +0000 (18:01 +0000)
commit94c40964df92cd19393a15d18c9704bec4020362
tree405be2f3b35f2cfab500c55348f791166b09f905
parente66b20c56dfd72e45df5fb2b638994dd9f668d30
REQMOD stuck when adapted request (body) is not forwarded (#1966)

Squid forwards request bodies using BodyPipe objects. A BodyPipe object
has two associated agents: producer and consumer. Those agents are set
independently, at different processing stages. If BodyPipe consumer is
not set, the producer may get stuck waiting for BodyPipe buffer space.
When producer creates a BodyPipe, it effectively relies on some code
somewhere to register a consumer (or declare a registration failure),
but automatically tracking that expectation fulfillment is impractical

For REQMOD transactions involving adapted request bodies, including ICAP
204 transactions, Client::startRequestBodyFlow() sets body consumer. If
that method is not called, there will be no consumer, and REQMOD may get
stuck. Many `if` statements can block request forwarding altogether or
block a being-forwarded request from reaching that method. For example,
adapted_http_access and miss_access denials block request forwarding

Without REQMOD, request processing can probably get stuck for similar
lack-of-consumer reasons, but regular requests ought to be killed by
various I/O or forwarding timeouts. There are no such timeouts for those
REQMOD transactions that are only waiting for request body consumer to
clear adapted BodyPipe space (e.g., after all ICAP 204 I/Os are over).
Relying on timeouts is also very inefficient

For a `mgr:mem` observer, stuck REQMOD transactions look like a ModXact
memory leak. A `mgr:jobs` report shows ModXact jobs with RBS(1) status
src/BodyPipe.cc
src/errorpage.cc