DatabaseError: SSL SYSCALL error: EOF detected (Intermitten

[Auden RovelleQuartz]

I am getting the error (see below) intermittently - does anyone know what that error means?

{

Ticket ID

12.239.162.254.2015-06-02.15-18-57.cda87665-75a8-4c94-98a8-f4fe633e2c01

<class 'psycopg2.DatabaseError'> SSL SYSCALL error: EOF detected

Version

web2py™	Version 2.11.2-stable+timestamp.2015.05.30.16.33.24
Python	Python 2.7.3: /usr/bin/python (prefix: /usr)

Traceback

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.

Traceback (most recent call last): File "/home/www-data/web2py/gluon/restricted.py", line 227, in restricted exec ccode in environment File "/home/www-data/web2py/applications/omniavx_cxn/controllers/tradeespresso.py", line 5606, in <module> File "/home/www-data/web2py/gluon/globals.py", line 412, in <lambda> self._caller = lambda f: f() File "/home/www-data/web2py/applications/omniavx_cxn/controllers/tradeespresso.py", line 1398, in vxr_active_profiles a.validate() #CDN-000030 File "/home/www-data/web2py/applications/omniavx_cxn/controllers/tradeespresso.py", line 15, in validate site_maintenance_rec = db(db.site_maintenance.id > 0).select() #CDN-000299 File "/home/www-data/web2py/gluon/packages/dal/pydal/objects.py", line 1986, in select return adapter.select(self.query,fields,attributes) File "/home/www-data/web2py/gluon/packages/dal/pydal/adapters/base.py", line 1258, in select return self._select_aux(sql,fields,attributes) File "/home/www-data/web2py/gluon/packages/dal/pydal/adapters/base.py", line 1215, in _select_aux self.execute(sql) File "/home/www-data/web2py/gluon/packages/dal/pydal/adapters/base.py", line 1350, in execute return self.log_execute(*a, **b) File "/home/www-data/web2py/gluon/packages/dal/pydal/adapters/base.py", line 1344, in log_execute ret = self.cursor.execute(command, *a[1:], **b) DatabaseError: SSL SYSCALL error: EOF detected

}

[Niphlod]

seems rather "famous". see https://github.com/psycopg/psycopg2/issues/263, https://devcenter.heroku.com/articles/postgres-logs-errors#pgerror-ssl-syscall-error-eof-detected,  https://bitbucket.org/zzzeek/sqlalchemy/issue/3021/ssl-eof-not-detected-as-disconnect-in .

I think (from a fast-read of the above) that the problem is that the connection is restarted in the middle of a transaction, and so the exception is raised. 

Not sure what web2py can do except maybe intercepting it return a more meaningful trace. 

The fact is, even if the traceback is not "cristal clear", the transaction is lost because the connection misbehaved. 

<offtopic>Given that an exception is raised, I **think** the connection is recycled "properly", but we'd need a reproducible test-case to see if everything works fine. If web2py tries to reuse that same connection for another transaction, there it would lie a subtle bug (that **should need** to be fixed on the adapter side)...I doubt that the newly-opened cursor on that connection would be usable

</offtopic> 

[Auden RovelleQuartz]

another VERY INTERMITTENT error I am getting

{

web2py Web Framework

Created by Massimo Di Pierro, Copyright 2007-2015

Version 2.11.2-stable+timestamp.2015.05.30.16.33.24

Database drivers available: sqlite3, imaplib, pymysql, pg8000

Traceback (most recent call last):

  File "/home/www-data/web2py/gluon/shell.py", line 261, in run

    execfile(startfile, _env)

  File "applications/trade_search_engine_cxn/cron/trade_search_engine.py", line 2600, in <module>

    general_vxr_expiration()

  File "applications/trade_search_engine_cxn/cron/trade_search_engine.py", line 1031, in general_vxr_expiration

    expiration_status = general_expiration_status()

  File "applications/trade_search_engine_cxn/cron/trade_search_engine.py", line 1022, in general_expiration_status

    exdates_ref_rec = db(db.exdates_ref.id > 0).select()

  File "/home/www-data/web2py/gluon/packages/dal/pydal/objects.py", line 1986, in select

    return adapter.select(self.query,fields,attributes)

  File "/home/www-data/web2py/gluon/packages/dal/pydal/adapters/base.py", line 1258, in select

    return self._select_aux(sql,fields,attributes)

  File "/home/www-data/web2py/gluon/packages/dal/pydal/adapters/base.py", line 1216, in _select_aux

    rows = self._fetchall()

  File "/home/www-data/web2py/gluon/packages/dal/pydal/adapters/base.py", line 1206, in _fetchall

    return self.cursor.fetchall()

  File "/home/www-data/web2py/gluon/contrib/pg8000/core.py", line 659, in fetchall

    return tuple(self)

  File "/home/www-data/web2py/gluon/contrib/pg8000/core.py", line 701, in __next__

    self._c.handle_messages(self)

  File "/home/www-data/web2py/gluon/contrib/pg8000/core.py", line 1767, in handle_messages

    code, data_len = ci_unpack(self._read(5))

error: unpack_from requires a buffer of at least 5 bytes

}

an interesting note: those intermittent errors never happened on earlier versions of web2py

would those errors be related in any way?

[Niphlod]

one is coming from pyscopg2, the other from pg8000 . By the looks of it, the last is trying to read 5 bytes that aren't there, so it's consistent with the previous analysis of a "flaky" connection to the database

[Dan Hett]

I read through a few of these threads. If it is indeed a connection issue, how do I test that within Web2Py?
I switched the DB to MySQL to see if that would make a difference and received the same error.
It seems to create the error after the 5th table creation. It doesn't seem to matter what table I create next, I receive the same error.
I'm running from source. I will try running from the install version. FYI, I'm running on Windows.

[Niphlod]

On Friday, June 5, 2015 at 6:26:00 AM UTC+2, Dan Hett wrote:

I read through a few of these threads. If it is indeed a connection issue, how do I test that within Web2Py?
I switched the DB to MySQL to see if that would make a difference and received the same error.
It seems to create the error after the 5th table creation. It doesn't seem to matter what table I create next, I receive the same error.
I'm running from source. I will try running from the install version. FYI, I'm running on Windows.

let's be serious for a second...you can't get the same exception from a different adapter!