[Bug 48388] mod proxy disabling workers after a single error
https://issues.apache.org/bugzilla/show_bug.cgi?id=48388 --- Comment #13 from Ruediger Pluem rpl...@apache.org --- (In reply to Yann Ylavic from comment #10) Created attachment 32341 [details] Don't put normal (non balancer-member) workers in error (trunk/2.4.x) This patch should prevent httpd from putting workers which are *not* load-balancer members in error state, since we don't want the retry timeout to be applied when there is no alternative to connect to. -1 as this being hardcoded. This can be already done with retry=0. We may discuss to set retry=0 as a default value in this case if not set explicitly. It may make sense to put even a single backend in error state for some time to give the backend some time to recover without new requests sent to it and have them blocked at the reverse proxy layer. -- 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 48388] mod proxy disabling workers after a single error
https://issues.apache.org/bugzilla/show_bug.cgi?id=48388
--- Comment #14 from Yann Ylavic ylavic@gmail.com ---
(In reply to Ruediger Pluem from comment #13)
(In reply to Yann Ylavic from comment #10)
Created attachment 32341 [details]
Don't put normal (non balancer-member) workers in error (trunk/2.4.x)
This patch should prevent httpd from putting workers which are *not*
load-balancer members in error state, since we don't want the retry timeout
to be applied when there is no alternative to connect to.
-1 as this being hardcoded. This can be already done with retry=0. We may
discuss to set retry=0 as a default value in this case if not set
explicitly. It may make sense to put even a single backend in error state
for some time to give the backend some time to recover without new requests
sent to it and have them blocked at the reverse proxy layer.
Nothing is hardcoded here, the default being still status=-I for
balancer-members, but changed to status=+I for the standalone workers (but it
can still be opt-out).
This is indeed debatable, the backend's time-to-recover argument is right/real,
but there is no status=+I vs retry=0 here, both would change the default
behaviour (is that acceptable?).
The only difference (I see) between status=+I and retry=0 is the logging of the
worker's error/recovery states (in addition to the protocol/socket error).
I think this logging should be done only for status=-I workers (hence +I should
ignore any error, not only those from connect()/handshake, eg.
failon{status,timeout} or 500/503...).
This is at least what I did (try to) implement in this patch, so that users
with simple workers don't bother (including logs) with recovery period if they
configured so (or by default, if acceptable).
--
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 57416] New: htcacheclean thinks the cache is smaller than it actually is
https://issues.apache.org/bugzilla/show_bug.cgi?id=57416 Bug ID: 57416 Summary: htcacheclean thinks the cache is smaller than it actually is Product: Apache httpd-2 Version: 2.5-HEAD Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: mod_cache_disk / mod_disk_cache Assignee: bugs@httpd.apache.org Reporter: chaos...@gmail.com Created attachment 32347 -- https://issues.apache.org/bugzilla/attachment.cgi?id=32347action=edit Sum physical sizes rather than logical sizes in htcacheclean When running htcacheclean on a large disk cache directory, it uses the logical sizes of the files instead of the physical size. Since the header and vary files are almost always below the block size of the filesystem, the size on disk of the cache directory can grow to be drastically more than what htcacheclean thinks. In my testing, I got du -hs to report that the cache directory was 12G, while htcacheclean -v reported around 3G. It seems like there's an easy fix for this, since apr_stat() reports the physical size as well as the logical size; this leaves me wondering whether this was a deliberate choice. However, I think using the logical size is counterintuitive - after all, the user's intention is generally to limit the physical size of the cache directory, and doesn't care about the logical size of the files. The attached patch changes htcacheclean to sum files' physical size, instead of their logical size. There's still a problem in that hcacheclean still does not add the sizes of the directory nodes themselves, which can also be significant; however, this change at least brings the size closer to what a user would expect. -- 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 57416] htcacheclean thinks the cache is smaller than it actually is
https://issues.apache.org/bugzilla/show_bug.cgi?id=57416 Edward Lu chaos...@gmail.com changed: What|Removed |Added Keywords||PatchAvailable -- 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 57416] htcacheclean thinks the cache is smaller than it actually is
https://issues.apache.org/bugzilla/show_bug.cgi?id=57416 --- Comment #1 from Eric Covener cove...@gmail.com --- How far off is the mismatch after the patch? Worth mentioning in the manual that it underestimates? -- 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 48388] mod proxy disabling workers after a single error
https://issues.apache.org/bugzilla/show_bug.cgi?id=48388 --- Comment #15 from Ruediger Pluem rpl...@apache.org --- (In reply to Yann Ylavic from comment #14) (In reply to Ruediger Pluem from comment #13) (In reply to Yann Ylavic from comment #10) Created attachment 32341 [details] Don't put normal (non balancer-member) workers in error (trunk/2.4.x) This patch should prevent httpd from putting workers which are *not* load-balancer members in error state, since we don't want the retry timeout to be applied when there is no alternative to connect to. -1 as this being hardcoded. This can be already done with retry=0. We may discuss to set retry=0 as a default value in this case if not set explicitly. It may make sense to put even a single backend in error state for some time to give the backend some time to recover without new requests sent to it and have them blocked at the reverse proxy layer. Nothing is hardcoded here, the default being still status=-I for balancer-members, but changed to status=+I for the standalone workers (but it can still be opt-out). Sorry I misread the patch here. So no worries. As said changing the default makes sense for trunk. As this setup can already be reached by explicit configuration I would not backport it. -- 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 55445] mod_socache_memcache ignores expiry, creating eternal memcache entries
https://issues.apache.org/bugzilla/show_bug.cgi?id=55445 Eric Covener cove...@gmail.com changed: What|Removed |Added Keywords||FixedInTrunk --- Comment #5 from Eric Covener cove...@gmail.com --- fixed in trunk http://svn.apache.org/r1649491 -- 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 55445] mod_socache_memcache ignores expiry, creating eternal memcache entries
https://issues.apache.org/bugzilla/show_bug.cgi?id=55445 Matt Jamison m...@mattjamison.com changed: What|Removed |Added Hardware|PC |All Version|2.4.6 |2.4-HEAD OS|Linux |All Severity|normal |major --- Comment #4 from Matt Jamison m...@mattjamison.com --- Strange, I'm going to tweak some things in the bug just to see if it'll get someone's attention. Hopefully we can at least get a pointer on how to get this committed... -- 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 57416] htcacheclean thinks the cache is smaller than it actually is
https://issues.apache.org/bugzilla/show_bug.cgi?id=57416 --- Comment #2 from Edward Lu chaos...@gmail.com --- After the patch, the difference was 12G vs 9G (physical vs logical). A note in the documentation would help, but it would be better if we summed the directory node sizes too and brought the two sizes to parity. I can take a look at that when I've got the bandwidth, or someone else can take it on. -- 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 57416] htcacheclean thinks the cache is smaller than it actually is
https://issues.apache.org/bugzilla/show_bug.cgi?id=57416 --- Comment #3 from Eric Covener cove...@gmail.com --- I've been searching and I am a bit concerned that csize in APR might be a little optimistic about really representing the overhead. I noticed on Unix it uses a constant rather than st_blksize for example.Maybe we could take the larger of size and csize here? I also saw that we need to pass CSIZE as 'wanted' to get it back on Windows. -- 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
