DisconnectionErrors (already disconnected) happening again
Bug #504291 reported by
Ursula Junque
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
William Grant | ||
Storm |
Invalid
|
Undecided
|
Unassigned |
Bug Description
We had some in 3rd, then a bunch of DisconnectionErrors on 4th, only staging, as we can see in the summaries: https:/
elmo reported to have upgraded postgresql on sourcherry (the staging DB server) at 2010-01-03, 23:35, but we don't know if that's the cause of all of them.
Now we can see them on lpnet and edge summaries, not staging:
https:/
https:/
Related branches
lp:~stub/launchpad/bug-504291-disconnection-errors
Merged
into
lp:launchpad
- Henning Eggers (community): Approve (code)
-
Diff: 194 lines (+78/-20)4 files modifiedlib/canonical/launchpad/webapp/dbpolicy.py (+4/-1)
lib/canonical/launchpad/webapp/publication.py (+20/-4)
lib/canonical/launchpad/webapp/tests/test_publication.py (+52/-15)
lib/lp/scripts/utilities/importfascist.py (+2/-0)
lp:~wgrant/launchpad/no-fdt-oopses
- Colin Watson (community): Approve
-
Diff: 212 lines (+102/-14)4 files modifieddatabase/replication/Makefile (+13/-7)
lib/lp/services/webapp/errorlog.py (+14/-0)
lib/lp/services/webapp/publication.py (+9/-3)
lib/lp/services/webapp/tests/test_error.py (+66/-4)
affects: | blueprint → launchpad-foundations |
Changed in storm: | |
status: | New → Invalid |
Changed in launchpad-foundations: | |
status: | Triaged → In Progress |
Changed in launchpad-foundations: | |
assignee: | nobody → Stuart Bishop (stub) |
Changed in launchpad-foundations: | |
milestone: | none → 10.01 |
Changed in launchpad-foundations: | |
status: | Fix Committed → Fix Released |
Changed in launchpad: | |
status: | Incomplete → Invalid |
Changed in launchpad: | |
assignee: | nobody → William Grant (wgrant) |
status: | Triaged → In Progress |
tags: |
added: qa-ok removed: qa-needstesting |
Changed in launchpad: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Looks as if a storm.Connection gets stuck in STATE_DISCONNECTED ("I'm broken and will stay that way until you roll me back") instead of STATE_RECONNECT ("I'll re-open when you need me again"). We need the latter at the end of a request so that the next request can re-use the connection.
The cause might be this:
canonical. launchpad. webapp. publication. LaunchpadBrowse rPublication. afterCall does...
if request.method in ['GET', 'HEAD']:
self. finishReadOnlyR equest( txn)
txn. abort() # Sends an abort to the database, even though
txn. commit( )
elif txn.isDoomed():
# transaction is still doomed.
else:
This amounts to:
if request.method == "POST" and not txn.isDoomed():
txn.commit( )
txn.rollback( )
else:
Makes sense to me, but unfortunately storm.database. Connection. commit goes into STATE_DISCONNECTED on failure. Only a rollback can get it back to STATE_RECONNECT. So we'd need to catch disconnection errors coming out of txn.commit() and handle them by calling txn.abort() after all.