On 6/11/15 9:32 PM, Eugene Nikanorov wrote:
Hi neutrons,
I'd like to draw your attention to an issue discovered by rally gate job:
http://logs.openstack.org/96/190796/4/check/gate-rally-dsvm-neutron-rally/7a18e43/logs/screen-q-svc.txt.gz?level=TRACE
I don't have bandwidth to take a deep look at it, but first impression
is that it is some issue with nested transaction support either on
sqlalchemy or pymysql side.
Also, besides errors with nested transactions, there are a lot of Lock
wait timeouts.
I think it makes sense to start with reverting the patch that moves to
pymysql.
My immediate reaction is that this is perhaps a concurrency-related
issue; because PyMySQL is pure python and allows for full blown eventlet
monkeypatching, I wonder if somehow the same PyMySQL connection is being
used in multiple contexts. E.g. one greenlet starts up a savepoint,
using identifier "_3" which is based on a counter that is local to the
SQLAlchemy Connection, but then another greenlet shares that PyMySQL
connection somehow with another SQLAlchemy Connection that uses the same
identifier.
I'm not saying this is a bug in PyMySQL or Eventlet necessarily, it
could be a bug in Neutron itself, since none of this code has ever been
used with a true context-switching greenlet environment at the database
connection level.
Thanks,
Eugene.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
