Re: Implementing a forking SOAP::Lite server

I noticed (while making my cpan:// links work :-) that there is a 'ForkOnAccept' module in the examples directory of the module, but I gave it a quick try and couldn't get it to work.

OK I got it to work.

It's obviously pretty raw, quite a few warnings while it is in use.

I'd still prefer Net::Server or similar for more control (ie to make sure the number of children is kept under control, or even better, pre-forking.

Any ideas very welcome :-)

Comment on Re: Implementing a forking SOAP::Lite server

Replies are listed 'Best First'.
Re^2: Implementing a forking SOAP::Lite server by mda2 (Hermit) on Nov 02, 2006 at 12:50 UTC
I have many systems with SOAP::Lite and prefer to use a standalone server (SOAP::Transport::(HTTP\|TCP) because Fork on accept is a very bad option when you have many calls. I´m prefer to use an single process with Listen is 10 or more, when one process is more quickly of ForkOnAccept! I think PreFork is a good solution, but only now (after some years) my database are upgrading to transaction mode! Pay attemption on timeouts on client side and a correct rollback actions (traped with SIGPIPE), or make an good "protocol" on client/server (Identify requests) if you need it. I don´t check Net::Server at now, but I think it´s a great solution, because I´m implementing Config, Log Facilities and requestor control by hand, and it´s very hard! I don't like the idea of installing a web server to solve a problem that might be solved with perl itself :-) I have an Config_Server and a Dist_Server with some Targets_Agents. At Config_Server I think are good point to use Apache&mod_perl, but never simultaneous without transaction database, for others perl solve all on *nix servers and MS plataform ;) -- Marco Antonio Rio-PM	[reply]

Replies are listed 'Best First'.

Re^2: Implementing a forking SOAP::Lite server
by mda2 (Hermit) on Nov 02, 2006 at 12:50 UTC

I think PreFork is a good solution, but only now (after some years) my database are upgrading to transaction mode!

Pay attemption on timeouts on client side and a correct rollback actions (traped with SIGPIPE), or make an good "protocol" on client/server (Identify requests) if you need it.

I don´t check Net::Server at now, but I think it´s a great solution, because I´m implementing Config, Log Facilities and requestor control by hand, and it´s very hard!

I don't like the idea of installing a web server to solve a problem that might be solved with perl itself :-)

--
Marco Antonio
Rio-PM

[reply]