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. The primary difference is that warning is more backwards compatible with previous behaviour, wheras croak is little cleaner to try/catch. 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
