[ZCM] [ZC] 1104/ 8 Comment "testSetupServers fails on Windows"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #1104 Update (Comment) "testSetupServers fails on Windows"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://zope.org/Collectors/Zope/1104

==============================================================
= Comment - Entry #8 by tim_one on Oct 31, 2003 3:55 pm

Yikes!  What a mess this one is turning into.

Despite what the log file says, the actual (hostname, port) addresses the FTP and HTTP servers bind to are identical.  That normally raises an "address already in use" exception on Windows, and, if it did, this test would pass.

However, other code here mucks around setting the SO_REUSEADDR socket option, and then Windows *doesn't* complain about the double bind.  Linux still complains about it.  Searching the web reveals that other Unix flavors may or may not still complain about it, depending on other phase-of-the-moon conditions, although Linux may be unique in always complaining about it.

Best summary I found:

<http://lists.spread.org/pipermail/spread-users/2001-September/000354.html>

I don't know why we use SO_REUSEADDR, but the evidence suggests it's a x-platform nightmare.
________________________________________
= Comment - Entry #7 by tim_one on Oct 31, 2003 2:04 pm

OK, this has morphed into a very different bug.  We don't get a ConfigurationError on Windows in this test because the HTTP and FTP servers have different ideas about what the hostname is, which saves them from getting an "address already in use" error from socket.bind despite that the same port number gets used in both cases.  Here from the end of a log while running this test:

 2003-10-31T13:40:25 INFO(0) ZServer HTTP server started at Fri Oct 31 13:40:25 2003
 	Hostname: pcpnnnnnnpcs.reston01.va.comcast.net
 	Port: 18092
 ------
 2003-10-31T13:40:25 INFO(0) ZServer FTP server  started at Fri Oct 31 13:40:25 2003
	Hostname: cjnnnn-b
 	Port: 18092

So the HTTP and FTP factories must be using different code to derive their ideas of what the hostname is.
________________________________________
= Comment - Entry #6 by fdrake on Oct 31, 2003 12:03 pm

The tests are now working for me on the Zope 2 head.
Running the Zope 2.7 branch tests now.
________________________________________
= Comment - Entry #5 by tim_one on Oct 31, 2003 11:52 am

OK, with your patches in place, this part of the test simply doesn't raise ConfigurationError on Windows.  I'm not clear on why it *should* raise ConfigurationError.  Does it still raise ConfigurationError on Linux?
________________________________________
= Comment - Entry #4 by tim_one on Oct 31, 2003 11:38 am

The bit about ConfigurationError was a red herring:  assertRaises() failures are darned hard to interpret correctly.

What actually happened when I removed the "# conflict" comment is starter.setupServers() didn't raise any exception, so assertRaises() was complaining that it *wanted* to see a ConfigurationError.

BTW, I don't think you've checked your changes in on Zope-2_7-branch, which is where I'm running the test (see "Version info:" above).

________________________________________
= Comment - Entry #3 by fdrake on Oct 31, 2003 11:31 am

The syntax of the configuration data in that test is bogus;
the intent was that "# conflict" be a comment, but comments
must be on lines by themselves.

I've fixed that and made ZConfig stricter about what it
considers a valid hostname; the later fix would have
caused the syntax error to be identified earlier regardless
of platform.

Still looking into the rest.
________________________________________
= Assign - Entry #2 by tim_one on Oct 31, 2003 10:50 am

 Status: Pending => Accepted

 Supporters added: fdrake

Noting that if I change the line

               address 18092 # conflict

to

               address 18092

in the test (removing the "# conflict" comment), the test fails in a very different way:

 FAIL: testSetupServers (Zope.Startup.tests.testStarter.ZopeStarterTestCase)
 ---------------------------------------------------------------------
 Traceback (most recent call last):
   File "C:\Code\Zope-2_7-branch\lib/python\Zope\Startup\tests\testStarter.py", line 194, in testSetupServers
   self.assertRaisesZConfig.ConfigurationError, starter.setupServers)
   File "C:\PYTHON23\lib\unittest.py", line 295, in failUnlessRaises
    raise self.failureException, excName
AssertionError: ConfigurationError

So it looks (a) the comment isn't getting stripped out on Windows; and, (b) ConfigurationError isn't a subclass of ZConfig.ConfigurationError on Windows.

Assigning Fred cuz I bet he's less lost than me.
________________________________________
= Request - Entry #1 by tim_one on Oct 31, 2003 10:42 am

testSetupServers has been failing for a long time on Windows, whether I run it, or whether from ChrisW's automated test runner reports.  It doesn't fail on Linux.

 ERROR: testSetupServers (Zope.Startup.tests.testStarter.ZopeStarterTestCase)
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "C:\Code\Zope-2_7-branch\lib/python\Zope\Startup\tests\testStarter.py", line 194, in testSetupServers
     self.assertRaises(ZConfig.ConfigurationError, starter.setupServers)
   File "C:\PYTHON23\lib\unittest.py", line 289, in failUnlessRaises
     callableObj(*args, **kwargs)
   File "C:\Code\Zope-2_7-branch\lib/python\Zope\Startup\__init__.py", line 187, in setupServers
     servers.append(server.create())
   File "C:\Code\Zope-2_7-branch\lib/python\ZServer\datatypes.py", line 93, in create
     logger_object=access_logger)
   File "C:\Code\Zope-2_7-branch\lib/python\ZServer\FTPServer.py", line 600, in __init__
     ftp_server.__init__(self, None, *args, **kw)
   File "C:\Code\Zope-2_7-branch\lib/python\ZServer\medusa\ftp_server.py", line 727, in __init__
     self.bind ((self.ip, self.port))
   File "C:\PYTHON23\lib\asyncore.py", line 300, in bind
     return self.socket.bind(addr)
   File "<string>", line 1, in bind
 TypeError: an integer is required

The second half of testSetupServers() appears to be setting up an error case, but it's not dying in the way the test expects.  Instead

   self.ip == '18092 # conflict'

and

   self.port == None

at the time of the failure, and socket.bind has no idea what to make of that.  socket.bind raises TypeError, which is sensible given those nonsense arguments.

The test is expecting ZConfig.ConfigurationError instead.
==============================================================