Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am not sure I understand correctly: does the error occur on the client or server side (assuming they are both written in Pharo using Zinc HTTP Components).
First Pharo server side, and afterwards of course the clients complain that they cannot connect to the server. Everything is Pharo. And running perhaps a bit too close to the machine capacity. At least memory wise
Because 'CreateThread() failed (1450) - Insufficient system resources exist to complete the requested service' does not sound like a Pharo error.
Itâs a vm error I suppose. Opening the output console
In any case, ZnEasy class>>#get: uses #beOneShot so that the client side connection is closed after 1 request, it also uses the Connection:close header so that the server knows it does not have to keep the connection open.
Ok. Do I understand correctly that the server does not forcibly releases the connection and thread after a timeout, but continues waiting?
Server side, Zn should also clean up nicely (even for dirty requests). But is also depends on what you do inside your server side request handler. Maybe something prevents normal GC to clean up ?
That is lightweight, telling the clients which tests to run and collecting the results
Although Pharo processes are like green threads (not OS threads) you can technically use too many. Typically you will run out of sockets for IO. Unless you have a a real leak, it might be a GC configuration problem: a little used server might not invoke enough real/full GC cycles.
So when running out of sockets, no GC is triggered?
In any case, I have many images with long running HTTP servers and clients and I don't have any issues. How many requests are we talking about, how many concurrent users, how long before things go wrong ?
I havenât instrumented it yet, but after several hours. And the machine is pushed to its limits. Stephan