On 29 Nov 2013, at 14:25, Sebastian Sastre <[email protected]> wrote:
> Did a test now and looks good. OK > But using closeAndDestroy: 0 when stopping the websocket handler collects > things a lot sooner It is called a graceful shutdown and is apparently the default for SocketStream>>#close since 2005. But I agree that it might make sense to think about doing it a lot faster ;-) Maybe we can rephrase the question: why is there such a long timeout there ? Anyone ? > thanks for the tip Sven! You’re welcome. > 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/ >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
