[Pharo-dev] Stopping Zinc

Sebastian Sastre sebastian at flowingconcept.com
Thu Nov 28 11:13:10 EST 2013


sure..

Of course the inconvenience is not in saving the image with processes hanging around but in opening it in an unusable state 

Building fresh ones for production is great but for development is too impractical

=/





On Nov 28, 2013, at 12:27 PM, Sven Van Caekenberghe <sven at stfx.eu> wrote:

> Hi Sebastian,
> 
> CC-ing to the mailing list because this is generally useful.
> 
> On 28 Nov 2013, at 14:11, Sebastian Sastre <sebastian at flowingconcept.com> 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/
> 





More information about the Pharo-dev mailing list