[squid-users] squid 5.3 frequent crash

[Alex Rousskov]

On 1/18/22 2:51 AM, Amos Jeffries wrote:
> On 8/01/22 05:02, Alex Rousskov wrote:
>> On 1/7/22 9:34 AM, Amos Jeffries wrote:
>>> Others include altering the fundamental AsyncJob API behaviour -
>>> affecting every feature in Squid at their most fundamental levels.

>> I disagree with the above summary.

> This is not an opinion.

It is impossible to tell for sure whether this is an opinion or a fact
because the summary is using undefined terms like "every feature" and
"most fundamental levels". To you, it may sound like a fact. To me, it
sounds like gross exaggeration at best: Clearly, there are Squid
features (for some reasonable definition of a "feature") unaffected by
this change at "most fundamental levels" (for some reasonable definition
of "most fundamental levels").


> The patch "part 2" makes logic changes to
> AsyncJob - specifically destructors and swanSong. That touches
> *everything* Squid does. The other parts touch I/O in similarly deep
> ways and we have a history of unexpected weird side effects with I/O
> refactorings.

I do not think squid-users is the right place to debate complex
development issues. I will just note that the commit in question does
not, IMO, change AsyncJob methods in fundamental ways. It only shrinks
the long-known gray area of what those functions should (not) do. Before
this change, we did not know where certain actions should take place.
Now, we (think we) do, and we have adjusted a few places to follow those
newly discovered rules.

Will this complex change have unexpected side effects? Yes, of course! I
have disclosed that risk when posting the changes. No need to grossly
exaggerate to agree on that point -- nobody is arguing against it.


> I am seriously considering using our exceptional beta release process
> for these changes once v5.4 bug fixes are out.

FWIW, I see no need for a special process here. We have no reasons to
believe that the change is making Squid v5 worse overall. All those who
tested the change in v5 and master reported significant improvement in
Squid stability. Moreover, since the last numbered v5 release was
unstable (for many reasons), the bar for the next numbered v5 release is
pretty low: We are not going from very stable to possibly unstable; we
are going from very unstable to possibly less unstable.

Said that, I am not trying to block the "exceptional beta release
process" you want to use. I am just providing feedback. Most v5 actions
are your call as a v5 maintainer, including special v5.x.y snapshots
that have three numbers instead of the usual two.


> IMO the best code to base your backport PR on would be the v5 HEAD after
> 1st Feb when I post the "prep for 5.4" or similar QA for review.

To avoid misunderstanding, when you have a commit SHA that the backport
should be based on, please let me know that SHA, and I will start
backporting from that point. That commit/SHA does not have to be in the
official branch, of course.


> That gives us 6 weeks for validation before v5.5 release decisions are
> made. I seriously *hope* that is enough testing not to be hit later with
> another one of these.

FWIW, all other factors being equal, I doubt you would see more "beta"
v5 testers than you would see without any special "beta" releases. If
anything, the opposite is probably true. That is one of the several
reasons I do not recommend using special procedures for releasing this
important bug fix in v5. Again, this is your call.


HTH,

Alex.