Jetty Client sending RST_STREAM towards the server after n seconds of idleness on a particular Stream ID even if idleTimeout is set to 0

[joyfulnikhil]

Jetty version(s) 11.0.7

Java version/vendor (use: java -version) Oracle JDK 17

OS type/version CentOS

Description We have a Microservice-A that uses Jetty Client to communicate with downstream Microservices. We are observing an intermittent issue of RST_STREAM being sent from MS-A to the downstream if there is no traffic exchanged on that specific stream ID after 4 seconds.

10.233.98.253 belongs MS-A 10.233.60.39 belongs to downstream MS

How to reproduce?

Below is our Jetty Configuration for Initialization

	SslContextFactory.Client sslContextFactory = new SslContextFactory.Client(true);
	HTTP2Client http2Client = new HTTP2Client();
	http2Client.setMaxConcurrentPushedStreams(1024);
	common.jettyclient.HttpClientTransportOverHTTP2 transport = new common.jettyclient.HttpClientTransportOverHTTP2(http2Client,pingDelay);
	transport.setUseALPN(false);
	ClientConnector connector = new ClientConnector();
	connector.setSslContextFactory(sslContextFactory);
	transport.updateBean(transport.getBean(ClientConnector.class), connector);
	common.jettyclient.HttpClient httpClient = new  common.jettyclient.HttpClient(
					transport){
		@Override
		protected void doStart() throws Exception
		{
			super.doStart();
		}
	};
	//Adding listener for jetty client metrics
	httpClient.getRequestListeners().add(new JettyRequestMetrics("h2",metrics));
	httpClient.setDnsResolver(dnsResolver);
	httpClient.setConnectTimeout(10000);
	httpClient.setMaxRequestsQueuedPerDestination(1024);
	httpClient.setMaxConnectionsPerDestination(4);
	httpClient.setMaxConnectionsPerIp(4);
	httpClient.setUserAgentField(null);
	httpClient.setRequestTimeout(3000);
	httpClient.setIdleTimeout(0);
	httpClient.setClient_type("h2c");

[sbordet]

common.jettyclient.HttpClient is not a Jetty class, so we cannot say what's doing.

From httpClient.setRequestTimeout(3000); I may imagine that if the request is not replied within 3 seconds it gets aborted, and that would explain the RST_STREAM.

Other than this guess, there is not enough information.

Can you provide the client DEBUG logs?

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sbordet]

No further information, closing.