Thomas Jackson created TS-4796:
----------------------------------
Summary: 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
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)
