Check for hard time out expiration as we retrieve rows from the database cursor
Bug #228352 reported by
Francis J. Lacoste
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Storm |
Triaged
|
Low
|
Unassigned | ||
Bug Description
The hard time out expiration is only checked for by the database while it executes the query. Once the query is executed, the timeout isn't checked again until the next query or (once bug 288331 is fixed) the view completes. A nice improvement to save on resources would be to raise the timeout exception as we retrieve results from the database. The database cursor should check regularly (once every 100 or 1000 or N rows) if the timeout is expired and raise the appropriate exception if it is.
| Changed in launchpad: | |
| importance: | Undecided → High |
| status: | New → Triaged |
| visibility: | private → public |
Revision history for this message
| Robert Collins (lifeless) wrote | #1 |
| affects: | launchpad → storm |
| Changed in storm: | |
| importance: | High → Low |
| tags: | removed: infrastructure lp-foundations |
To post a comment you must log in.
According to jamesh, all the rows are buffered by the postgresql python driver anyway, so getting rows from the resultset, even incrementally, is basically a no-op. That said, we could certainly do this to free up some resources when CPU time is the issue.
The right place to do this check is in the storm TimeoutTracer though, so I'm going to a) downgrade to low because of the minimal benefits, and b) retarget this to storm.