[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673347#comment-13673347 ] ASF subversion and git services commented on TS-1492: - Commit c0565072e37db84d033ee00c250b397456a87828 in branch refs/heads/master from Leif Hedstrom zw...@apache.org [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c056507 ] TS-1492 Prevent net-throttling from locking out the health checks from traffic_cop. if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request) -- Key: TS-1492 URL: https://issues.apache.org/jira/browse/TS-1492 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Leif Hedstrom Priority: Critical Labels: A Fix For: 3.3.3 Attachments: backdoor_not_throttling.patch In our env, ts will be throttled because of many request incomming simultaneously(because of frontend haproxy is restarted). But we don't expect ts be restarted because of this case. we can handled this: 1、if throttled, ts's health check request always be handled 2、many many connection request may be handled in long time -- 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
[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[
https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669876#comment-13669876
]
Leif Hedstrom commented on TS-1492:
---
James, so, looking at the code, I do agree that backdoor is somewhat
unfortunate, something like from_cop would be better. However, the notion of
backdoor is all over the code, and is bridged across API boundaries via
{code}
na-backdoor = opt.backdoor;
{code}
My vote would be that we keep the name backdoor for now, and file a separate
bug to rename this to something else. The name allow_throttle has some
weirdness to it, it's somewhat the inverse of what backdoor means, but if you
feel strongly about that, I don't really care that much. The bridge would
then be e.g.
{code}
na-allow_throttle = !opt.backdoor;
{code}
and we change the code in this patch to invert the logic as well.
if being net_connections_throttled, ts must to be restarted?(because of
can't accept health checking request)
--
Key: TS-1492
URL: https://issues.apache.org/jira/browse/TS-1492
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Leif Hedstrom
Priority: Critical
Labels: A
Fix For: 3.3.3
Attachments: backdoor_not_throttling.patch
In our env, ts will be throttled because of many request incomming
simultaneously(because of frontend haproxy is restarted). But we don't expect
ts be restarted because of this case. we can handled this:
1、if throttled, ts's health check request always be handled
2、many many connection request may be handled in long time
--
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
[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606426#comment-13606426 ] Leif Hedstrom commented on TS-1492: --- What's the word on this? Should we commit the fix and create a new bug for feature additions / changes ? James? if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request) -- Key: TS-1492 URL: https://issues.apache.org/jira/browse/TS-1492 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Priority: Critical Fix For: 3.3.3 Attachments: backdoor_not_throttling.patch In our env, ts will be throttled because of many request incomming simultaneously(because of frontend haproxy is restarted). But we don't expect ts be restarted because of this case. we can handled this: 1、if throttled, ts's health check request always be handled 2、many many connection request may be handled in long time -- 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
[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606428#comment-13606428 ] Leif Hedstrom commented on TS-1492: --- Fwiw, the patch looks reasonable to me. if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request) -- Key: TS-1492 URL: https://issues.apache.org/jira/browse/TS-1492 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Priority: Critical Fix For: 3.3.2 Attachments: backdoor_not_throttling.patch In our env, ts will be throttled because of many request incomming simultaneously(because of frontend haproxy is restarted). But we don't expect ts be restarted because of this case. we can handled this: 1、if throttled, ts's health check request always be handled 2、many many connection request may be handled in long time -- 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
[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606485#comment-13606485 ] James Peach commented on TS-1492: - I'm ok with the implementation, but I think the flag should be called allow_throttle rather than backdoor. I prefer that the iocore layers expose general mechanisms rather than specific policy. Bin Chen, can you please make that change, then I will commit this patch. if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request) -- Key: TS-1492 URL: https://issues.apache.org/jira/browse/TS-1492 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Priority: Critical Fix For: 3.3.2 Attachments: backdoor_not_throttling.patch In our env, ts will be throttled because of many request incomming simultaneously(because of frontend haproxy is restarted). But we don't expect ts be restarted because of this case. we can handled this: 1、if throttled, ts's health check request always be handled 2、many many connection request may be handled in long time -- 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
[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13495454#comment-13495454 ] James Peach commented on TS-1492: - thinking about the feature to not start accepting connections until e.g. the cache is initialized, ... Please discuss with amc and myself before implementing ... we talked about a design where we alter the startup sequence and create ATS lifecycle events that plugins can hook ... if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request) -- Key: TS-1492 URL: https://issues.apache.org/jira/browse/TS-1492 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Priority: Critical Fix For: 3.3.1 Attachments: backdoor_not_throttling.patch In our env, ts will be throttled because of many request incomming simultaneously(because of frontend haproxy is restarted). But we don't expect ts be restarted because of this case. we can handled this: 1、if throttled, ts's health check request always be handled 2、many many connection request may be handled in long time -- 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
[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494593#comment-13494593 ] Bin Chen commented on TS-1492: -- if we should restart traffic_server, set stat records=1. And if ts restored, then we must set stat records=0. But maybe have more case(throttling, cache error), one is setting, and other is restoring, how to set stat records? so maybe we can't use only one stat records. if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request) -- Key: TS-1492 URL: https://issues.apache.org/jira/browse/TS-1492 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Priority: Critical Fix For: 3.3.1 Attachments: backdoor_not_throttling.patch In our env, ts will be throttled because of many request incomming simultaneously(because of frontend haproxy is restarted). But we don't expect ts be restarted because of this case. we can handled this: 1、if throttled, ts's health check request always be handled 2、many many connection request may be handled in long time -- 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
[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494596#comment-13494596 ] Bin Chen commented on TS-1492: -- the other solution, we can use one stat records to flagging one case(throttling, cache not enable), and traffic manager collect to handler(check every case) traffic_server restart. if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request) -- Key: TS-1492 URL: https://issues.apache.org/jira/browse/TS-1492 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Priority: Critical Fix For: 3.3.1 Attachments: backdoor_not_throttling.patch In our env, ts will be throttled because of many request incomming simultaneously(because of frontend haproxy is restarted). But we don't expect ts be restarted because of this case. we can handled this: 1、if throttled, ts's health check request always be handled 2、many many connection request may be handled in long time -- 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
[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465755#comment-13465755 ] Leif Hedstrom commented on TS-1492: --- 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 being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request) -- Key: TS-1492 URL: https://issues.apache.org/jira/browse/TS-1492 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: kuotai Assignee: kuotai Priority: Critical Fix For: 3.3.0 Attachments: backdoor_not_throttling.patch In our env, ts will be throttled because of many request incomming simultaneously(because of frontend haproxy is restarted). But we don't expect ts be restarted because of this case. we can handled this: 1、if throttled, ts's health check request always be handled 2、many many connection request may be handled in long time -- 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
