You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2015/11/25 23:14:11 UTC

[jira] [Commented] (TS-4041) Refine squid codes to distinguish connection shutdown causes

    [ https://issues.apache.org/jira/browse/TS-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15027698#comment-15027698 ] 

Leif Hedstrom commented on TS-4041:
-----------------------------------

I'm for improvements here, but this has to be done carefully. The error codes here were intentionally done (obviously) to mirror Squid. Now, there has been changes in Squid since we did this, so maybe it's a matter of syncing up our error codes etc. with current Squid versions? Also see e.g. TS-1174.

> 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
>             Fix For: 6.1.0
>
>
> 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)