Hi Michael, I don’t know the future of mod_WebObjects. Last updates were two years ago but they were fairly significant, fixing a security exploit.
Thanks for mentioning MPM-event issues as I wasn’t aware until you mentioned them. Perhaps that is what we were experiencing. To give an update, we got stuck deploying to production environment last night and gave up but we kept looking into it and deployed mod_proxy today and preliminary reports show people are happy. We had missed the part about adding a header: x-webobjects-adaptor-version We had it in staging but overlooked it in production. So if you have a java instance running and direct-connect disabled, you can’t do something like this: curl localhost:9001/cgi-bin/WebObjects/app.woa If you do you’ll get a: (52) Empty reply from server So how would mod_proxy or mod_WebObjects connect to it then? Well they give that header I mentioned above. So you’d need to do this with curl: curl localhost:9001/cgi-bin/WebObjects/app.woa -H 'x-webobjects-adaptor-version: mod_proxy’ You need to have this line in your Apache config files: RequestHeader append x-webobjects-adaptor-version “mod_proxy" While we like this solution we aren’t quite where we want to be yet. Our app shows the instance number as “-1” no matter which app is responding. We know it’s doing round-robin but we don’t have the instance number in the request like WO expects it. Small stuff like that… but the stability and performance improvements are huge. So far so good :-) Thanks everyone, — Aaron > On Mar 8, 2024, at 9:15 AM, Michael Schmiedgen <schmied...@takwa.de> wrote: > > > On 3/8/2024 1:55 AM, Aaron Rosenzweig via Webobjects-dev wrote: >> Thank you Stefan, Johann, and the community for making the switch from >> mod_Webobjects.so adaptor to the built-in Apache mod_proxy module. >> It helped us out this week to dig up Stefan’s 2015 video presentation on >> this topic, utilize the ERXApplication cookie generation, and the migration >> tab in Java Monitor. >> The reason for us to make the switch was because Apache had become unstable. >> It was having numerous segmentation faults. We were using the latest >> available Apache 2.4.x for Amazon Linux along with freshly compiled from >> source WO Adaptor taken from latest WOnder repo. Whenever httpd wet-the-bed, >> we’d lose communication with an app instance. It seems there was no rhyme or >> reason to what was causing it to crash. It did seem that when we downloaded >> user files (passed from disk to web browser through fileInputStreams) that >> we’d be more likely to see a segmentation fault anywhere from 5 to 7 >> request-response loops later (navigating the app, clicking links). File >> sizes ranged from somewhat small like 4 megs up to about 250 megs. >> It was almost as if the WO adaptor was getting corrupted. Apache would give >> errors about unreadable headers that looked like a stream of binary data and >> then shortly after segmentation fault. > > > Some Linux distros do not configure Apache with MPM-prefork anymore > these days. We observed major problems with MPM-event / MPM-multithread > in combination with WO module, including httpd process crashes. We > switched back to prefork and that solved the issue. > > But clearly, mod_proxy seems to be the better option here, we are > looking forward to this. > > Whats the 'official' state of mod_WebObjects? Will it become legacy > or get abandoned? Are there any plans? > > Thank you all, > Michael > > > > -- > ___________________________ > > Michael Schmiedgen, BSc > Senior Software Engineer > > Takwa GmbH > Friedrich-List-Str. 15 > 99096 Erfurt GERMANY > > Tel +49 361 6534096 > Fax +49 361 6534097 > Mail schmied...@takwa.de > Web http://www.takwa.de/ > ___________________________ > > > Amtsgericht Jena HRB 112964 > Geschäftsführung: Ingo Buchholz _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
