[
https://issues.apache.org/jira/browse/TS-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465752#comment-13465752
]
Leif Hedstrom commented on TS-1502:
-----------------------------------
So, I'm thinking about the feature to not start accepting connections until
e.g. the cache is initialized, and it would have this problem as well. I'm
thinking what we should do is to have a stats Record, which is either 0 or 1. 1
Means that the system is expected to accept() connections properly, and 0 means
that it is not (e.g. not initialized, or we are throttling).
traffic_cop can read this Records stat before issuing a health check. If it's
0, then we will not test and restart traffic_server. Maybe with some
(configurable) threshold, such as that if this setting is at 0 for longer than
120seconds, then forcefully restart traffic_server.
I think this would solve both of these problems, and becomes a generally useful
stats that something can check to make sure traffic_server is in a state of
accepting connections.
> if ts is throttling becasue of request jitter (more connection incoming
> suddenly), we shoudn't restart ts because of not accepting cop's check request
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TS-1502
> URL: https://issues.apache.org/jira/browse/TS-1502
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network
> Affects Versions: 3.2.0
> Environment: in our env, ts is running at about 40Gbps(10 ts). So we
> should ensure ts will be running smoothly. So we should pretend ts restaring
> in some case.
> Reporter: kuotai
> Assignee: kuotai
> Priority: Critical
> Fix For: 3.3.0
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
