[jira] [Work logged] (TS-4796) ATS not closing origin connections on first RST from client

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TS-4796?focusedWorklogId=27677&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-27677 ]

ASF GitHub Bot logged work on TS-4796:
--------------------------------------

                Author: ASF GitHub Bot
            Created on: 01/Sep/16 01:55
            Start Date: 01/Sep/16 01:55
    Worklog Time Spent: 10m 
      Work Description: Github user atsci commented on the issue:

    https://github.com/apache/trafficserver/pull/947
  
    FreeBSD build *failed*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/659/ for details.
     



Issue Time Tracking
-------------------

    Worklog Id:     (was: 27677)
    Time Spent: 1h 40m  (was: 1.5h)

> ATS not closing origin connections on first RST from client
> -----------------------------------------------------------
>
>                 Key: TS-4796
>                 URL: https://issues.apache.org/jira/browse/TS-4796
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: HTTP
>            Reporter: Thomas Jackson
>            Assignee: Thomas Jackson
>          Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> *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:
> {code}
> < 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
> {code}
> 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).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)