[jboss-jira] [JBoss JIRA] (WFLY-11691) Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts

[jaikiran pai (Jira)]

    [ https://issues.jboss.org/browse/WFLY-11691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696450#comment-13696450 ] 

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)