On 28 Nov 2013, at 17:35, Sebastian Sastre <[email protected]> wrote:
> This is how I start Zinc > > (ZnServer startDefaultOn: self port) > delegate: self makeDispatcher; > register; > yourself the #register is too much (the default server is registered automatically), the server will be added twice to #managedServers which leads to the same instance being stopped/started twice, which probably does no harm, but it should not be done. > and that screenshot was taken after > 1. starting Zinc OK, see remark above. > 2. using a little the app (which has a custom dispatcher that has a couple of > handlers, one is a websocket handler) There might of course be some error in your code ;-) A repeatable bug report requires no use of custom code. > 3. stopping with the code you see in the workspace If you start like you do above, just ZnServer stopDefault is enough. > 4. also this: 5 timesRepeat:[Smalltalk garbageCollect]. Yeah, that is a good idea, typically you should also wait at least the connection time out time (30s by default). > so I typically have to go manually to cmd-t those processes hanging there Please try to say #logToTranscript to your server, it will report many details of connections opening/closing, with a special tag to identify each thread. > <Screen Shot 2013-11-28 at 2.29.31 PM.png> I see you are on the latest Mac OS X 10.9, using #20625, this definitively should work. If I have time later tonight, I will try to run a similar scenario. Note that running the unit tests creates many, many servers and afterwards everything cleans up. > On Nov 28, 2013, at 2:21 PM, Sven Van Caekenberghe <[email protected]> wrote: > >> >> On 28 Nov 2013, at 17:13, Sebastian Sastre <[email protected]> >> 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 <[email protected]> wrote: >>> >>>> 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/ >>>> >>> >>> >> >> >
