On Tue, Feb 18, 2014 at 9:07 PM, Ævar Arnfjörð Bjarmason <[email protected]> wrote: > 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.
I honestly didn't remember this when I wrote this yesterday but a while ago I wrote a PSGI spec proposal to normalize the return values of these streaming functions between different servers: https://github.com/plack/psgi-specs/wiki/Proposal:-Return-values-for-PSGI-streaming-functions > 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
