Re: How to get “my” VHOST in code executed by PerPostCon figRequire?

Guten Tag André Warnier,
am Mittwoch, 7. August 2019 um 15:21 schrieben Sie:

> In the PerlPostConfigRequire phase, there is no request yet, so there is no "selected"
> VHost yet.
> (But maybe, yes, it does get executed once per "VirtualHost" in the configuration; that, I
> really don't know. It may need to do that, just in case you have specified an option that
> allocates a separate perl interpreter per VHost).

And that's exactly what I need to do with "PerlOptions +Parent" anyway
and I can see in logs that my code behind "PerlPostConfigRequire" gets
executed without any request, has different environment variables per
request etc. I already implemented my former described approach and
things work (mostly) as hoped.

> All the above being said, I am wondering why it bothers you so, that a module is loaded
> and pre-compiled only when needed by the child/thread processing the request.

Performance is not my main concern, mod_perl/Perl/... simply breaks in
case too many concurrent requests arrive and need to compile my code.
I can easily reproduce that on Windows and Linux simply by using "ab"
and have that in production with different mod_perl-enabled apps.

Details can be found in the following mail, but the only workaround I
found so far is to pre-compile the code during startup or simply to
not use mod_perl at all. The latter is not an option because some apps
implement mod_perl request handlers.

> Syntax errors in case of threaded MPM and lots of concurrent requests.

http://mail-archives.apache.org/mod_mbox/perl-modperl/201907.mbox/%3C1116164701.20190731193313%40am-soft.de%3E

> And if you do not want this extra overhead at all, can you not specify all the module
> versions to be loaded, in the PerlPostConfigRequire directive ?

That introduces manual maintenance overhead I would like to avoid. My
current implementation simply finds the dirs to its app based on the
current VHOST, iterates some files and forwards that to mod_perl to
load them.

Works almost as expected, for some reason Perl still crashes at some
point during compilation of some packages.

> P.S. There are definitely some deep and mysterious issues remaining with mod_perl, when it
> is running under a threaded MPM.  We use only prefork MPM with mod_perl, for those reasons.

I need to support Windows which only supports some threaded MPM,
unless I'm missing something. But simply using prefork might be a
workaorund on Linux I didn't think of... Going to give it a try if I
can't find the root cause for my current crashes. Thanks for the hint!

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail: [email protected]
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow