[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 --- Comment #14 from John Harper --- I get a kick out of coming by your blog website. You are definitely clever and create so well. Thanks for striving on this specific wordpress blog. http://www.plerb.com/jerry0111 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 --- Comment #13 from jimmyjoe <3ac453d...@emailmonkey.club> --- Great work man. its wonderful and always pleasure to work with you. thank you. https://getmyoffer.live/ -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 --- Comment #12 from ava james --- Your work is just excellent. I really love your work and thanks for sharing these resources. https://doubleyourlineoffer.com/doubleyourline/ https://www.peryourhealthonline.com/peryourhealth/ https://www.getmyoffersonline.com/getmyoffers-capital-one/ https://mymedicalpaymentsonline.com/mymedicalpayments/ https://myaarpmedicareonline.xyz/myaarpmedicare/ https://indigo-apply.com/www-indigoapply-com/ https://www.indi-apply-go.com/indigoapply-com/ -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 --- Comment #11 from sandy45 --- Companies must have the necessary computer applications to issue and receive invoices. There must be compatibility between the formats of the company that issues the invoice and who receives it. Sometimes, the system can cause delays if the staff does not know it well. Adapting systems translates into costs for the company. Electronic failures can cause the loss of information. https://raizofsuccess.com/www-quickpayportal-com-29/ -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 Graham Leggett changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Graham Leggett --- Backported to v2.4.36. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 WJCarpenter changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #9 from WJCarpenter --- I confirm that the patch fixed the problem in my test environment. NOTE: My environment is 2.4.33 to which I manually made the change from the patch. Thanks for the fix. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 --- Comment #8 from Jim Jagielski --- Thx. Awaiting your check. I can confirm that the patch passes my tests which recreated the original problem -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 --- Comment #7 from WJCarpenter --- The change is one of the things I tried, and it does solve the problem of having multiple outstanding health checks for the same target. One of the things I was not sure about (and am still not sure about) is whether it's better to set "updated" to the time of the beginning of the health check or the time of the end of the health check. It's a design decision that could go either way, depending on what you think "interval" should mean, as you commented earlier. I previously gave this kind of change a quick sanity test. I should be able to do more thorough testing next week. I'll report back with the results either way. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 Jim Jagielski changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #6 from Jim Jagielski --- According to my testing, the below patch seems to fix this. Can you test as well? http://svn.apache.org/viewvc?rev=1838937=rev -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 --- Comment #5 from WJCarpenter --- (sorry) I meant "the watchdog timer will consider doing the callback every 100ms" -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 --- Comment #4 from WJCarpenter --- Jim Jagielski, I don't understand what you are trying to say. No amount of changing the configured interval for the health checks will alter the fact that the watchdog timer does the callback every 100ms. In fact, the default for hcinterval is 60s, which suggests what the module author had in mind for the order of magnitude of that parameter. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 --- Comment #3 from Eric Covener --- (In reply to Jim Jagielski from comment #2) > The issue appears to be one of, mainly, interpretation of what an interval > is. As seen in the code and the documentation, the value of the interval > determines when a health check *is performed*. It does not define the time > *between* health checks, which is a separate timing entirely. > > It is also assumes that the sysadmin matches the interval time with the time > taken to perform said health check and avoids such nonsense as kicking off a > check every 100ms if the health check itself takes 250ms. I don't think increasing the interval helps with a slow health check, since we check every AP_WD_TM_SLICE to see if a health check has completed in the desired interval. If my health check takes 1 second and the interval is 10 seconds, we will still kick off 10 health checks in rapid succession just after 10 seconds has elapsed. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 --- Comment #2 from Jim Jagielski --- The issue appears to be one of, mainly, interpretation of what an interval is. As seen in the code and the documentation, the value of the interval determines when a health check *is performed*. It does not define the time *between* health checks, which is a separate timing entirely. It is also assumes that the sysadmin matches the interval time with the time taken to perform said health check and avoids such nonsense as kicking off a check every 100ms if the health check itself takes 250ms. Personally, I don't consider this a bug but rather expected behavior and behavior as designed. Admittedly, the docs could make this clearer and should be updated. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318 WJCarpenter changed: What|Removed |Added CC||bill-apa...@carpenter.org -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62318] healthcheck executed more often than configured in hcinterval
https://bz.apache.org/bugzilla/show_bug.cgi?id=62318
--- Comment #1 from WJCarpenter ---
I recently hit this problem, and I think I understand why it happens. I did a
simple proof-of-concept change to validate my theory. Although I was also
working with 2.4.33, I don't see any recent changes to suggest it's a new bug.
BTW, I saw this on a Windows 10 Enterprise machine.
The health checks are done via callbacks from the watchdog timer module. The
callback is scheduled to run every AP_WD_TM_SLICE interval. On my server,
that's 100 milliseconds (I didn't investigate whether it's 100ms for everyone).
When triggered, the callback iterates over all of the configured health checks
to see which need attention. And, for any that are "due", the health check is
performed.
In mod_proxy_hchceck.c, in function hc_watchdog_callback(), near line 928 (in
2.4.33), there is this "if" condition:
if (!PROXY_WORKER_IS(worker, PROXY_WORKER_STOPPED) &&
(worker->s->method != NONE) &&
(now > worker->s->updated + worker->s->interval)) {
The last part is intended to mean "if the HC interval has passed since the last
time we checked, then do a health check".
If it is "due", according to that "if" condition, the actual health check is
kicked off in function hc_check(), near line 811 (in 2.4.33). It makes the TCP
or HTTP health check call made, the results evaluated, and the "updated"
timestamp is updated.
That's what the code does. Now, here is a description of the problem as I
understand it:
1. It's kind of icky to be polling every 100 ms compared to what would be a
normal health check interval [default is 60 s]. But I don't know if there is a
wiser way to do it in httpd.
2. The "if" condition and surrounding logic don't keep track of whether there
is already a health check in progress for a given target. I suppose there could
be a reason to allow multiple requests (hung connections?), but in any case it
at least contributes to this problem.
3. The "update" timestamp is updated after the health check is completed, but
it is updated with a timestamp from when the health check began. In other
words, if it takes 1000 ms for a health check call, the "updated" timestamp
will eventually be updated with a time 1000 ms in the past.
The points just mentioned conspire to keep the health check "due" on every 100
ms watchdog callback if the individual health checks take longer than 100 ms to
complete. Suppose, for example, each health check for a given target takes 1000
ms. Then there will be 9 or 10 in-progress health checks for that target. As
each finishes, it will mark the "updated" timestamp to 1000 ms in the past. The
situation will never resolve until the elapsed time for the health checks drops
below 100 ms. That's made less likely by the additional health checks
contributing to the load.
To test the theory, I locally modified the hc_check() function to modify the
"updated" timestamp with the time the health check finishes instead of the time
it started. That produced the desired behavior. I have not examined that
solution for unexpected consequences.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
