Hello, Just a follow up in case someone hits the mailing list archive looking for info related to this issue, this change seems to fix the problem:
https://review.openstack.org/#/c/57019/ "When concurrent PUT requests come in for an account or container, the resulting DB access will try to lock the DB for writing. Normal access will retry when it encounters a locked DB, change 0fdad0d9 introduced a cursor for doing the initialization which did not have the retry capability, resulting in a hard failure." It's related to this bug report: https://bugs.launchpad.net/swift/+bug/1243973 Regards, Juan On 14/11/13 17:09, Pete Zaitcev wrote: > On Thu, 14 Nov 2013 14:18:37 +0000 > "Juan J. Martinez" <[email protected]> wrote: > >> I've managed to isolate the change that introduced the problem: >> >> https://github.com/openstack/swift/commit/0fdad0d9d9e68b00f61171bb2a0dfd840ef5345f >> >> As this change is just for PyPy support I've reverted it and the problem >> is gone. >> >> Unfortunately I can't really explain why. >> >> According to sqlite3 docs [1], *execute* method in the connection is >> creating a cursor, but it looks like the cursor created explicitly is >> doing something differently (at least in Python 2.6 running on Squeeze), >> because I got rid of the OperationalError (database is locked) errors. > > Interesting. I don't have a clue either. Peter is going to poke Alex > about this, but ultimately we have to figure it out. > > -- Pete > -- Juan J. Martinez Software Developer, MEMSET mail: [email protected] web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey GU6 8TB, UK. _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
