On 29 Nov 2013, at 13:31, Sebastian Sastre <sebastian@flowingconcept.com> 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 <sven@stfx.eu> wrote:
On 28 Nov 2013, at 17:35, Sebastian Sastre <sebastian@flowingconcept.com> 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 <sven@stfx.eu> wrote:
On 28 Nov 2013, at 17:13, Sebastian Sastre <sebastian@flowingconcept.com> 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 <sven@stfx.eu> wrote:
Hi Sebastian,
CC-ing to the mailing list because this is generally useful.
On 28 Nov 2013, at 14:11, Sebastian Sastre <sebastian@flowingconcept.com> 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/