OpenNERO does not release ports on error-triggered exit.

[GoogleCodeExporter]

- I just changed the file NERO/data/shapes/characters/FirstPersonAgent.xml the 
attach_point from 0 0 30 to 0 0 40. 
- The big black spot disappeared,but now when I try to run OpenNero/Nero, many 
times, now I have prompt: "ScriptServer: port 8888 busy, waiting (10 more 
attempts) ..."
- If it doesn't succeed in 10 attempts, error appear and dialog box doesn't 
appear.
   """
   2011-Nov-30 22:36:44.935929 (!) [scripting] error executing script: NERO/main.py
   2011-Nov-30 22:36:44.940031 (M) [python] Traceback (most recent call last):
  File "NERO/main.py", line 11, in <module>
    script_server = common.menu_utils.GetScriptServer()
  File "/v/filer4b/v38q001/sungjin/cs343/OpenNERO-2011-11-30-x86_64/common/menu_utils.py", line 97, in GetScriptServer
    theServer = ScriptServer(port)
  File "/v/filer4b/v38q001/sungjin/cs343/OpenNERO-2011-11-30-x86_64/common/menu_utils.py", line 46, in __init__
    self.server.bind((HOST, port))
  File "<string>", line 1, in bind
  """

- If I try many times, I could get it to work a few times, and I could proceed.

Original issue reported on code.google.com by sungjin0...@gmail.com on 1 Dec 2011 at 4:46

[GoogleCodeExporter]

My partner had same problem without fixing 0 0 30, so I guess that's not what's 
it's causing this error.

Original comment by sungjin0...@gmail.com on 1 Dec 2011 at 4:51

[GoogleCodeExporter]

this happens if the python process running the menu is still running when you 
restart opennero.

try to find it and kill it:

ps aux | grep YOUR_USER_NAME | grep python

if you see something that looks like python NERO/menu.py, note the process 
number at the beginning of that line, and then call kill PROCESS_NUMBER.

On windows and Mac, you can do this with Task Manager and Activity Monitor 
respectively.

Original comment by ikarpov on 1 Dec 2011 at 12:24

[GoogleCodeExporter]

Here is also a very good response from another student:

This doesn't have anything to do with the change you made. OpenNero 
communicates with the control window through a port, and if it does not get a 
chance to free the port when it shuts down, when it starts up again, it won't 
be able to acquire the same port (because the OS still has it allocated). 

It will work again eventually because the OS will eventually perceive that the 
process which has that port allocated is now gone, but it takes a while 
sometimes. You should always close OpenNero by hitting Esc to take you back to 
the main window and then hitting the Exit button, instead of just hitting the 
OS "close" button in the window border. In case you forget and the port gets 
tied up, shutting down and restarting the machine will certainly free it. If 
you're in the lab, you can just hop over to another machine for a little while.

For completeness, the relevant port is 8888. What I usually do is just change 
the code so that it uses another port for a while. You have to change both 
common/menu.py and NERO/menu_utils.py (that's from memory; sorry if he file 
names are wrong). Just change the port number in both places to 8889 or 
something.

Original comment by ikarpov on 1 Dec 2011 at 12:26

[GoogleCodeExporter]

Original comment by ikarpov on 8 Dec 2011 at 2:44

• Changed title: OpenNERO does not release ports on error-triggered exit.
• Changed state: Accepted

[GoogleCodeExporter]

Another approach to this issue is to just use the SO_REUSEADDR ( 
http://www.unixguide.net/network/socketfaq/4.5.shtml ) socket option to allow 
binding again to the socket left in TIME_WAIT state. I have a attached a small 
patch that does just that. 

Small caveat: If there is an OpenNERO training session running and you open a 
second one without closing the first, things can get messy (as in, one of them 
won't work) as there is no single-instance check or an easy way to change ports 
to run two sessions at the same time. 

Original comment by cafede...@gmail.com on 12 Dec 2011 at 12:05

Attachments:

• socket_reuseaddr.patch

[GoogleCodeExporter]

Note: The problem with two sessions I mentioned is only relevant in Windows 
AFAIK, as in Windows SO_REUSEADDR can steal sockets that are not in TIME_WAIT 
unless they were bound using SO_EXCLUSIVEADDRUSE.

Original comment by cafede...@gmail.com on 12 Dec 2011 at 12:09

[GoogleCodeExporter]

Looks good, applying patch. Should be in the next binary release if it checks 
out.

Original comment by ikarpov on 1 Sep 2013 at 7:06

• Changed state: Started
• Added labels: Performance

[GoogleCodeExporter]

Fixed with latest trunk commit.

Original comment by ikarpov on 12 Sep 2013 at 1:58

• Changed state: Fixed