Hi Máté,
On 15/12/2020 23:12, Máté Kocsis wrote:
I've just collected a few examples when my proposal would be useful:
https://gist.github.com/kocsismate/dbcc4ba81b27cfb2e25b949723bb7c79
[...]
Do the above examples and this reasoning make sense to you? Also, I'll
improve the wording I used when describing the consequences.
The part I'm curious about is not so much when the setting would have an
effect, as when it would be the desired solution.
Your point about the server not being able to serve any more connections
is reasonable, and I can see this being a useful last resort mechanism
to keep the server responding. I'd be likely to treat it similarly to
the Linux OOM killer: if it was ever actually invoked, I would be
investigating how to fix my application.
The wording in your e-mails and RFC suggests you see it as something
you'd use instead of application-level solutions, rather than as well as
them, and that's what I'm trying to picture the use case for.
One scenario I can think of would look a bit like this:
foreach ( $ordersToProcess as $orderDetails ) {
$result = send_order_to_remote_system($orderDetails);
save_confirmation_to_db($orderDetails->customerOrderRef,
$result->supplierOrderRef);
}
If the remote system responded very slowly, that loop might take many
times the expected duration. If we simply kill the process when a fixed
wall time has elapsed, we're very likely to create an order on the
remote system, but exit without saving its reference. It is however easy
to see where in that loop we could safely call a routine like
throw_exception_if_time_limit_reached().
If rather than placing orders, the loop was just gathering search
results, killing the process would be less dangerous, but cleanly
exiting would still be preferable, because we could return a warning and
partial results, rather than a 500 error.
Other scenarios I can think of have similar problems:
* If the database locks up inside a transaction, killing the process
probably won't roll that transaction back cleanly
* If the process was working through a large import of data, it may have
written a bunch of temporary data to disk or holding tables which won't
be cleaned up
In other words, I can only think of cases where "the cure would be worse
than the disease".
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
