I would think you have a few options here. #1. Sounds overall the problem is with apache, not the application itself. Even in older 1.3 apache, there are configuration parameters you can set to provide a limit to the maximum number of children spawned. However, the source of the problem is the fact that there are so many being spawned already. Maybe check the apache logs and see if you are either getting a much higher volume of valid requests coming in then your customer had before, or you are just getting hammered by some kind of low end denial of service attack or even dumb things like google/webcrawlers?
#1A. One option would be to move to a more traditional multi tier architecture - basically move the apache server over to a FreeBSD or Linux box, with Apache 2.2.x and the WebObjects adaptor included. Nice thing about this is that it is generally a more robust solution anyway, and also helps you separate out where the problems are. The above is presuming the web server and the WebObjects application are both being run on the same server. #2 In regards to the code base itself, you said you had an older Mac around. If you can install 10.4 on that, along with the appropriate xCode developer toolset that still had WebObjects support, you should do that and ensure you can open the project up. You then have basic verification that the project files you received are fit and sound. From there, you can use some older scripts (I have local copies around somewhere) that help convert WebObjects apps from xCode to Eclipse and after that, once you are up and running in a modern Eclipse based development environment for WebObjects you can move forward in that way. I would recommend that you suggest to your client that you do this as part of helping them out no matter what. I just started on a contract a few months ago where nobody made the jump to Eclipse and were using vi/vim for editing, etc and were freaked out about inability to be able to maintain their existing code base. For the above, on that 10.4 install + xCode, you will also need to install the additional WebObjects stuff from the Developer package since it does not install by default. The above is not a 100% guaranteed solution, just some pointers - my 2-cents as it were. - Mike On Jun 16, 2011, at 3:14 PM, P Teeson wrote: > The overseas organisation that contacted me is having a problem with their WO > app. > It is running on a Dual 500 MHz PPC G4 with 1GB RAM and running Tiger Server > 10.4.11. > The backend DB is under Oracle on a Sun server. > > The current problem is that the httpd root task gets into a situation where > it keeps spawning www tasks. > It initially starts of with 5 of them. At some point in time there are a > multitude of them and > the system slows down to the point of having to be re-booted. > > I have now received the source code for the WO app. It turns out to be an > Xcode project. > My present environment is Snow Leopard 10.6.7 and Xcode 3.2.6 on an Intel Mac > Pro (2009 Nehalem 2xQuad Core) etc. > > Leopard was last the OS X version where Apple provided WO support. I do have > Leopard 10.5.8 as a bootable partition. > Also Xcode is installed and I can install whatever WO stuff is needed from > the dvd. I have also DL'd WO 5.4.3 but not installed it yet. > > I also have available a G4 PPC 867MHz machine which I can setup as a web > server if this is needed. > (It runs Tiger 10.4.11 but not Server version. Server is available to me and > I can setup a separate partition as a test environment) > > Browsing around in the Xcode project I see a folder named GCRI.eomodeld > containing a lot of .fspec and .plist files. > Then a whole bunch of other folders containing .java source files. > And a folder named Web Components containing other folders in which are .api, > .wo, .html, .wod, and .woo files. > > Finally there is a single target named GCRI made up of two sub targets named > Application Server and Web Server > > Please advise me as to the best debugging path to follow to diagnose the > spawning issue. > > Thanks for your advice and > > respect.... > > Peter _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40deman.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
