|
|
| Author |
Message |
|
| Guest |
 Posted: Mon Mar 03, 2008 1:58 pm |
 |
|
|
Guest
|
Hello.
Soap server in Yaws does not handle concurrent processes (request N+1
has to wait for request N to be finished). Non-concurrency doesn't
play well with the web services I'm developing, so I've made a fix of
my own in yaws_soap_srv. Does it break anything I'm not aware of?
My thought process is that the gen_server does only keeps track of the
started web services, and doesn't change the state after it is
started. Therefor, the actual processing need not be done within the
server, and the server is only used to return the server state to the
processing code. While returning the state is a non-concurrent
gen_server:call(), it is rather quick.
/Andreas Hellstr |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Mar 03, 2008 2:27 pm |
|
|
|
Guest
|
Andreas wrote:
> Hello.
>
> Soap server in Yaws does not handle concurrent processes (request N+1
> has to wait for request N to be finished). Non-concurrency doesn't
> play well with the web services I'm developing, so I've made a fix of
> my own in yaws_soap_srv. Does it break anything I'm not aware of?
>
> My thought process is that the gen_server does only keeps track of the
> started web services, and doesn't change the state after it is
> started. Therefor, the actual processing need not be done within the
> server, and the server is only used to return the server state to the
> processing code. While returning the state is a non-concurrent
> gen_server:call(), it is rather quick.
>
> /Andreas Hellstr |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Mar 03, 2008 7:18 pm |
|
|
|
Guest
|
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
Erlyaws-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/erlyaws-list
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
