DisconnectionError not raised when TCP errors messup underlying PostgreSQL db connection

Bug #1025264 reported by Stuart Bishop
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Storm
Triaged
Undecided
Unassigned

Bug Description

Per Bug #1000805, it is possible for the following exception to be raised when issuing a query:

psycopg2.OperationalError: could not send data to server: Connection timed out

While this is probably a network issue that needs fixing, Storm still should detect that this is a disconnection error and reraise it as a DisconnectionError, so the store is put into the 'will reconnect' state.

Related branches

Stuart Bishop (stub)
tags: added: disconnection postgresql
Revision history for this message
Stuart Bishop (stub) wrote :

Storm already catches all DatabaseError subclasses (including OperationalError) that set the psycopg2 connection object's closed attribute. So for the bug's situation to happen, I think it means psycopg2 is not flagging the connection as closed if this TCP failure happens.

Changed in storm:
status: New → Invalid
status: Invalid → Triaged
Revision history for this message
Stuart Bishop (stub) wrote :

Need to verify that this is really happening.

no longer affects: psycopg
Changed in storm:
status: Triaged → Incomplete
Stuart Bishop (stub)
Changed in storm:
status: Incomplete → Triaged
Revision history for this message
Stuart Bishop (stub) wrote :

It looks like we don't reraise failures when constructing Stores as DisconnectionErrors.

stub@aargh:~/lp/replication$ python
Python 2.7.3 (default, Aug 1 2012, 05:14:39)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from storm.locals import *
>>> db = create_database('postgres://localhost:6666/whatever')
>>> from storm.exceptions import DisconnectionError
>>> try:
... store = Store(db)
... except DisconnectionError:
... print 'storm exception'
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/local/lib/python2.7/dist-packages/storm-0.19-py2.7-linux-x86_64.egg/storm/store.py", line 73, in __init__
    self._connection = database.connect(self._event)
  File "/usr/local/lib/python2.7/dist-packages/storm-0.19-py2.7-linux-x86_64.egg/storm/database.py", line 410, in connect
    return self.connection_factory(self, event)
  File "/usr/local/lib/python2.7/dist-packages/storm-0.19-py2.7-linux-x86_64.egg/storm/database.py", line 185, in __init__
    self._raw_connection = self._database.raw_connect()
  File "/usr/local/lib/python2.7/dist-packages/storm-0.19-py2.7-linux-x86_64.egg/storm/databases/postgres.py", line 329, in raw_connect
    raw_connection = psycopg2.connect(self._dsn)
  File "/usr/lib/python2.7/dist-packages/psycopg2/__init__.py", line 179, in connect
    connection_factory=connection_factory, async=async)
psycopg2.OperationalError: could not connect to server: Connection refused
 Is the server running on host "localhost" (127.0.0.1) and accepting
 TCP/IP connections on port 6666?

Revision history for this message
Stuart Bishop (stub) wrote :

The problem seems to be we are opening the connection in the constructor rather than deferring this until the Store is used. I think it is safe to wrap the raw_connect with _check_disconnect

Revision history for this message
Sidnei da Silva (sidnei) wrote :

Linked possibly related fix for an error that happens at runtime (instead of at connection construction). Please mark as fix released if it fixes the issue.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.