I've just find out that closing chrome before stopping Zinc leaves everything clean.
The funny thing is that Zinc is closing the sockets on stop.. I mean, if they are properly killed, one wouldn't expect them to cause the hold of any thread even if web browser tries to keep open connections. mmm On Nov 28, 2013, at 3:54 PM, Sven Van Caekenberghe <[email protected]> wrote: > > 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/ >>>>> >>>> >>>> >>> >>> >> > >
