Uploaded image for project: 'Traffic Server'
  1. Traffic Server
  2. TS-4796

ATS not closing origin connections on first RST from client

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 7.1.0
    • Component/s: HTTP
    • Labels:
      None
    • Backport to Version:

      Description

      TLDR; similar to TS-4720 – slower to close than it should, instead of never closing

      As a continuation of TS-4720, while testing that the session is closed when we expect-- I found that it isn't.

      Although we are now closing the sessions, we aren't doing it as quickly as we should. In this client abort case we expect the client to abort, and ATS should initially continue to send bytes to the client-- as we are in the half-open state. After the first set of bytes are sent to the client-- the client will send an RST-- which should signal ATS to stop sending the request (and tear down the origin connection etc.).

      I'm able to reproduce this locally, and the debug output (with some additional comments) looks like below:

      < FIN FROM CLIENT >
      [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG: <HttpSM.cc:2649 (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
      [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG: <HttpSM.cc:892 (state_watch_for_client_abort)> (http) [0] [&HttpSM::state_watch_for_client_abort, VC_EVENT_EOS]
      
      
      
      < RST FROM CLIENT >
      Got an HttpTunnel event 100 
      [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1173 (producer_handler)> (http_tunnel) [0] producer_handler [http server VC_EVENT_READ_READY]
      [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1108 (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http server VC_EVENT_READ_READY]
      [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:203 (read_size)> (http_chunk) read chunk size of 15 bytes
      [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:279 (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
      [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1213 (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] enable_redirection: [1 0 0] event: 100
      Got an HttpTunnel event 101 
      [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1373 (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent VC_EVENT_WRITE_READY]
      write ready consumer_handler
      
      

      In this situation the connection doesn't close here at the RST-- but rather on the next set of bytes from the origin to send-- which end up tripping a VC_EVENT_ERROR-- and tearing down the connection.

      When the client sends the first RST epoll returns a WRITE_READY event – which the HTTPTunnel consumer ignores completely. It seems then that when we recieve the WRITE_READY event we need to determine if we are already in the writing state-- and if so, then we should stop the transaction (since we are already edge-triggered).

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jacksontj Thomas Jackson
                Reporter:
                jacksontj Thomas Jackson
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 10h 20m
                  10h 20m