Jeroen T. Vermeulen <jtv@...
2007-08-13 03:29:09 GMT
On Sun, August 12, 2007 14:39, Bart Samwel wrote:
> ...but generally intended to be a precise one if the user doesn't
> manually cancel what he's waiting for. So timeouts are generally not the
> thing. Think of loading web pages: there's a network timeout of several
> minutes, but there's also a "stop" button. I would be very annoyed if I
> would replace this with only a timeout, but not with only a stop button.
But if there's an application running behind the web page, and a query
inside that application is taking too long, then at some point the
application must conclude that:
1. The user isn't going to get an answer in reasonable time, and it may be
better to tell him "no can do" than to keep him waiting.
2. There may be something seriously wrong with the query, or with system
load, and the application had better abort the query to protect itself.
The user is likely at some point to move on to something else anyway, and
it doesn't make much sense to continue processing. Worst case, the user
has already tried to reload the page a few times and you may have several
instances of the problem query running at the same time.
> And consider "real-time monitoring" software, e.g. something displaying
> a graph. If the data doesn't get there on time for a once-a-second graph
> update, should the query be cancelled? No: otherwise it probably won't
> get there on time *every* second.
Yes, if the job can't make its real-time constraint, it should be
canceled. If the application consistently can't make its time goals, then