Loading src/config/BootstrapConfig.cpp +2 −0 Changes for src/config/BootstrapConfig.cpp: 2 added lines, 0 removed lines. Original line number Diff line number Diff line Loading @@ -238,6 +238,8 @@ void BootstrapConfig::loadAndValidate() { readInt(conf, "/proxyplus/process/upstream_request_timeout_seconds", 60); cfg.h2DispatchQueueMax = readInt(conf, "/proxyplus/process/h2_dispatch_queue_max", 256); cfg.h1DispatchQueueMax = readInt(conf, "/proxyplus/process/h1_dispatch_queue_max", 256); cfg.pidFile = readValue(conf, "/proxyplus/pid_file", ""); cfg.recoveryMode = readBool(conf, "/proxyplus/recovery_mode", false) ? RecoveryMode::Recover Loading src/config/BootstrapConfig.h +10 −0 Changes for src/config/BootstrapConfig.h: 10 added lines, 0 removed lines. Original line number Diff line number Diff line Loading @@ -133,6 +133,16 @@ struct AppConfig { // long-lived streaming responses off this pool entirely, not raising this further. int h2DispatchQueueMax = 256; // H1 analogue of h2DispatchQueueMax above (see libhttppp::HttpEvent's h1DispatchQueueMax // ctor param) -- until this existed, _h1DispatchPool had no bound at all, so a saturated // pool left every subsequent offloaded H1 request's socket detached from the event loop // (invisible to the idle reaper) and un-timed until a worker finally freed up. If the // client had already given up by then, proxyplus discovered it far too late and started // its own close against a peer that might already be gone -- the real root cause behind // sockets observed stuck in LAST_ACK under load (see the 08-16 netstat lead). Positive by // default for the same reason h2DispatchQueueMax is: degrade to a fast 503 out of the box. int h1DispatchQueueMax = 256; RecoveryMode recoveryMode = RecoveryMode::Normal; MaintenanceMode maintenanceMode = MaintenanceMode::Off; }; Loading src/http/HttpProxyServer.h +4 −1 Changes for src/http/HttpProxyServer.h: 4 added lines, 1 removed line. Original line number Diff line number Diff line Loading @@ -37,6 +37,8 @@ public: // param (see httpd.h) -- caps how many H2 streams queue for a free offload worker before // proxyplus answers 503 instead of piling up behind a saturated (or fully stuck) pool; // main.cpp's real call sites pass AppConfig::h2DispatchQueueMax. // h1DispatchQueueMax is the H1 analogue, forwarded to HttpEvent's own h1DispatchQueueMax // ctor param; main.cpp's real call sites pass AppConfig::h1DispatchQueueMax. HttpProxyController(std::vector<netplus::socket *> serverSockets, std::string listenerLabel, bool tlsActive, Loading @@ -48,7 +50,8 @@ public: tls::AcmeChallengeStore *acmeChallenges = nullptr, int idleTimeoutSeconds = 0, int upstreamTimeoutSeconds = 60, int h2DispatchQueueMax = 256); int h2DispatchQueueMax = 256, int h1DispatchQueueMax = 256); void RequestEvent(libhttppp::HttpRequest &curreq, const int tid, ULONG_PTR args) override; Loading Loading
src/config/BootstrapConfig.cpp +2 −0 Changes for src/config/BootstrapConfig.cpp: 2 added lines, 0 removed lines. Original line number Diff line number Diff line Loading @@ -238,6 +238,8 @@ void BootstrapConfig::loadAndValidate() { readInt(conf, "/proxyplus/process/upstream_request_timeout_seconds", 60); cfg.h2DispatchQueueMax = readInt(conf, "/proxyplus/process/h2_dispatch_queue_max", 256); cfg.h1DispatchQueueMax = readInt(conf, "/proxyplus/process/h1_dispatch_queue_max", 256); cfg.pidFile = readValue(conf, "/proxyplus/pid_file", ""); cfg.recoveryMode = readBool(conf, "/proxyplus/recovery_mode", false) ? RecoveryMode::Recover Loading
src/config/BootstrapConfig.h +10 −0 Changes for src/config/BootstrapConfig.h: 10 added lines, 0 removed lines. Original line number Diff line number Diff line Loading @@ -133,6 +133,16 @@ struct AppConfig { // long-lived streaming responses off this pool entirely, not raising this further. int h2DispatchQueueMax = 256; // H1 analogue of h2DispatchQueueMax above (see libhttppp::HttpEvent's h1DispatchQueueMax // ctor param) -- until this existed, _h1DispatchPool had no bound at all, so a saturated // pool left every subsequent offloaded H1 request's socket detached from the event loop // (invisible to the idle reaper) and un-timed until a worker finally freed up. If the // client had already given up by then, proxyplus discovered it far too late and started // its own close against a peer that might already be gone -- the real root cause behind // sockets observed stuck in LAST_ACK under load (see the 08-16 netstat lead). Positive by // default for the same reason h2DispatchQueueMax is: degrade to a fast 503 out of the box. int h1DispatchQueueMax = 256; RecoveryMode recoveryMode = RecoveryMode::Normal; MaintenanceMode maintenanceMode = MaintenanceMode::Off; }; Loading
src/http/HttpProxyServer.h +4 −1 Changes for src/http/HttpProxyServer.h: 4 added lines, 1 removed line. Original line number Diff line number Diff line Loading @@ -37,6 +37,8 @@ public: // param (see httpd.h) -- caps how many H2 streams queue for a free offload worker before // proxyplus answers 503 instead of piling up behind a saturated (or fully stuck) pool; // main.cpp's real call sites pass AppConfig::h2DispatchQueueMax. // h1DispatchQueueMax is the H1 analogue, forwarded to HttpEvent's own h1DispatchQueueMax // ctor param; main.cpp's real call sites pass AppConfig::h1DispatchQueueMax. HttpProxyController(std::vector<netplus::socket *> serverSockets, std::string listenerLabel, bool tlsActive, Loading @@ -48,7 +50,8 @@ public: tls::AcmeChallengeStore *acmeChallenges = nullptr, int idleTimeoutSeconds = 0, int upstreamTimeoutSeconds = 60, int h2DispatchQueueMax = 256); int h2DispatchQueueMax = 256, int h1DispatchQueueMax = 256); void RequestEvent(libhttppp::HttpRequest &curreq, const int tid, ULONG_PTR args) override; Loading