Did a test now and looks good. But using closeAndDestroy: 0 when stopping the websocket handler collects things a lot sooner
thanks for the tip Sven! On Nov 29, 2013, at 10:37 AM, Sven Van Caekenberghe <[email protected]> wrote: > > On 29 Nov 2013, at 13:31, Sebastian Sastre <[email protected]> > wrote: > >> 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 > > Did you try waiting 20 or 30 seconds ? > > SocketStream>>#close ends up doing a Socket>>#closeAndDestroy: with argument > 30 seconds, while ZdcSocketStream>>#close ends up doing a > Socket>>#closeAndDestroy: with argument 20 seconds. Before that timeout, they > only close their end and are waiting for the other end to close. After the > timeout, there is a hard destroy. > >> 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/ >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > >
