[Twisted-Python] Another brown paper bug release.
I just put out 0.8.7, a bugfix release for .6, which was leaking resources until the webserver crashed, for a second time (while the release was on freshmeat's front page :-\). There are still a number of known problems, which continue to baffle me: twisted.protocols.http is buggy, especially _parse_command. I don't know why, yet: it *looks* right... There regular tracebacks in /var/www/twistd.log, and I'm pretty sure it's not because of a proliferation of buggy HTTP clients. These didn't appear before. POST doesn't work if you're in germany. Nobody can see this problem except for Jürgen, and then only to twistedmatrix.com; however, I think that it's a real bug. I am vaguely suspicious that this has something to do with protocols.basic.LineReceiver prematurely closing the process's connection, but I have absolutely *no* idea why. CGIs work flawlessly for me, both GET and POST, and I've constructed some pretty pathological tests. This whole incident indicates the need for a better testing procedure; now that people actually rely on twistedmatrix.com to do stuff, I think that the release process should take a few days in order to ensure that *all* aspects of the code are tested. Proposals for something more formal will be gladly accepted :) -- ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
I think one good real-world test would be to actually run the frozen code on twistedmatrix.com for a day before releasing. This would of course only be a supplement to other harder tests, but as this incident shows, it would be a useful one. On Tue, May 08, 2001 at 06:52:41PM -0500, Glyph Lefkowitz wrote:
This whole incident indicates the need for a better testing procedure; now that people actually rely on twistedmatrix.com to do stuff, I think that the release process should take a few days in order to ensure that *all* aspects of the code are tested. Proposals for something more formal will be gladly accepted :)
-- Chris Armstrong carmstro@twistedmatrix.com http://twistedmatrix.com/~carmstro
On Tue, 8 May 2001, Glyph Lefkowitz
This whole incident indicates the need for a better testing procedure; now that people actually rely on twistedmatrix.com to do stuff, I think that the release process should take a few days in order to ensure that *all* aspects of the code are tested. Proposals for something more formal will be gladly accepted :)
Random note: web.Resource and friends and web.Request do not rely on an internet connection: they rely on a handler which has a .server with some properties and some other attributes. Creating such a handler is no problem if we start from FileWrapper, add attributes, and create a server and attach it to the handler ourselves. So any *recorded and analysed* bug should be able to quickly become a test case. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
On Wednesday 09 May 2001 00:19, you wrote:
Random note: web.Resource and friends and web.Request do not rely on an internet connection: they rely on a handler which has a .server with some properties and some other attributes. Creating such a handler is no problem if we start from FileWrapper, add attributes, and create a server and attach it to the handler ourselves.
So any *recorded and analysed* bug should be able to quickly become a test case.
While this is true in theory, there are many practical concerns that can't be simulated by an automatic test case; the one outstanding bug is one of these. Since twisted.web relies on external processes -- for server distribution, for CGI scripts -- race conditions may arise that are impossible to unit test. So, we need some functional testing as well, to make sure that those sorts of conditions don't arise. If anyone else can think of a way to get fork() into a unit test, I'd like to hear about it :). But, even more than that, I am frequently surprised when I try to run "working" code on Windows or Jython and have it crash due to some undocumented incompatibility (or even a documented one that I just haven't read about). I'm a big proponent of automated testing, though, so I'd love to be wrong. -- ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
participants (3)
-
Chris Armstrong -
Glyph Lefkowitz -
Moshe Zadka