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

[QE](7.4.z) Server responds with chunked transfer even for short data from deployment

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Blocker Blocker
    • 7.4.12.CR3, 7.4.12.GA
    • 7.4.12.CR2
    • Undertow
    • None
    • False
    • None
    • False
    • +
    • Hide

      These steps mimics what our test does:

      1. unzip the server and start ./bin/standalone
      2. start the cli client ./bin/jboss-cli.sh -c
      3. setup the server and deploy deployment 
        /subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()
/subsystem=undertow/configuration=filter/gzip=gzip-filter:add()
/subsystem=undertow/server=default-server/host=default-host/filter-ref=gzip-filter:add()

deploy simple-web.war
      1. start e.g. Wireshark to see the data traffic and perform curl request against the server: 
        curl -H "Accept-Encoding: gzip" http://localhost:8080/simple-web/dummy-text.html --compressed
      Show
      These steps mimics what our test does: unzip the server and start ./bin/standalone start the cli client ./bin/jboss-cli.sh -c setup the server and deploy deployment /subsystem=undertow/server= default -server/host= default -host/setting=access-log:add() /subsystem=undertow/configuration=filter/gzip=gzip-filter:add() /subsystem=undertow/server= default -server/host= default -host/filter-ref=gzip-filter:add() deploy simple-web.war start e.g. Wireshark to see the data traffic and perform curl request against the server: curl -H "Accept-Encoding: gzip" http: //localhost:8080/simple-web/dummy-text.html --compressed

      To be honest - I'm not sure how much this is a bug or not. What I see is a change in server behavior after this commit in the Undertow component. It was introduced as a fix for UNDERTOW-2243.

      What changed. Before this commit, our testing scenario for gzip filter received data with the regular "fixed-length" response from the server (Content-Length) header used (see gzip-content-length.png and gzip-content-length.pcapng). After this commit, server decide to use chunked transfer for the data without using the Content-Length header (see gzip-chunked.png and gzip-chunked.pcapng). Technically this may not be any problem, but this change means more ping-pongs between server and client. So I'm a bit worried that this may affect Undertow performance.

      Is this change of behavior expected?

        1. gzip-chunked.pcapng
          2 kB
        2. gzip-chunked.png
          gzip-chunked.png
          226 kB
        3. gzip-content-length.pcapng
          3 kB
        4. gzip-content-length.png
          gzip-content-length.png
          273 kB
        5. simple-web.war
          3 kB

            flaviarnn Flavia Rainone
            padamec@redhat.com Petr Adamec
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: