[Twisted-Python] The Trial of the DirtyReactorError

[glyph at divmod.com]

On 04:53 pm, matt at zgroupplc.com wrote:
>I understand why this is occurring, its a simple matter of calling 
>tcp.Port.stopListening() to suppress the error. However, I am more 
>concerned with learning about where the most appropriate place to run 
>this routine would be. I am not happy about running it in the unit 
>test as it doesn't solve the problem, it just suppresses it.

Putting the stopListening call into the middle of the actual test method 
would definitely be wrong.

However, putting the listenTCP in the setUp and the stopListening in the 
tearDown would be entirely appropriate.  If the code under test 
dynamically calls stopListening and might fail before then, then a 
tearDown by itself might be appropriate.
>I can't  seem to find an easy way to stop a port from listening from 
>within a  ServerFactory. Should I be writing a class that wraps the 
>ServerFactory to run tcp.Port.stopListening() at the appropriate time?

This is, in part, a weakness of the IProtocolFactory interface.  Calls 
to doStart and doStop should really receive an IListeningPort argument.

However, this is a minor wart.  listenTCP returns the Port, and hooking 
this up to your server factory in application code should be easy 
enough.
>Please bear in mind that I am creating multiple 'one-shot' servers 
>that are always shut down as soon as they have done their business. I 
>am guessing that the stopService methods would be more appropriate  for 
>a conventional server that serves multiple clients / requests.

If they are "always shut down", what event currently shuts them down? 
Have your test trigger that event.  If they're one-shot, then perhaps 
the method that calls listenTCP should be on the factory itself, making 
it even easier to keep track of the Port instance it is associated with.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20070412/1906a032/attachment.html>