Describe the bug
I experienced a weird problem recently. With a client for gama-server I try to regularly reconnect in case the connection is lost.
With gama GUI, I open the program, let the client connect then close it and reopen. Everytime at the opening of the socket for gama-server systematically crashes and I can read in the console that it had a Bind exception saying that the socket is already in use.
But if I do the same thing with gama headless I have no problem at all, the server is created without exception and the client can reconnect instantly.
Even weirder, if I start a gama GUI, let the client connect, then close it and try to open gama headless, I also have the same socket already in use exception.
To Reproduce
Steps to reproduce the behavior:
- open gama in gui mode
- connect a client to the server
- close and reopen gama
- see that the server is not working
Additional context
I don't know if the client part is important or not in this case, I didn't try without it yet.
I see two possible reason for that problem: either we use different classes and behaviours in gui and headless to manage the server and for some reason the one in GUI takes way longer to be "cleaned" by the OS, or we do manually some resource closing in headless mode that we do not do in GUI.
Describe the bug
I experienced a weird problem recently. With a client for gama-server I try to regularly reconnect in case the connection is lost.
With gama GUI, I open the program, let the client connect then close it and reopen. Everytime at the opening of the socket for gama-server systematically crashes and I can read in the console that it had a Bind exception saying that the socket is already in use.
But if I do the same thing with gama headless I have no problem at all, the server is created without exception and the client can reconnect instantly.
Even weirder, if I start a gama GUI, let the client connect, then close it and try to open gama headless, I also have the same socket already in use exception.
To Reproduce
Steps to reproduce the behavior:
Additional context
I don't know if the client part is important or not in this case, I didn't try without it yet.
I see two possible reason for that problem: either we use different classes and behaviours in gui and headless to manage the server and for some reason the one in GUI takes way longer to be "cleaned" by the OS, or we do manually some resource closing in headless mode that we do not do in GUI.