From: AndreasH71 <and...@te...> - 2013-05-03 08:16:36
|
Hi Klacke! This old issue was forgotten five years ago, but better late than never. We have been running an old version of Yaws (1.72) since 2008, with some custom made changes to make the soap server concurrent. A month ago we switched to 1.96 and implemented the changes in that code too. What is the process of adding changes to Yaws? I'm not that familiar with doing a 'proper patch', and would prefer to send the modified modules to someone in the know. In summary, the changes are: - 3 files for the concurrent soap server (yaws_soap_srv + 2 new files) - 3 files for adding a soap_workers gconf param. - 1 file for a bug fix in yaws_stats. Also, we've had an issue where we had to to encode soap data with utf-8 encoding, but I'm not sure how well that change will fit into Yaws? How do I proceed with this? Andreas Claes Wikstrom wrote: > > Andreas wrote: >> Before I try your suggestion, do you think this is a good idea? > > I CC the list - I think mor people are interested in my reply. > >> >> - The main soap server inits the web service, starts N worker >> processes and hand them the model, and exports a get_worker() function >> that returns the pid to an available worker process. When running out >> of free workers, another one is started. (With N=1 there is no need to >> configure this parameter). >> >> - The worker process is a modified yaws_soap_srv, just dealing with >> requests (and not doing any model init). >> >> - handler function (called by rpc) asks the main server for a pid, and >> sends a gen_server:call() to that pid. > > > Optimal solution is as follows. > > 1. Let the init/1 function craete a small nuber of workers, say 3. > > 2. Each worker is ready to receive similar messages as the gen_server > is today. > > 3. Whenever the top proc gets new models they are sent down to all > workers. The main idea here is that we want to avoid copying the > model data for each req. > > 4. A request comes in to the top proc, it selects a worker and sends > the req to the worker. > > 5. The worker does it's job and performs an explict reply through > gen_server:reply() It needs the full set of params received by the > top proc in handle_call() > > 6. Finally the worker notifies the top proc that it is ready to > receive new jobs. > > > If you do this - please make sure I get the result as either > a proper patch or optionally a copy of the new yaws_soap_srv.erl file > > > > /klacke > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > > -- View this message in context: http://old.nabble.com/Soap-server-not-concurrent-tp15804462p35360564.html Sent from the Yaws mailing list archive at Nabble.com. |