[ https://issues.apache.org/jira/browse/TS-4796?focusedWorklogId=27695&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-27695 ]
ASF GitHub Bot logged work on TS-4796: -------------------------------------- Author: ASF GitHub Bot Created on: 01/Sep/16 05:23 Start Date: 01/Sep/16 05:23 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/661/ for details. Issue Time Tracking ------------------- Worklog Id: (was: 27695) Time Spent: 2h (was: 1h 50m) > 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: 2h > 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)