<html><body>On 04:53 pm, matt@zgroupplc.com wrote:<br /><br />>I understand why this is occurring, its a simple matter of calling <br />>tcp.Port.stopListening() to suppress the error. However, I am more <br />>concerned with learning about where the most appropriate place to run  this <br />>routine would be. I am not happy about running it in the unit  test as it <br />>doesn't solve the problem, it just suppresses it.<br /><br />Putting the stopListening call into the middle of the actual test method would definitely be wrong.<br /><br />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.<br /><br />>I can't  seem to find an <br />>easy way to stop a port from listening from within a  ServerFactory. Should <br />>I be writing a class that wraps the  ServerFactory to run <br />>tcp.Port.stopListening() at the appropriate time?<br /><br />This is, in part, a weakness of the IProtocolFactory interface.  Calls to doStart and doStop should really receive an IListeningPort argument.<br /><br />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.<br /><br />>Please bear in mind that I am creating multiple 'one-shot' servers  that are <br />>always shut down as soon as they have done their business. I  am guessing <br />>that the stopService methods would be more appropriate  for a conventional <br />>server that serves multiple clients / requests.<br /><br />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.<br /></body></html>