[
https://issues.jboss.org/browse/WFLY-11691?page=com.atlassian.jira.plugin...
]
jaikiran pai commented on WFLY-11691:
-------------------------------------
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.
I highly suspect that the fix that [~swd847] 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. Stuart notes the same thing in that other JIRA:
This was caused by a bug in the ALPN open listener that could be
triggered if the server was configured with HTTP/2 enabled but did not have the correct
SSL config for HTTP/2.
This fits the issue being seen the linked forum thread where the user had HTTP2 enabled
but didn't have the correct SSL config (cipher suites that weren't valid).
With this underlying issue fixed, I think the only part that needs a decision is whether
the WildFly Undertow subsystem should default to something other than 60 seconds for the
no-request-timeout. I don't know if that question will even be relevant now that the
underlying issue with active requests being considered inactive is (I think) now solved.
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
--
This message was sent by Atlassian Jira
(v7.12.1#712002)