Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-20407

[GSS](7.3.z) UNDERTOW-1806 - HTTP/2 close behaviour is problematic on unclean close

XMLWordPrintable

    • False
    • False
    • +
    • Undefined
    • Hide

      1. Set up and run load balancer instance to accept HTTP/2 (standalone-load-balancer.xml)
      2. Set up app instance with included servlet-async.war deployed
      3. Access app through balancer (https://localhost:8543/servlet-async/). The servlet-async example is adjusted for a longer 60 second async request.
      4. ctrl+R to refresh and abort the longer async request in progress over HTTP/2.
      5. Note a long browser wait for a response seen by the /servet-async/ request for the index.html (typically seen within the first few refreshes for me). The access logging can show the unexpected delay induced in the /servlet-async/ index.html request. For instance, this /servlet-async/AsynchronousServlet request was started at 10:28:32 and a refresh occurred ~2.6 seconds later. The following /servlet-async/ request did not compelete until 10:29:32, when the prior /servlet-async/AsynchronousServlet request completed on the backend:

      127.0.0.1 - - [26/Oct/2020:10:28:34 -0400] "GET /servlet-async/AsynchronousServlet HTTP/2.0" 200 - "https://localhost:8543/servlet-async/" "Mozilla/5.0 (X11; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0" - "-" "-" - "default I/O-16" 2.627
127.0.0.1 - - [26/Oct/2020:10:29:32 -0400] "GET /servlet-async/ HTTP/2.0" 200 2244 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0" - "-" "-" - "default I/O-16" 57.380
      Show
      1. Set up and run load balancer instance to accept HTTP/2 (standalone-load-balancer.xml) 2. Set up app instance with included servlet-async.war deployed 3. Access app through balancer ( https://localhost:8543/servlet-async/ ). The servlet-async example is adjusted for a longer 60 second async request. 4. ctrl+R to refresh and abort the longer async request in progress over HTTP/2. 5. Note a long browser wait for a response seen by the /servet-async/ request for the index.html (typically seen within the first few refreshes for me). The access logging can show the unexpected delay induced in the /servlet-async/ index.html request. For instance, this /servlet-async/AsynchronousServlet request was started at 10:28:32 and a refresh occurred ~2.6 seconds later. The following /servlet-async/ request did not compelete until 10:29:32, when the prior /servlet-async/AsynchronousServlet request completed on the backend: 127.0.0.1 - - [26/Oct/2020:10:28:34 -0400] "GET /servlet-async/AsynchronousServlet HTTP/2.0" 200 - "https: //localhost:8543/servlet-async/" "Mozilla/5.0 (X11; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0" - "-" "-" - " default I/O-16" 2.627 127.0.0.1 - - [26/Oct/2020:10:29:32 -0400] "GET /servlet-async/ HTTP/2.0" 200 2244 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0" - "-" "-" - " default I/O-16" 57.380

      If a HTTP/2 connection is closed by the remote client (or RST_STREAM is sent), then the completion listener is currently directly invoked by the IO thread.

      This is problematic as the request might be 'owned' by a different thread, which means that the exchange state can change while the other thread is working on it.

      This is particularly problematic for the reverse proxy, as if the exchange is ended the connection is returned to the pool, even though it is still processing. Another request can then get allocating this connection, and the request will need to wait until the first backend request has finished.

        1. JBEAP-20407reproducer.zip
          15 kB

            spyrkob Bartosz Spyrko-Smietanko
            rhn-support-aogburn Aaron Ogburn
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: