Hi Sebastian, CC-ing to the mailing list because this is generally useful.
On 28 Nov 2013, at 14:11, Sebastian Sastre <[email protected]> wrote: > Hi Sven, > > how are you? all good over there? > > quick question: > > should this be enough to stop Zinc? > > ZnServer managedServers do:[:e| e stop]. > > ZnServer default ifNotNil:[ > ZnServer default delegate stop]. > > ZnServer stopDefault. > > I ask because after using it for a while the image still have processes > ZnManagingMultiThreadedServer related > > Do you have some kind of best practice to shut it down? > > sebastian > > o/ > > PS: The typical case is that you are developing and you make some changes and > want to save the image clean (without anything but the default processes) > > Now I'm manually terminating some after stopping all (using that code up > there) because if I don't do that I have ~50% chances to save an image that > will open absolutely frozen (forcing me to go back one commit and reload some > packages) Once you get started with Zinc there is no stopping it ;-) The default server (#startDefaultOn: and #defaultOn:) gets registered automatically. Registered servers get stopped on image shutdown and get restarted on image startup. There can only be one default server. Servers created otherwise (#on: #startOn:) do not get registered automatically. You have to do that explicitly using #register. Then they’ll get the behaviour described above. The default server class is ZnManagingMultiThreadedServer which will close its open connections when stopping. However, the HTTP worker processes (one per open connection) do not get terminated explicitly. This will happen when their main loop notices the connection is gone (by receiving an error, typically a ConnectionTimedOut or PrimitiveFailure on reading the next incoming request), after which they will clean up and terminate naturally. This is the theory, there are some platform differences (Mac, Windows, Linux). On Mac I never have trouble with managed server hanging in my development image, but YMMV. Now, my best practice advice for deployment is to use cleanly built images (very easy to do using the ZeroConf ‘config' handler that loads your Metacello Configuration) and then start your servers in your startup script (where you can do all other configurations, like setting ports, username/passwords, other hosts). Then use some monitoring tool like monit to check on the server(s) and kill/restart when needed. HTH, Sven PS: The following introduction article explains the deploy mechanism that I prefer (in simple terms): http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/
