Hi Nicolas, Yes I've been using Tora's redirect until now but as I suppose it just sets an function to be executed for those neko.Lib.print & neko.Lib.printLn methods, where in multi-threaded env. if those print methods are invoked -> the redirect won't work as expected.
See in uberTora implementation I've switched the overall logic to that every module has only one API instance passed to it, so there isn't need to create additional module instances when the api is in use. To overcome the above problem in multi-threaded fashion this morning I've extended the internal logics of the neko/tora api with one more - uberTora api capable to redirect requests directly to the module without the need of print redirection (see the latest commit in uberTora git repository). The aggregation of the uberTora api is placed here: http://github.com/outbounder/org.abn.haxe/tree/master/src/org/abn/uberTora/ and a simple web application running under uberTora for example reference is this: http://github.com/outbounder/org.abn.botmanager Where if you check http://github.com/outbounder/org.abn.botmanager/blob/master/src/org/abn/botManager/Main.hx , you'll get the idea of what I'm talking about -> org.abn.botManager.operation.Start is the implementation which when invoked by the standard Tora way is registering UberTora request redirect handler listed in Main.hx, which on its side is simple http request -> response operation handler, but does not uses neko.Lib.print because of the fact that other threads at the same time may use it from other modules. UberTora has the ability to contain more than one web application running with the above implementation and logic flow. There is no need for the web app implementation to maintain and create Threads because of the fact that uberTora handles them and just redirects the client requests in thread-safe way - isolating the client request's data per every redirect, so the server can handle/serve other request->responses at the same time. Another question from all the above is "why the performance stays the same" when benchmarked with 200 concurrent requests. To which the only answer I suppose is because of the neko -> mySQL concurrent connections and data retrieval (all those 200 requests are 200 queries to the database indeed). Kind regards, Boris PS. Also because SPOD's Manager is static implemented and I've needed to have sometimes two or more connections to different databases I've implemented one light replacement of that : http://github.com/outbounder/org.abn.haxe/tree/master/src/org/abn/neko/database/mysql/ :) > Date: Tue, 19 Jan 2010 22:17:03 +0100 > From: Nicolas Cannasse <[email protected]> > Subject: Re: [Neko] uberTora - redirect api.print > To: Neko intermediate language mailing list > <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Obi a écrit : >> Hi again :) >> >> While I've been revising the code base for optimizations one question >> came to me: >> Is it possible to pass f.api.print function redirects per client >> (meaning that Lib.print & Lib.printLn methods to be redirected to the >> according client print handler per every thread/client request)? >> >> Such possibility will also greatly improve the performance because at >> the moment uberTora working threads lock until the main cached >> function handler (web.cacheModule) is executed. > > Each thread/VM has its own customizable printer method. See "redirect" > in Tora.hx > > Nicolas -- Neko : One VM to run them all (http://nekovm.org)
