Susan Hinrichs created TS-4041:
----------------------------------
Summary: Refine squid codes to distinguish connection shutdown
causes
Key: TS-4041
URL: https://issues.apache.org/jira/browse/TS-4041
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Susan Hinrichs
SQUID_LOG_ERR_CLIENT_ABORT is used in multiple scenarios. The ambiguity
between these scenarios has caused us to take some false turns in debugging
failures. Based on code inspection, CLIENT_ABORT will show up in the following
cases.
* The client sends an EOS unexpectedy. CLIENT_ABORT seems completely
appropriate.
* The client VC times out (either inactive or active timeout). CLIENT_ABORT
doesn't seem right here. Perhaps SQUID_LOG_ERR_READ_TIMEOUT would be better.
That seems to be currently used for server side timeouts. Might be nice to have
a differentiation on which side timed out.
* The client VC has a read failure. This would include the SSL_read failure
case. Could use SQUID_LOG_ERR_READ_ERROR. Currently only used if the server
side sends EOS before end of expected data. Again differentiating server side
and client side error would be beneficial.
How fixed are the squid error codes? Could we add more codes? If so, we could
distinguish between the client-side failures and server-side failures by adding
the following codes.
* Use CLIENT_ABORT only for for client sending EOS too early.
* Use CLIENT_READ_TIMEOUT for inactive/active timeouts on client side.
* Use CLIENT_READ_ERROR for read failures on client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
