[
https://issues.apache.org/jira/browse/TS-4796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Jackson updated TS-4796:
-------------------------------
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:
{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).
was:
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).
> 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
>
> *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)
