I am trying to integrate NFC Chat with another Web application under Tomcat4. The intent is to eventually use httpTunneling only.
The problem comes when the Web application context is recycled. The Tunnel servlet attempts to create a new instance of a ChatServer, which attempts to bind to the socket /port that is owned by the previous run of the WebApp. Obviously this fails with a socket bind exception.
I need to be able to cleanly and completely shut down the running chat server when the WebApp shuts down. This does not seem to be happening. All the destroy method in the Tunnel servlet does is to stop the thread running in the ChatServer.acceptConnections(). It also needs to force the ChatServer to stop it's internal threads and release the resources it has allocated (the socket in particular).
I plan to implement/extend a method in the ChatServer to do this, the obvious place is pleaseStop(). In there I will close the _serverSocket, and stop the _displatcherThread, the _vultureThread, and the _distributorThread. I would also like to close all the client connections, but haven't looked into how I will do this yet.
I would suggest a call to this updated pleaseStop() should also be placed the ChatServer finalize() method as well.
Does anybody have any suggestions about things I that I should watch out for or hints on the best way to intgrate this with the rest of the code base?
Sounds fine to me, except that if there's a way to avoid restarting the server like that, you'd definitely be better off. I don't know anything about tomcat, so I'll take your word that there isn't...
I looked into that as well, but the only way to do that is by changing ChatServer into a singleton object with private constructors. With the amount of places ChatServer is created from, it seemed a clean shutdown was less likely to break other code.
The essence of the problem is that the current design looks like ChatServer should be a singleton (single config file), but it isn't.
The init method in the TunnelServlet will create a new instance each time it is called, which will happen each time the Webapp is stopped and restarted. This causes a conflict with the resources the ChatServer requires (server port among other things).