[jira] [Commented] (TS-3816) Should we replace ptr_len_cmp() with memcmp() consistently?
[ https://issues.apache.org/jira/browse/TS-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366924#comment-15366924 ] ASF subversion and git services commented on TS-3816: - Commit d36cb4791a4e42736e4db97100eb8449ad118231 in trafficserver's branch refs/heads/master from [~tstroh] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d36cb47 ] TS-3816 : Replace ptr_len_cmp with memcmp (#783) > Should we replace ptr_len_cmp() with memcmp() consistently? > --- > > Key: TS-3816 > URL: https://issues.apache.org/jira/browse/TS-3816 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom >Assignee: Tyler Stroh > Labels: newbie++ > Fix For: 7.0 > > > In most places, we already use memcmp(), but we have our own implementation / > wrapper named ptr_len_cmp(), which is used in a few places. This seems rather > inconsistent, so either we use ptr_len_cmp() consistently, or just use > memcmp() across the board. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3816) Should we replace ptr_len_cmp() with memcmp() consistently?
[ https://issues.apache.org/jira/browse/TS-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366923#comment-15366923 ] ASF GitHub Bot commented on TS-3816: Github user jpeach closed the pull request at: https://github.com/apache/trafficserver/pull/783 > Should we replace ptr_len_cmp() with memcmp() consistently? > --- > > Key: TS-3816 > URL: https://issues.apache.org/jira/browse/TS-3816 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom >Assignee: Tyler Stroh > Labels: newbie++ > Fix For: 7.0 > > > In most places, we already use memcmp(), but we have our own implementation / > wrapper named ptr_len_cmp(), which is used in a few places. This seems rather > inconsistent, so either we use ptr_len_cmp() consistently, or just use > memcmp() across the board. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3816) Should we replace ptr_len_cmp() with memcmp() consistently?
[ https://issues.apache.org/jira/browse/TS-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-3816. - Resolution: Fixed Fix Version/s: (was: sometime) 7.0 > Should we replace ptr_len_cmp() with memcmp() consistently? > --- > > Key: TS-3816 > URL: https://issues.apache.org/jira/browse/TS-3816 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom >Assignee: Tyler Stroh > Labels: newbie++ > Fix For: 7.0 > > > In most places, we already use memcmp(), but we have our own implementation / > wrapper named ptr_len_cmp(), which is used in a few places. This seems rather > inconsistent, so either we use ptr_len_cmp() consistently, or just use > memcmp() across the board. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3816) Should we replace ptr_len_cmp() with memcmp() consistently?
[ https://issues.apache.org/jira/browse/TS-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366920#comment-15366920 ] ASF GitHub Bot commented on TS-3816: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/783 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/308/ for details. > Should we replace ptr_len_cmp() with memcmp() consistently? > --- > > Key: TS-3816 > URL: https://issues.apache.org/jira/browse/TS-3816 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom >Assignee: Tyler Stroh > Labels: newbie++ > Fix For: sometime > > > In most places, we already use memcmp(), but we have our own implementation / > wrapper named ptr_len_cmp(), which is used in a few places. This seems rather > inconsistent, so either we use ptr_len_cmp() consistently, or just use > memcmp() across the board. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3816) Should we replace ptr_len_cmp() with memcmp() consistently?
[ https://issues.apache.org/jira/browse/TS-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366915#comment-15366915 ] ASF GitHub Bot commented on TS-3816: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/783 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/414/ for details. > Should we replace ptr_len_cmp() with memcmp() consistently? > --- > > Key: TS-3816 > URL: https://issues.apache.org/jira/browse/TS-3816 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom >Assignee: Tyler Stroh > Labels: newbie++ > Fix For: sometime > > > In most places, we already use memcmp(), but we have our own implementation / > wrapper named ptr_len_cmp(), which is used in a few places. This seems rather > inconsistent, so either we use ptr_len_cmp() consistently, or just use > memcmp() across the board. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3816) Should we replace ptr_len_cmp() with memcmp() consistently?
[ https://issues.apache.org/jira/browse/TS-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366903#comment-15366903 ] ASF GitHub Bot commented on TS-3816: Github user jpeach commented on the issue: https://github.com/apache/trafficserver/pull/783 [approve ci] > Should we replace ptr_len_cmp() with memcmp() consistently? > --- > > Key: TS-3816 > URL: https://issues.apache.org/jira/browse/TS-3816 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom >Assignee: Tyler Stroh > Labels: newbie++ > Fix For: sometime > > > In most places, we already use memcmp(), but we have our own implementation / > wrapper named ptr_len_cmp(), which is used in a few places. This seems rather > inconsistent, so either we use ptr_len_cmp() consistently, or just use > memcmp() across the board. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4472) Number of active connections is incorrect
[
https://issues.apache.org/jira/browse/TS-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366866#comment-15366866
]
Leif Hedstrom commented on TS-4472:
---
I think I have a patch / fix for this, sent to Masaori and Susan for review. I
believe the issue is around the duality of m_active in both Http1ClientSession
and Http1ClientTransaction.
> Number of active connections is incorrect
> -
>
> Key: TS-4472
> URL: https://issues.apache.org/jira/browse/TS-4472
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Masaori Koshiba
> Fix For: 6.2.0, 7.0.0
>
>
> Looks like the number of active connections is not decrementing and is always
> increasing.
> active connections keeps increasing in traffic_top:
> {code}
> Active Con 60.4K
> {code}
> [bcall@l28 trafficserver]$ ss -s
> {code}
> Total: 7036 (kernel 7258)
> TCP: 11404 (estab 6776, closed 4247, orphaned 349, synrecv 0, timewait
> 4247/0), ports 2580
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3816) Should we replace ptr_len_cmp() with memcmp() consistently?
[ https://issues.apache.org/jira/browse/TS-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366772#comment-15366772 ] ASF GitHub Bot commented on TS-3816: Github user jpeach commented on the issue: https://github.com/apache/trafficserver/pull/783 👍 > Should we replace ptr_len_cmp() with memcmp() consistently? > --- > > Key: TS-3816 > URL: https://issues.apache.org/jira/browse/TS-3816 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom >Assignee: Tyler Stroh > Labels: newbie++ > Fix For: sometime > > > In most places, we already use memcmp(), but we have our own implementation / > wrapper named ptr_len_cmp(), which is used in a few places. This seems rather > inconsistent, so either we use ptr_len_cmp() consistently, or just use > memcmp() across the board. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4100) remove XML statistics
[
https://issues.apache.org/jira/browse/TS-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366760#comment-15366760
]
ASF GitHub Bot commented on TS-4100:
Github user zwoop commented on the issue:
https://github.com/apache/trafficserver/pull/789
:+1:
> remove XML statistics
> -
>
> Key: TS-4100
> URL: https://issues.apache.org/jira/browse/TS-4100
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup, Configuration
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> Once TS-4099 lands, remove the XML statistics and corresponding code in the
> {{StatsProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4100) remove XML statistics
[
https://issues.apache.org/jira/browse/TS-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366763#comment-15366763
]
ASF GitHub Bot commented on TS-4100:
Github user jpeach closed the pull request at:
https://github.com/apache/trafficserver/pull/789
> remove XML statistics
> -
>
> Key: TS-4100
> URL: https://issues.apache.org/jira/browse/TS-4100
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup, Configuration
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> Once TS-4099 lands, remove the XML statistics and corresponding code in the
> {{StatsProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4100) remove XML statistics
[
https://issues.apache.org/jira/browse/TS-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366753#comment-15366753
]
ASF GitHub Bot commented on TS-4100:
Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/789
Linux build *successful*! See
https://ci.trafficserver.apache.org/job/Github-Linux/307/ for details.
> remove XML statistics
> -
>
> Key: TS-4100
> URL: https://issues.apache.org/jira/browse/TS-4100
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup, Configuration
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> Once TS-4099 lands, remove the XML statistics and corresponding code in the
> {{StatsProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4100) remove XML statistics
[
https://issues.apache.org/jira/browse/TS-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366748#comment-15366748
]
ASF GitHub Bot commented on TS-4100:
Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/789
FreeBSD build *successful*! See
https://ci.trafficserver.apache.org/job/Github-FreeBSD/413/ for details.
> remove XML statistics
> -
>
> Key: TS-4100
> URL: https://issues.apache.org/jira/browse/TS-4100
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup, Configuration
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> Once TS-4099 lands, remove the XML statistics and corresponding code in the
> {{StatsProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4100) remove XML statistics
[
https://issues.apache.org/jira/browse/TS-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366735#comment-15366735
]
ASF GitHub Bot commented on TS-4100:
GitHub user jpeach opened a pull request:
https://github.com/apache/trafficserver/pull/789
TS-4100: Remove remaining stats processor code.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jpeach/trafficserver fix/4100-2
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/789.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #789
commit c0336aad2ceda8fca4b70b6183832a8b7522f0bd
Author: James Peach
Date: 2016-07-07T19:06:18Z
TS-4100: Remove remaining stats processor code.
> remove XML statistics
> -
>
> Key: TS-4100
> URL: https://issues.apache.org/jira/browse/TS-4100
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup, Configuration
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> Once TS-4099 lands, remove the XML statistics and corresponding code in the
> {{StatsProcessor}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4646) Revisit SSL statistics exposed
[ https://issues.apache.org/jira/browse/TS-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shrihari updated TS-4646: - Affects Version/s: 6.2.0 > Revisit SSL statistics exposed > -- > > Key: TS-4646 > URL: https://issues.apache.org/jira/browse/TS-4646 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Affects Versions: 6.2.0 >Reporter: Shrihari > > Based on an e-mail discussion, I am opening this bug to track SSL statistics. > To summarize from > (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201607.mbox/browser) > 1. 'proxy.process.ssl.total_success_handshake_count' is a derived metric. > However it is listed under 'RECT_PROCESS' which is owned by traffic_server as > per the code. I feel this should either be under 'RECT_NODE' if it still > needs to be a derived metric. If not, it should not be a derived metric. > Instead, it should be redefined in traffic_server. > I haven't looked into any other ssl stats as of now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4646) Revisit SSL statistics exposed
Shrihari created TS-4646: Summary: Revisit SSL statistics exposed Key: TS-4646 URL: https://issues.apache.org/jira/browse/TS-4646 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Shrihari Based on an e-mail discussion, I am opening this bug to track SSL statistics. To summarize from (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201607.mbox/browser) 1. 'proxy.process.ssl.total_success_handshake_count' is a derived metric. However it is listed under 'RECT_PROCESS' which is owned by traffic_server as per the code. I feel this should either be under 'RECT_NODE' if it still needs to be a derived metric. If not, it should not be a derived metric. Instead, it should be redefined in traffic_server. I haven't looked into any other ssl stats as of now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-4642) Parent host healths across multiple configurations is inefficient
[ https://issues.apache.org/jira/browse/TS-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366312#comment-15366312 ] John Rushford edited comment on TS-4642 at 7/7/16 3:59 PM: --- @zwoop - yes i think we should close it but, I'll update the documentation before I do so. I think that most use cases can be accommodated as is. was (Author: jrushford): @zwoop - yes i think we should close it but, I'll update the documentation before I do so. I think that most use cases can accommodated as is. > Parent host healths across multiple configurations is inefficient > - > > Key: TS-4642 > URL: https://issues.apache.org/jira/browse/TS-4642 > Project: Traffic Server > Issue Type: Improvement > Components: Parent Proxy >Reporter: Leif Hedstrom >Assignee: John Rushford > Fix For: sometime > > > It seems that if I have multiple config lines in parent.config, where I use > the same list of parents for multiple rules, each such rules keeps it's own > "health" status? That means that if you repeat a line 100 times, the number > of "failures" until marked down is 100x more than what we configured in > records.config. > It seems that the health and failure counts should be per host, such that > regardless of how many times I use each host in parent.config, it'll > consistently use the settings from records.config. > So, I'm not 100% sure this is how things works, but if they are not, I blame > Phil. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4642) Parent host healths across multiple configurations is inefficient
[ https://issues.apache.org/jira/browse/TS-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366312#comment-15366312 ] John Rushford commented on TS-4642: --- @zwoop - yes i think we should close it but, I'll update the documentation before I do so. I think that most use cases can accommodated as is. > Parent host healths across multiple configurations is inefficient > - > > Key: TS-4642 > URL: https://issues.apache.org/jira/browse/TS-4642 > Project: Traffic Server > Issue Type: Improvement > Components: Parent Proxy >Reporter: Leif Hedstrom >Assignee: John Rushford > Fix For: sometime > > > It seems that if I have multiple config lines in parent.config, where I use > the same list of parents for multiple rules, each such rules keeps it's own > "health" status? That means that if you repeat a line 100 times, the number > of "failures" until marked down is 100x more than what we configured in > records.config. > It seems that the health and failure counts should be per host, such that > regardless of how many times I use each host in parent.config, it'll > consistently use the settings from records.config. > So, I'm not 100% sure this is how things works, but if they are not, I blame > Phil. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4638) Get rid of HostDBBackgroundTask
[
https://issues.apache.org/jira/browse/TS-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366303#comment-15366303
]
Leif Hedstrom commented on TS-4638:
---
Very much +1 on this.
> Get rid of HostDBBackgroundTask
> ---
>
> Key: TS-4638
> URL: https://issues.apache.org/jira/browse/TS-4638
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: James Peach
> Fix For: 7.0.0
>
>
> There is exactly 1 HostDB background task, namely {{HostDBSync}}, so there's
> no point having a class hierarchy to share any code. This is just unnecessary
> complexity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4638) Get rid of HostDBBackgroundTask
[
https://issues.apache.org/jira/browse/TS-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-4638:
--
Fix Version/s: 7.0.0
> Get rid of HostDBBackgroundTask
> ---
>
> Key: TS-4638
> URL: https://issues.apache.org/jira/browse/TS-4638
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: James Peach
> Fix For: 7.0.0
>
>
> There is exactly 1 HostDB background task, namely {{HostDBSync}}, so there's
> no point having a class hierarchy to share any code. This is just unnecessary
> complexity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4635) fix HostDB file descriptor handling
[
https://issues.apache.org/jira/browse/TS-4635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366274#comment-15366274
]
ASF GitHub Bot commented on TS-4635:
Github user zwoop commented on the issue:
https://github.com/apache/trafficserver/pull/788
:+1:
> fix HostDB file descriptor handling
> ---
>
> Key: TS-4635
> URL: https://issues.apache.org/jira/browse/TS-4635
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0
>
>
> Various file descriptor handling bugs syncing HostDB.
> 1. RefCountCacheSerializer::fd is initialized to 0 rather than -1
> 2. RefCountCacheSerializer::initialize_storage checks for fd <= 0 rather than
> -1
> 3. Any time the RefCountCacheSerializer is deleted it leaks the file
> descripto.
> 4. Leaks on error paths in RefCountCacheSerializer::finalize_sync()
> There is a fd leak somewhere:
> {noformat}
> [ET_NET 23444 nmadmin 32u REG 202,1 12 524318
> /n/trafficserver/var/host.db.syncing
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4635) fix HostDB file descriptor handling
[
https://issues.apache.org/jira/browse/TS-4635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366270#comment-15366270
]
ASF GitHub Bot commented on TS-4635:
Github user zwoop commented on the issue:
https://github.com/apache/trafficserver/pull/788
Hmmm, this code looks overly complicated already to begin with :-/. Why is
RefCountCacheSerializer a template class? It's tightly coupled with HostDB it
seems, and is only used to contain HostDBInfo?
If we are going to clean this up, I'd strongly suggest not using templates
just because. I know this isn't your fault James (in any way), and you are
trying to make it better, but this is not good.
That much said, I'm ok with the refactoring, it's making it a bit better
(but I still don't like this :). As someone smart said, this is premature
generalization.
> fix HostDB file descriptor handling
> ---
>
> Key: TS-4635
> URL: https://issues.apache.org/jira/browse/TS-4635
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0
>
>
> Various file descriptor handling bugs syncing HostDB.
> 1. RefCountCacheSerializer::fd is initialized to 0 rather than -1
> 2. RefCountCacheSerializer::initialize_storage checks for fd <= 0 rather than
> -1
> 3. Any time the RefCountCacheSerializer is deleted it leaks the file
> descripto.
> 4. Leaks on error paths in RefCountCacheSerializer::finalize_sync()
> There is a fd leak somewhere:
> {noformat}
> [ET_NET 23444 nmadmin 32u REG 202,1 12 524318
> /n/trafficserver/var/host.db.syncing
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4642) Parent host healths across multiple configurations is inefficient
[ https://issues.apache.org/jira/browse/TS-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366218#comment-15366218 ] Leif Hedstrom commented on TS-4642: --- [~jrushford] Should we just close this one as Won't Fix? Or do you think there's legitimate use cases where you want to treat some "groups" of parents the same? I'm ok either way, your use case makes a lot of sense. If we close it, we should perhaps update the documentation with the current behavior? > Parent host healths across multiple configurations is inefficient > - > > Key: TS-4642 > URL: https://issues.apache.org/jira/browse/TS-4642 > Project: Traffic Server > Issue Type: Improvement > Components: Parent Proxy >Reporter: Leif Hedstrom >Assignee: John Rushford > Fix For: sometime > > > It seems that if I have multiple config lines in parent.config, where I use > the same list of parents for multiple rules, each such rules keeps it's own > "health" status? That means that if you repeat a line 100 times, the number > of "failures" until marked down is 100x more than what we configured in > records.config. > It seems that the health and failure counts should be per host, such that > regardless of how many times I use each host in parent.config, it'll > consistently use the settings from records.config. > So, I'm not 100% sure this is how things works, but if they are not, I blame > Phil. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
