[
https://issues.apache.org/jira/browse/TS-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-3777:
-------------------------------
Attachment: ts-3777.diff
I dug through the bugzilla description and the code diffs. It looks like there
were a fair number of changes to fix the problem of untidy shutdown on error.
This particular change affects the tunnel from the server back to the client.
After much playing around with my proxy test client, I think I see the issue
they were draining for.
UA sends proxy request. This gets send onto origin server. UA sets to tunnel
to sending proxy data to origin server, but origin server returns immediately
with a redirect or error. A tunnel is set up to send the response to the UA.
The response has been sent (WRITE_COMPLETE), but the post data is still being
read by the ua_session. If we shutdown the client_vc at this point, the
network stack would send a RESET since there was still was data on the socket.
The half close state would work in general if the client_vc is a network vc.
HttpClientSession::do_io_close will send a FIN to the client. That will
generally cause the UA to send a FIN after writing its data. Then the EOS
logic in the HttpClientSession::state_wait_for_close will complete the
do_io_close when it receives the FIN from the UA.
But in the PluginVC case, there is no real network involved to return the FIN.
So the HttpClientSession lingers until inactivity timeout goes off. In
Daniel's case he is waiting for EOS to determine that his chunked response is
done. Similarly, TS-3640 is working over a PluginVC instead of a real network
VC.
I'm attaching ts-3777.diff with a different fix to the problem. It splits the
HttpClientSession read_state HCS_ACTIVE_READER into HCS_ACTIVE_READER and
HCS_DONE_READER. The HCS_DONE_READER state gets set once the post data tunnel
has completed the client side read. Then the HttpClientSession::do_io_close is
changed to only follow the half_close flag if the state is HCS_ACTIVE_READER.
That should preserve the original fix. And that addresses the case of a
successful post shutting down directly. Daniel's plugin is happy.
I'll do some more testing with this tomorrow on my box and then in production
on YCPI to look for memory leaks.
> TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor
> TS_VCONN_EOS
> ------------------------------------------------------------------------------------
>
> Key: TS-3777
> URL: https://issues.apache.org/jira/browse/TS-3777
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
> Reporter: Daniel Vitor Morilha
> Assignee: Susan Hinrichs
> Labels: yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3777.diff
>
>
> When using TSHttpConnect to connect to ATS itself (internal vconnection),
> sending a POST request and receiving a CHUNKED response. ATS does not fire
> neither TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS.
> Trying to close the vconnection from the plug-in after receiving the last
> chunk ("\r\n0\r\n") results into the PluginVC repeating the following message:
> {noformat}
> [Jul 14 21:24:06.094] Server {0x7ffff7fbe800} DEBUG: (pvc_event) [0] Passive:
> Received event 1
> {noformat}
> I am glad to provide an example if that helps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
