Opened 9 years ago

Closed 9 years ago

#4650 closed (fixed)

Since [5482], mod_python keeps a stale database connection for each HTTP request

Reported by: Ilya Semenov <semenov@…> Owned by: Adrian Holovaty
Component: Core (Other) Version: master
Severity: Keywords:
Cc: ferringb@… Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Since [5482], a template is lazy-rendered. However under mod_python environment, the signal to close database connection (signals.request_finished) is sent before a template is actually rendered. If a connection is then reopened by demand during the rendering process, it will not be ever closed again and result in a stale connection, which soon overwhelms the database server.

Attached the proposed patch (sending the request_finished signal after the template is actually rendered).

Note: this can also fix #4612, though I'm not completely sure.

Attachments (2)

stale_connections_fix.diff (1.6 KB) - added by Ilya Semenov <semenov@…> 9 years ago.
response-wrapping.patch (1.7 KB) - added by (removed) 9 years ago.
Wrap the response object, firing the signal once the response object is fully consumed

Download all attachments as: .zip

Change History (5)

Changed 9 years ago by Ilya Semenov <semenov@…>

Attachment: stale_connections_fix.diff added

Changed 9 years ago by (removed)

Attachment: response-wrapping.patch added

Wrap the response object, firing the signal once the response object is fully consumed

comment:2 Changed 9 years ago by (removed)

Cc: ferringb@… added

If folks could kindly give that a test, would be appreciated- still preserves the iteration, but basically injects the signal firing as the last step for full iteration of the object.

At least for the mod_python wsgi implementation I looked over (and digging through pep 333), this *should* do the trick. Comments/complaints/feedback desired.

comment:3 Changed 9 years ago by Simon G. <dev@…>

Resolution: fixed
Status: newclosed

[5482] was backed out in [5511]

Note: See TracTickets for help on using tickets.
Back to Top