On Wed, 2020-11-18 at 21:20 +0000, jwhit...@redhat.com wrote: > Hi, > I am benchmarking HttpCore 5.1-Beta. When running under load HTTP > clear text tests I am seeing frequent protocol errors reported. Using > Wireshark to trace the interface. > > No. Time Cumulative Protocol Length Info UTC > 29 0.093415950 2572 TCP 66 37020 → 80 [ACK] > Seq=554 Ack=90 Win=65536 Len=0 TSval=3201662568 TSecr=3201662568 > 2020-11-18 18:09:26.134336499 > 30 0.094209181 2749 HTTP2 177 HEADERS[9]: GET > http://localhost/api/content/maven/remote/central/org/codehaus/mojo/build-helper-maven-plugin/3.0.0/build-helper-maven-plugin-3.0.0.pom > 2020-11-18 18:09:26.135129730 > 31 0.094291017 2828 HTTP2 79 RST_STREAM[9] 2020- > 11-18 18:09:26.135211566 > 32 0.094304480 2894 TCP 66 37020 → 80 [ACK] > Seq=665 Ack=103 Win=65536 Len=0 TSval=3201662569 TSecr=3201662569 > 2020-11-18 18:09:26.135225029 > > > Immediately after the client issues a GET method request the server > is > sending RST_STREAM. > > Frame 31: 79 bytes on wire (632 bits), 79 bytes captured (632 bits) > on > interface lo, id 0 > Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: > 00:00:00_00:00:00 (00:00:00:00:00:00) > Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1 > Transmission Control Protocol, Src Port: 80, Dst Port: 37020, Seq: > 90, > Ack: 665, Len: 13 > Source Port: 80 > Destination Port: 37020 > [Stream index: 0] > [TCP Segment Len: 13] > Sequence number: 90 (relative sequence number) > Sequence number (raw): 3817038059 > [Next sequence number: 103 (relative sequence number)] > Acknowledgment number: 665 (relative ack number) > Acknowledgment number (raw): 3962548455 > 1000 .... = Header Length: 32 bytes (8) > Flags: 0x018 (PSH, ACK) > Window size value: 512 > [Calculated window size: 65536] > [Window size scaling factor: 128] > Checksum: 0xfe35 [unverified] > [Checksum Status: Unverified] > Urgent pointer: 0 > Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), > Timestamps > [SEQ/ACK analysis] > [Timestamps] > TCP payload (13 bytes) > [PDU Size: 13] > HyperText Transfer Protocol 2 > Stream: RST_STREAM, Stream ID: 9, Length 4 > Length: 4 > Type: RST_STREAM (3) > Flags: 0x00 > 0... .... .... .... .... .... .... .... = Reserved: 0x0 > .000 0000 0000 0000 0000 0000 0000 1001 = Stream Identifier: > 9 > Error: PROTOCOL_ERROR (1) > > > The set-up I have is running Apache Httpd to serve content with h2c > protocol. The load driver pushing GET requests for files. A mixture > of > text or binary. > > I checked JIRA and found no reported issues. I know this as BETA > release I'm using. Is this api expected to work without issue ? > > Regards, > Jeremy > > The client driver is based on this example [1]. > > $ java -version > openjdk version "11.0.9" 2020-10-20 > OpenJDK Runtime Environment 18.9 (build 11.0.9+11) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.9+11, mixed mode, sharing) > $ uname -a > Linux burtha-f31 5.8.17-100.fc31.x86_64 #1 SMP Thu Oct 29 18:58:48 > UTC > 2020 x86_64 x86_64 x86_64 GNU/Linux > $ > > [1] > https://hc.apache.org/httpcomponents-core-5.1.x/httpcore5-h2/examples/H2RequestExecutionExample.java >
Hi Jeremy I am not aware of such issue. This is not expected. However to be able to tell me I need to see the complete message exchange leading to a stream reset by the server. Is there a chance you could put together a reproducer based on this docker image [1] or anything I could run locally? Oleg [1] https://github.com/apache/httpcomponents-core/tree/master/httpcore5-testing/docker/apache-httpd --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org