On Tue, Feb 18, 2014 at 7:51 PM, demerphq <[email protected]> wrote: > There is a contradiction in what you say. On one hand, you say > "clients going away is OK" and the other you say "croaking is ok". > Normally one does not throw an exception when people do something that > is ok. Hence my thought that using the warning subsystem is better, as > it means that > > no warnings; > > would turn off the warnings, but a __WARN__ handler can catch them and > do something more specific if they want. Making it croak turns that > around, you cant turn them off for a simple app, and you more or less > have to catch them.
When uWSGI croaks it doesn't croak in a vacuum. If that's the default behavior you have to consider how other default behavior interacts with it. The main task for most web applications is to generate some content and return it to the client. If the client has gone away then most of the time there's no point in continuing. Doing so would be a waste of resources, so just dying and aborting instead of warning and continuing is the right default behavior. By default uWSGI institutes a global __DIE__ handler under Perl, so even if the API dies and you don't have a containing eval() the child won't actually die, it'll just exit to the top-level. This has to be explicitly disabled with "perl-no-die-catch = true" in the configuration. Even if you haven't set "perl-no-die-catch = true" and a child really dies due to an uncaught failing write() call the master process will just notice that the child went away and re-spawn the child almost instantly. That operation is usually much cheaper than letting the child pointlessly continue whatever it was doing, hoping it can write to a client that has gone away. > The primary difference is that warning is more backwards compatible > with previous behaviour, wheras croak is little cleaner to try/catch. I don't think adding a new die here is really a matter of breaking backwards compatibility. It's safe to say that before this change most uWSGI Perl applications would just continue to do pointless work for no reason when this happened, now they'll abort early. I do think though that it's pretty unoptimal how vague the PSGI spec is about the return values of various functions including write() and close(). The spec doesn't say anything about it. In Perl (under e.g. IO::Handle) those functions don't die but just return a scalar value indicating how many bytes they managed to write. Perhaps that would be more sensible for consistency. But on the other hand most application developers will probably just ignore the return value unless you die() or warn() and forcefully bring it to their attention. > On 18 February 2014 19:45, Ævar Arnfjörð Bjarmason <[email protected]> wrote: >> I think the croak is good, I'm just catching it and turning it into a >> counter that I'm graphing. >> >> You'd expect a steady stream of these in any active site, I'm just logging >> them as non-errors (clients going away is OK) to see if the frequency goes >> up or down. >> >> I think dying is a good default, there's no point in the process doing more >> work if its client has disappeared. >> >> On 18 Feb 2014 18:53, "Roberto De Ioris" <[email protected]> wrote: >>> >>> >>> > Since I did a bit of digging into this I thought I'd sent a short >>> > message about it to the list since there wasn't anything equally >>> > informative online when I searched. >>> > >>> > When upgrading to 1.9.20 to 2.0 we started getting "error while >>> > streaming PSGI response" errors on various live requests when calling >>> > $writer->write($part) when using the streaming PSGI API. >>> > >>> > It turned out that this was happening all along before 2.0, but was >>> > just being silently ignored, this is the relevant commit that first >>> > appeared in 1.9.21: https://github.com/unbit/uwsgi/commit/46cceb0 >>> > >>> > This happens when a client aborts a request on their side, I solved it >>> > just by wrapping the ->write() call in an eval and logging when this >>> > happens. >>> >>> Is wrapping it a good solution ? >>> >>> That croak is there otherwise the server could never knows about client >>> being disconnected. >>> >>> How do you manage it ? >>> >>> This is an interesting (language-independent) problem, that i would like >>> to better address >>> -- >>> Roberto De Ioris >>> http://unbit.it >>> _______________________________________________ >>> uWSGI mailing list >>> [email protected] >>> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >> >> >> _______________________________________________ >> uWSGI mailing list >> [email protected] >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >> > > > > -- > perl -Mre=debug -e "/just|another|perl|hacker/" > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
