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.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
