[Twisted-Python] The Trial of the DirtyReactorError
glyph at divmod.com
glyph at divmod.com
Thu Apr 12 14:56:06 EDT 2007
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
>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...
More information about the Twisted-Python