Hello Laurent,
Regarding Pharo Issue 4910, http://code.google.com/p/pharo/issues/detail?id=4910
Did you see my reply ?
Did you get any further ?
I would really like to solve this problem. I have described it before, but here
is what I think happens:
- you start the ZnZincServerAdaptor, which implies creating a listener socket
and process
- you test it to see if it is running by doing one or more requests
- this means that at least one connection and worker process are alive
- you save the image
- the server receives a shutdown and stops cleanly
- since this is a ZnMultiThreadedServer and not the experimental
ZnManagingMultiThreadedServer it leaves the connection and the worker process
alone
- you restart the image
- the server receives a startup and starts working
- the worker process is revived and will continue its blocking read for the
next request
- this signals a primitive failed and causes a hang/crash
Now, using the lastest Zn, the primitive failed should be caught and the
connection and worker should be cleaned up silently, unless there is also a VM
problem, but I don't think so.
(It would also be possible to make sure that no open connections are alive,
close the browser that you used, check the Process Monitor)
Another option is to use the experimental ZnManagingMultiThreadedServer which
does track its own connections and cleans them up, which should result in the
worker processes stopping cleanly.
The next code requires the very latest Zinc-Seaside adaptor, you could try:
ZnZincServerAdaptor new
port: 8080;
serverClass: ZnManagingMultiThreadedServer;
start;
yourself
Regards,
Sven
