Comment 24 for bug 1466926

Thanks a lot hloeung for trying in that environment.
This is exactly what we needed.

Too bad thou for the fix, the TL;DR now is:
- there is an issue if users/scripts reload apache too often (bad practice but existing)
- we have backported the fix that is upstream and tested, but tests show that this will cause new issues in the SRU environment

For the SRU perspective there are four things now:
a) - backport the upstream fix and check for regressions - we tried that and failed

b) - One could start identifying more upstream changes related, but to be honest that will end up considering a backport of a full new apache2 release to Xenial (with probably even more potential fallout, not in terms of stability but e.g. need to adapt configs) -> not going to happen IMHO

c) - Usually we would try to identify a smaller subset of the fix that is more SRUable but this doesn't apply to this case -> So not going to happen either

d) - those (few) affected need to adapt their environment to not call reload so often
     The most likely outcome for now :-/

e) - One could get creative
     What would get to my mind is for example a rate limiting on the reloads.
     One would have to wait up to x time, and collect all requests until that time, then one
     reload would happen and all would return.
     But that is fixing a symptom and would (if done at apache2) surely affect some things out
     there that expect it to be immediately.
     So even for these cases fixing the environment that does the high reload counts is more
     wise, as there the special cases can better be considered.

In terms of an "overall user base SRU tradeoff" it feels safer to recommend those affected to fix the environment, instead of forcing that onto everyone.
So for now, until one has a better idea I'm sadly feeling I have to set this to "won't fix" for now.

@SRU Team - could one cancel the current upload from x-proposed?