Public bug reported:
I've seen this error twice while running integration tests (of our own application) that access Mailman 3 using the API. The load on Mailman is very light, as all requests made to the API are serial, never in parallel. Of course the various processing queues in MM3 are separate processes and could be doing work concurrently.
The platform is Centos 6.
Traceback (most recent call last): File "/usr/lib64/python2.6/wsgiref/handlers.py", line 93, in run self.result = application(self.environ, self.start_response) File "/home/sgoss/mailman_clone/src/mailman/rest/wsgiapp.py", line 63, in __call__ config.db.commit() File "/home/sgoss/mailman_clone/src/mailman/database/stock.py", line 70, in commit self.store.commit() File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/store.py", line 122, in commit self._connection.commit() File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/databases/sqlite.py", line 126, in commit self.raw_execute("COMMIT", _end=True) File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/databases/sqlite.py", line 154, in raw_execute return Connection.raw_execute(self, statement, params) File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/database.py", line 321, in raw_execute self._check_disconnect(raw_cursor.execute, *args) File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/database.py", line 366, in _check_disconnect return function(*args, **kwargs) OperationalError: database is locked
The backend here is SQLite, which falls over very quickly under concurrent load. If the goal here is to create a stable mailing list server, maybe SQLite is a poor default.
** Affects: mailman Importance: Undecided Status: New
** Tags: mailman3