Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-17307

Default no-request-timeout value on HTTP(s) listeners seems to be causing unexpected timeouts

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • 16.0.0.Final
    • 14.0.1.Final, 15.0.1.Final
    • Web (Undertow)
    • None

      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

       

       

       

       

      Note :

      We are facing the similar issue of request timed-out within a minute. Our http/2 is disabled. can anyone help us on this. We are using jBoss EAP 7.3.10.GA Release version 10.1.25.Final-redhat-0001

              Unassigned Unassigned
              narenderg588 Narender G (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: