[Bug 66602] New: TCP abnormal shutdown during pressure testing based on HTTP2 (h2c)
https://bz.apache.org/bugzilla/show_bug.cgi?id=66602
Bug ID: 66602
Summary: TCP abnormal shutdown during pressure testing based on
HTTP2 (h2c)
Product: Tomcat 9
Version: 9.0.75
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: 517893...@qq.com
Target Milestone: -
Created attachment 38559
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38559&action=edit
normal request log comparison
**Perform a simple GET request pressure test on the HTTP2 (h2c) service, and
the TCP link will shutdown abnormally.**
1.By simulating 50 concurrent requests with 500 each, perform pressure testing
and packet capture on a simple GET request.
2.The process found that the TCP link would be disconnected.
3.The reason is that tomcat sent a WINDOW_UPDATE Frame with window size value
is zero.
call Http2UpgradeHandler.endRequestBodyFrame method the dataLength is zero? Is
this reasonable？
Http2UpgradeHandler:
public void endRequestBodyFrame(int streamId, int dataLength) throws
Http2Exception, IOException {
AbstractNonZeroStream abstractNonZeroStream =
getAbstractNonZeroStream(streamId, true);
if (abstractNonZeroStream instanceof Stream) {
((Stream)
abstractNonZeroStream).getInputBuffer().onDataAvailable();
} else {
// The Stream was recycled between the call in Http2Parser to
// startRequestBodyFrame() and the synchronized block that contains
// the call to this method. This means the bytes read will have
been
// written to the original stream and, effectively, swallowed.
// Therefore, need to notify that those bytes were swallowed here.
onSwallowedDataFramePayload(streamId, dataLength);
}
}
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66602] TCP abnormal shutdown during pressure testing based on HTTP2 (h2c)
https://bz.apache.org/bugzilla/show_bug.cgi?id=66602 ledefe <517893...@qq.com> changed: What|Removed |Added OS||All Priority|P2 |P1 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66602] TCP abnormal shutdown during pressure testing based on HTTP2 (h2c)
https://bz.apache.org/bugzilla/show_bug.cgi?id=66602 --- Comment #1 from ledefe <517893...@qq.com> --- Comment on attachment 38559 --> https://bz.apache.org/bugzilla/attachment.cgi?id=38559 normal request log comparison The overall process is as follows: 1. http-nio-9988-exec-4 thread: Read data from the stream. After reading the header frame, asynchronously start the request distribution processing for data (http-nio-9988-exec-13) and continue reading the data frame data. 2. http-nio-9988-exec-13 thread: Process data requests. If the request is completed, the status changes to CLOSE and replaces the current stream with the recycling stream（RecycledStream） 3. http-nio-9988-exec-4 thread: Process data frame data. If it is processed, execute endRequestBodyFrame. is RecycledStream will send WINDOW_UPDATE notify. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
To service the SSL tomcat end users are now engaged mostly with HTTPD SERVER and IBM HTTPD If we look at the c,c++,etc API vendors they rarely change thier Products production at user level - @Mark remarks On Sat, May 13, 2023 at 1:48 AM Mark Thomas wrote: > On 12/05/2023 22:24, Rémy Maucherat wrote: > > On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas wrote: > >> We would normally make Java 21 the minimum Java version. Given that Java > >> 21 is still in EA, I don't plan to do that yet. > > > > Since the update to Java 21 has now been made and seems to make > > everyone happy, I would like to discuss Panama. > > > > - Panama as it is right now removes the need for tomcat-native 2.0. It > > is stable, fast enough, works out of the box, is much much better for > > cloud environments (no funny custom binary to add, only the usual > > Java), and so on. Actually, all of these statements were already true > > with Java 17, although the API was a bit rougher. Unfortunately at the > > moment, it is still preview in Java 21. > > - It is possible to include the support right now, but since the API > > would change in Java 22, then Tomcat 11 (or at least that feature) > > would only target Java 21. Compilation would have to occur on Java 21. > > - Support for Java 21 ends in 2028. This means then there would be a > > needed API update to Java LTS.next, dropping support for Java 21 (for > > that feature), and causing a more complex build (targeting Java 21 > > with a newer Panama API would cause the compiler to scream). > > - Multi release JARs are an option, but this is annoying as it would > > require multiple Java versions to build Tomcat (since it is a preview > > API), then assemble the multi release JAR. Not looking too good ... > > > > Given all this, there are two main options: > > A) (unfortunately) *not* including the Panama support until it is non > > preview. Once this happens, then my proposal would be to update the > > minimum build Java version (not runtime !) for Tomcat 11, add the > > Panama "final API" support, and use the release option to still target > > 21 (except for the Panama feature classes, of course, which would be > > compiled separately). Also as a consequence tomcat-native 2 would have > > to be supported for the entire lifecycle of Tomcat 11. > > B) Add full support using Java 21, drop tomcat-native. Once Java > > LTS.next is released towards the end of 2025 (with non preview Panama, > > hopefully), update to use the new API. Users of OpenSSL will have to > > move to Java LTS.next > > > > Although I would like B), A) seems more reasonable and in line with > > our support practices. > > > > Comments ? > > Is there any chance Panama will come out of preview in Java 21? > > OpenSSL supports versions for less time than the typical support period > for a major Tomcat version (10 years). And then you have the Linux > distributions that have specific OpenSSL versions and their support > periods. With Tomcat Native we have been able to manage this reasonably > well without too much maintenance burden for us. > > How would this work with different versions of OpenSSL? Is it possible > to support multiple OpenSSL versions? > > Of the two options you present, I agree that option A is more in-line > with how we typically do things (as much as I would like to say goodbye > to native code). > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
