Re: Apache config + startup.pl attached; Re: Apache2 with Plack;

Hi Marjan,

I'm sorry if I missed the attachments before. I have them now; I'll be looking at it shortly.

Working on 1.5.0-beta6/-rc1 and 1.4.29 delayed my looking at it for a bit, but I didn't forget. Today, I looked at it. These are my findings:

While I'm seeing your problem too, I'm not seeing it consistently: I can load http://192.168.122.13/ledgersmb/login.pl repeatedly and sometimes I see the login page, while other times, I see the error you're describing. (192.168.122.13 is my VM running Apache).

What I'm also seeing is that the mod_perl solution is pretty memory-hungry: the same VM is able to run Starman+nginx without issues. When I start the Apache2.4+mod_perl2 setup, the system starts running out of memory really quickly and starts killing workers to free up memory for other workers. (This is a 1GB VM, with nothing other than "just" Apache2/mod_perl/LedgerSMB(preloaded)) The memory-hungriness can be understood by the fact that mod_perl creates a separate Perl interpreter for each thread that Apache2 starts and loads LedgerSMB with all its dependencies into that. That's a lot. On Starman we pre-load a lot of LedgerSMB dependencies *before* we fork(). This means that we take maximum advantage of Unix's copy-on-write fork()ing efficiency. A lot of memory holding the dependencies, is used for all Starman's workers, instead of needing an entirely new copy for each worker.

Upon review of the startup.pl file, there's another important remark to be made: At this time, LedgerSMB can't generally be made to work under Apache2/mod_perl in any other scenario than where Apache2 runs the Prefork MPM; the chdir() call changes global process state, while the worker and event MPMs have multiple requests in process on various threads within a single process. Using chdir() affects these other requests.

[ Switched Apache2 to prefork mpm from event mpm ]

Running on the Prefork MPM isn't much better, I'm affraid. What I've been able to establish through debugging now, is that there's one thing very different in this setup than on any other setup: It's not an uninitialized value that's causing the problem; it's an object of type Apache2::RequestRec which is specific to this setup that's causing the problem.

Knowing what the problem is, I can at least put a patch in 1.4.30 which works around this problem: it's a 2-line change (in 5 files). That'd at least allow you to further experiment with the setup. Would that be helpful? (Once the change is in the tree, you could even apply it to your local 1.4.<anything> installation; I don't think these files have changed in ages.

Regards,

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.