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
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/856004
Title:
"OperationalError: database is locked" encountered under very light
load while using REST API
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/856004/+subscriptions
Public bug reported:
Not sure what caused this error that showed up in mailman.log:
Aug 16 10:54:50 2011 (31400) Uncaught runner exception: u'foo.example.com'
Aug 16 10:54:50 2011 (31400) Traceback (most recent call last):
File "/home/sgoss/mailman_clone/src/mailman/core/runner.py", line 138, in _one_iteration
self._process_one_file(msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/core/runner.py", line 220, in _process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/runners/virgin.py", line 37, in _dispose
process(mlist, msg, msgdata, 'virgin')
File "/home/sgoss/mailman_clone/src/mailman/core/pipelines.py", line 50, in process
handler.process(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/pipeline/cook_headers.py", line 360, in process
process(mlist, msg, msgdata)
File "/home/sgoss/mailman_clone/src/mailman/pipeline/cook_headers.py", line 202, in process
listinfo = mlist.script_url('listinfo')
File "/home/sgoss/mailman_clone/src/mailman/model/mailinglist.py", line 243, in script_url
return urljoin(self.domain.base_url, target + '/' + self.fqdn_listname)
File "/home/sgoss/mailman_clone/src/mailman/model/mailinglist.py", line 227, in domain
return getUtility(IDomainManager)[self.mail_host]
File "/home/sgoss/mailman_clone/src/mailman/model/domain.py", line 142, in __getitem__
raise KeyError(email_host)
KeyError: u'foo.example.com'
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/827547
Title:
KeyError in "virgin" runner.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/827547/+subscriptions
Public bug reported:
This is not a real bug, I would just like to start a discussion about
what can be done to set up a continuos integration system.
Is there any Jenkins server which can be used?
Another thing which I was thinking is if we have some real tests on
real systems with various MTA such as Postfix/Exim.
I haven't tried it yet but it seems that http://vagrantup.com/ and
puppet could really be very nice tools for the job.
And we could then
1. fire up a VM
2. install the different MTAs
3. create some complicated mailing lists and check that everything works correctly
Other ideas?
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/956384
Title:
Continuous integration and real-world testing
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/956384/+subscriptions
Public bug reported:
The `requests` package <http://pypi.python.org/pypi/requests/0.11.1> was
all the rage at Pycon 2012. Seems like it could replace the use of
several similar packages like httplib2, urllib2, etc. For future
investigation.
** Affects: mailman
Importance: Low
Status: Triaged
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/975708
Title:
Switch to the `requests` package
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/975708/+subscriptions
Public bug reported:
At Pycon, we talked about the need for the core to potentially push data
to Postorius, HyperKitty, and other components. It makes much more
sense for the core to be capable of publishing events and data to a
messaging system like ZeroMQ, which those other components could
subscribe to. This is a placeholder for future investigation.
** Affects: mailman
Importance: Low
Status: Triaged
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/975707
Title:
Investigate something like ZeroMQ
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/975707/+subscriptions
Public bug reported:
At Pycon, it was observed that the topic system as it exists in mm2.1
isn't really all that useful. Terri had some thoughts about that in
regards to work that Systers did. This is mostly a placeholder for
future ideas and to get it out of my TODO list. :)
** Affects: mailman
Importance: Low
Status: Triaged
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/975705
Title:
Rip out or redesign the topic system
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/975705/+subscriptions
Public bug reported:
`bin/mailman create` has a -d option which says to create the domain of
the new mailing list's posting address if it doesn't already exist. At
Pycon it was observed that it was kind of silly to always have to
specify -d and that maybe it should be the default. The reason I didn't
do that was because of typos, which would be a bit of work to undo.
Maybe once we have list renaming exposed, this would be useful. But I'm
still not sure.
** Affects: mailman
Importance: Low
Status: Triaged
** Tags: easy mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/975703
Title:
-d should (maybe) be the default for `bin/mailman create`
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/975703/+subscriptions
Public bug reported:
Stephen observed that it might be useful to implement a pipeline of
handlers (even chain processing?) for other runners such as archive,
bounce, and command. This is probably not something for 3.0 final, thus
I'm marking it triaged,low. But it's an interesting idea and may lead
to other useful refactoring.
** Affects: mailman
Importance: Low
Status: Triaged
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/975702
Title:
Implement a pipeline in other runners
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/975702/+subscriptions
Public bug reported:
In Mailman 3, technically rules should not have side effects. The
'approved' rule breaks this because it removes the Approved header (and
other supported headers) from the message. There should instead be a
handler that does the header cleaning, and the rule should not do this.
>From an implementation standpoint, the same code can be used in both the
handler and in the rule. You can use a slightly different API wrapper
and use a flag to indicate whether the header should be removed or not.
OTOH, some clever refactoring might make better sense.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/973790
Title:
'approved' rule should not modify the message
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/973790/+subscriptions
Public bug reported:
At the simplest, it should support GET on a Message-ID or X-Message-ID-
Hash value and return the bytes of the stored message, or 404.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/967954
Title:
IMessageStore should be exposed as a top level REST resource
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/967954/+subscriptions