[ https://issues.jboss.org/browse/WFLY-12188?page=com.atlassian.jira.plugin... ] Flavia Rainone commented on WFLY-12188: --------------------------------------- [~brian.stansberry] After some investigation, I figured that the only way that read timeout is being properly set is at Undertow subsystem via: {code} <subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other" statistics-enabled="${wildfly.undertow.statistics-enabled:${wildfly.statistics-enabled:false}}"> <buffer-cache name="default"/> <server name="default-server"> <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true" read-timeout="120"/> <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true" read-timeout="5000"/> {code} So, for users using {code} <connection uri="remote+http://127.0.0.1:8080" /> {code} or {code} <connection uri="remote://127.0.0.1:8080" /> {code} It is the timeout at http-listener that counts. If using 8443 port, it is the one in https-listener. If the option is passed via: {code} <subsystem xmlns="urn:jboss:domain:remoting:4.0"> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"> <properties> <property name="org.xnio.Options.READ_TIMEOUT" value="100"/> </properties> </http-connector> </subsystem> {code} It is completely ignored, even if the read-timeout config in Undertow http-listener is ommitted, i.e., it is not overwritten, it is plainly ignored. What do you think we should do about this? Just document it, or remove the XNIO Options support from http-connector? Add a warning? -- This message was sent by Atlassian Jira (v7.13.5#713005)