On 02 Sep 2011, at 23:01, Lukas Renggli wrote: >> It would be better if this were prevented. I will have a look to see if I >> can keep track of these connections and worker processes in a weak data >> structure so that they can be managed better. > > Better no weak data structures. The listener process could more > efficiently cleanup unused workers, no?
Yeah, the idea of the weak data structure was to have a fallback to the current situation in case something went wrong when explicitely managing the connections. The current implementation now uses a normal ordered collection. It passes all tests. Note that this version of Zn is way further than what is in 1.3, it also contains a brand new client I am working on and some important code already uses this new client. This needs some more testing before it can be included I guess (although it works for me). I know the Seaside builds use the latest Zn. Igor, as far as I could see, I only got nice PrimitiveFailed's. Sven A new version of Zinc-HTTP was added to project Zinc HTTP Components: http://www.squeaksource.com/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenberghe.189.mcz ==================== Summary ==================== Name: Zinc-HTTP-SvenVanCaekenberghe.189 Author: SvenVanCaekenberghe Time: 4 September 2011, 3:20:15 pm UUID: b4f2d979-0097-4dc8-bde9-23edda15a3f9 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.188 Added some new internal functionality to ZnMultiThreadedServer: To keep track of all its open client connections (socket streams) (#socketStreamOn: and #closeSocketStream) so that they can all be force closed (#closeAllConnections) when the server stops (#stop). This is necessary because on image save the worker processes and socket streams are frozen and fail when they start up afterwards due to illegal socket handles. Note that #readRequestSafely: was extended and #writeResponseSafely:on: was introduced to handle several exceptions, most notably PrimitiveFailed, in the situation where a socket stream is force closed on a live process using that stream. This can be observed in #testTimeout. The timeouts on reading/writing socket streams take care of closing connections that are kept open too long. Maybe the server side timeouts should be even shorter to conserve resources.
