Hi Sven,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">---<br>
Name: Zinc-HTTP-SvenVanCaekenberghe.248<br>
Author: SvenVanCaekenberghe<br>
Time: 4 March 2012, 8:25:19 pm<br>
UUID: aaab5645-ed48-4174-bdb5-53037fb297db<br>
Ancestors: Zinc-HTTP-SvenVanCaekenberghe.247<br>
<br>
Switched ZnServer class>>#defaultServerClass to ZnManagingMultiThreadedServer;<br>
[…]<br>
---<br>
<br>
ZnManagingMultiThreadedServer differs from its superclass ZnMultiThreadedServer in that it keeps explicit track of each (kept-alive) client connection. Tracking open client connections is important to correctly handle the case where people save an image with a running server. Before, that sometimes resulted in crashes of all kinds because even though the server (socket) itself came back up correctly, it happened that client worker process kept reading or writing to (now) stale socket streams. Now, when the server shuts down (#stop's) it closes all client connections explicitly.<br>
</blockquote><div><br></div><div>Currently the 3.0.7 one-click and developer images use ZnMultiThreadedServer rather than ZnManagingMultiThreadedServer and ConfigurationOfSeaside30 loads the stable configuration of Zinc which doesn't incorporate the change to #defaultServerClass to move from ZnMultiThreadedServer to ZnManagingMultiThreadedServer. </div>
<div><br></div><div>From your description above it sounds as though images uses ZnMultiThreadedServer could experience crashes. Is is worth updating the #stable version in ConfigurationOfZincHTTPComponents and the 3.0.7 one-click and developer images as Zinc is now used as the default server adaptor?</div>
<div><br></div><div>Cheers</div><div><br></div><div>Nick</div></div>