[Pharo-dev] Stopping Zinc

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


This is how I start Zinc

(ZnServer startDefaultOn: self port)
		delegate: self makeDispatcher;
		register;
		yourself

and that screenshot was taken after 
1. starting Zinc
2. using a little the app (which has a custom dispatcher that has a couple of handlers, one is a websocket handler)
3. stopping with the code you see in the workspace
4. also this: 5 timesRepeat:[Smalltalk garbageCollect].

so I typically have to go manually to cmd-t those processes hanging there


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

> 
> On 28 Nov 2013, at 17:13, Sebastian Sastre <sebastian at flowingconcept.com> wrote:
> 
>> 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
>> 
>> =/
> 
> If your server is managed (by being the default one, or being registered explicitly) it will be stopped on image save and started again when the image comes up. If that should fail, please try to give a repeatable bug report, using a standard image only.
> 
> Alternatively, stopping the servers manually should work as well. If that should fail, that is a bug too.
> 
> What platform are you on, what Pharo version, latest Zinc ?
> 
>> 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/
>>> 
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131128/24e2d6da/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2013-11-28 at 2.29.31 PM.png
Type: image/png
Size: 283614 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131128/24e2d6da/attachment.png>


More information about the Pharo-dev mailing list