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/ >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > >
