>I highly suspect that the fix that Stuart Douglas did for https://issues.jboss.org/browse/UNDERTOW-1486 will solve this part of the problem. My minimal investigation into this issue had led me to suspect that the open listener was being triggered twice in this case.

Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts --------------------------------------------------------------------------------------------- Key: WFLY-11691 URL: https://issues.jboss.org/browse/WFLY-11691 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 14.0.1.Final, 15.0.1.Final Reporter: jaikiran pai Assignee: Stuart Douglas Priority: Major More than one users[1][2] have reported that they are seeing odd timeout issues with HTTP(S) calls in their applications. Based on the discussion in those threads, I believe there are 2 issues here, one in Undertow and one in WildFly. In Undertow, I believe there's a bug which when using HTTP 1.1, in some cases, ends up marking an in-progress request as timed out (based on the value set for no-request-timeout). Thread[1] has more details on how to reproduce such a case, but like I note in that thread, I don't think the cipher suites is what's causing this. I haven't found the time to create a simpler reproducible application for that one yet and I haven't yet created a Undertow JIRA for it. In WildFly, I think the default value of 60 seconds for no-request-timeout on the HTTP(s) listeners, is arbitrary and even too low. IMO, this probably should default to -1 (i.e. no specific timeout) and let the users decide what value makes sense in their setup. [1] https://developer.jboss.org/thread/279379 [2] https://developer.jboss.org/thread/279261