[web2py] Re: DatabaseError: SSL SYSCALL error: EOF detected (Intermitten
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! -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[web2py] Re: DatabaseError: SSL SYSCALL error: EOF detected (Intermitten
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. On Tuesday, 2 June 2015 18:33:25 UTC-5, Niphlod wrote: 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. offtopicGiven 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 -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[web2py] Re: DatabaseError: SSL SYSCALL error: EOF detected (Intermitten
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?
On Tuesday, June 2, 2015 at 6:33:25 PM UTC-5, Niphlod wrote:
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.
offtopicGiven 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
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
web2py-users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[web2py] Re: DatabaseError: SSL SYSCALL error: EOF detected (Intermitten
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 -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[web2py] Re: DatabaseError: SSL SYSCALL error: EOF detected (Intermitten
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. offtopicGiven 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 -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups web2py-users group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
