Hi Joseph:

In message <1533083205.99.0.56676864532.issue2550750@psf.upfronthosting.co.za>,
Joseph Myers writes:
>Joseph Myers added the comment:
>My underlying expectation here is that the admin should get email when
>there is a bug in Roundup or the instance code, but not simply for
>attempts to access the instance by a client on a bad connection, or by a
>misbehaving client.  (There are lots of robots and other clients out
>there doing things that a proper browser implementation of HTTP, on a
>good connection, following valid links and making valid form submissions
>only, would never do, and so there can be unhelpfully many such emails
>when a robot does the same problematic thing on many pages.  I have a
>few other Roundup backtraces to investigate that may also relate to
>clients doing dubious things.)

Ah ok, I understand your point. My expectation is obviously different.

How about amending your patch with a check to see if the option
"IgnoreSocketTimeout" is set. If it is set to true, block the
exception from being propigated (as your patch does). If the setting
is false, re-assert the exception letting the normal roundup error
handler take effect.

Also I would make sure that there is a warning level log message
emitted if the email is suppressed. That way no email is sent but a
trace is left to give the admin a clue when somebody complains.

>I do happen to have an unsubmitted local patch to increase the default
>timeout from a hardcoded 60 seconds to a hardcoded 300 seconds
>(essentially an attempt to reduce the frequency of the errors in the
>present issue from before I wrote the patch attached to this issue, I
>think).

I think a minute timeout should be good in the majority of cases. It
would be nice to make that configurable rather than just raising the
timeout as that makes it easier to run the server out of resources.