wenzhenghu commented on PR #63332: URL: https://github.com/apache/doris/pull/63332#issuecomment-4552707245
> This is a great find — thanks for digging into the Jetty 12 regression. A couple of questions on the approach: > > 1. Are the Jetty-level maxUnconsumedRequestContentReads = -1 and the application-level bounded drain redundant? > 2. Misbehaving clients sending the body early is fundamentally a client-side problem — they aren't implementing Expect: 100-continue correctly, and the right fix is to push the clients to comply. Having FE actively consume the request body by default essentially makes FE take on body traffic it was never supposed > to handle; under high-concurrency Stream Load, this will noticeably increase FE's network and thread pressure. 1. There is no conflict between the two settings. Setting `maxUnconsumedRequestContentReads` to -1 allows Jetty 12 to process as much data as possible at its layer, while the draining logic on the FE side acts as a fallback. 2. You are right that this is essentially non-compliant behavior on the client side. This PR only provides a compatibility solution to prevent service failures and data write failures in businesses upgraded from Doris 2.1 and 3.0 due to this incompatibility. **This issue also affects businesses using the Doris Logstash plugin, an ecosystem tool developed officially by Doris itself.** The problem has already raised doubts about the compatibility of Doris 3.1. I also share your concern about the increased load on FE caused by consuming request bodies. I compared the behaviors of version 3.0 and 3.1, and found that request body consumption also exists in 3.0 — it was handled by Jetty 9 back then. In cases of overly large request bodies or high network latency, FE would still take tens of seconds to respond to clients. Requiring clients to make corrections is the proper long-term solution. However, since the existing services are already online, client adjustments cannot be completed immediately after the upgrade. The parameters introduced in this PR are designed to grant businesses a transition period for relevant modifications. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
