Re: How to get “my” VHOST in code executed by PerPostConfigRequire?
Then you're much more fortunate than I am. :( On Wed, Aug 7, 2019, 11:06 AM Thorsten Schöning wrote: > Guten Tag John Dunlap, > am Mittwoch, 7. August 2019 um 16:26 schrieben Sie: > > > This will cause you a lot of grief. As I understand things, the core perl > > interpreter supports threads and is thread safe. However, most of the > > modules available on CPAN are not thread safe. So, unless your > application > > has no dependencies whatsoever(very unlikely) you're highly likely to > > encounter segmentation faults in production unless you use the prefork > MPM. > > This is extremely unfortunate because it prevents us from using an MPM > > other than prefork in production. > > I'm not seeing segmentation faults on production using Ubuntu and > worker MPM. If mod_perl was able to compile things, I have the feeling > it runs pretty stable. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > 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 > >
Re: How to get “my” VHOST in code executed by PerPostConfigRequire?
Guten Tag John Dunlap, am Mittwoch, 7. August 2019 um 16:26 schrieben Sie: > This will cause you a lot of grief. As I understand things, the core perl > interpreter supports threads and is thread safe. However, most of the > modules available on CPAN are not thread safe. So, unless your application > has no dependencies whatsoever(very unlikely) you're highly likely to > encounter segmentation faults in production unless you use the prefork MPM. > This is extremely unfortunate because it prevents us from using an MPM > other than prefork in production. I'm not seeing segmentation faults on production using Ubuntu and worker MPM. If mod_perl was able to compile things, I have the feeling it runs pretty stable. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de 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
Re: How to get “my” VHOST in code executed by PerPostConfigRequire?
> And that's exactly what I need to do with "PerlOptions +Parent"... This is how I support multiple code versions, when necessary. However, I strive to avoid this because it causes performance issues and makes server restarts take forever. > I need to support Windows which only supports some threaded MPM, This will cause you a lot of grief. As I understand things, the core perl interpreter supports threads and is thread safe. However, most of the modules available on CPAN are not thread safe. So, unless your application has no dependencies whatsoever(very unlikely) you're highly likely to encounter segmentation faults in production unless you use the prefork MPM. This is extremely unfortunate because it prevents us from using an MPM other than prefork in production. On Wed, Aug 7, 2019 at 10:20 AM Thorsten Schöning wrote: > 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: thorsten.schoen...@am-soft.de > 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 > > -- John Dunlap *CTO | Lariat * *Direct:* *j...@lariat.co * *Customer Service:* 877.268.6667 supp...@lariat.co
Re: How to get “my” VHOST in code executed by PerPostConfigRequire?
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: thorsten.schoen...@am-soft.de 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
Re: How to get “my” VHOST in code executed by PerPostConfigRequire?
Hi. First, my knowledge of these things is more of the "practical, as mod_perl user" level, than based on the code. And I'm more than willing to be corrected by a real code specialist. And forgive me if I am explaining things which you already know. As I understand your request (and the first one that you sent), you want different VHost to run different versions of the same webapp (one specific version per VHost), and for efficiency reasons you would like this "version" to be pre-loaded and pre-compiled by mod_perl, on a per-VHost base. And to do that, you want to find out the VHost name at the PerlPostConfigRequire stage. If so, I believe that you may be slightly on the wrong track here. A "VirtualHost" is not the same as an "Apache child/thread". An Apache child/thread gets selected (or created and selected, if need be) when the main Apache server instance (which receives the requests, but does not itself run any) has already processed its full configuration (all VHost configs included), and needs a child/thread to handle a request just received. Initially, each child/thread is "VHost-agnostic", and each one has a copy of the full server configuration (all VHosts included). Any such child/thread /then/ "becomes" a specific VHost to handle the current request, as per the request's "Host:" header and the part of the global configuration which applies to that VHost. In other words, it is at the moment when the child/thread has already received a request to handle, and parsed its "Host:" header, that it decides to "change its personality" to become the VHost to which this request is addressed. (And the next request that is handled by this same child/thread, may be for another VHost altogether). With reference to : http://perl.apache.org/docs/2.0/user/handlers/server.html#Server_Life_Cycle and the schema "Server Life Cycle" in it, I would say that the selection of the "current" VHost only happens in the "Connection loop" parts (children/threads), and only on a per-request base. 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). I believe that the first stage at which mod_perl "knows" the VHost corresponding to the current request is : http://perl.apache.org/docs/2.0/user/handlers/intro.html link : PerlPostReadRequestHandler Also : http://perl.apache.org/docs/2.0/user/handlers/intro.html#mod_perl_Handlers_Categories Also : http://perl.apache.org/docs/2.0/api/Apache2/RequestUtil.html#C_get_server_name_ This would imply that you cannot, at the PerlPostConfigRequire level, make any decision as to whether to pre-load a particular module version based on the "current" VHost's name. Note: there is also a sample module example at http://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_Phases_Demonstration_Module which looks like a good starting point for an easy way to test these things. More references : http://perl.apache.org/docs/2.0/user/handlers/server.html#mod_perl_Startup 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. This does cause a slight overhead, the first time any given child/thread needs that module. But for any subsequent request to the same child/thread, that module would already be in the mod_perl cache and pre-compiled, so there is no extra overhead anymore. 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 ? Because then, as I understand it, when Apache creates an additional child/thread (from the main Apache instance), the "main" perl interpreter and its module cache would already contain these modules, and they would be duplicated along with perl, to the perl in the child/thread. See also : http://perl.apache.org/docs/2.0/api/Apache2/ServerRec.html#Limited_Functionality_under_Threaded_MPMs 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. On 05.08.2019 21:01, Thorsten Schöning wrote: Guten Tag Thorsten Schöning, am Montag, 5. August 2019 um 19:18 schrieben Sie: The problem is that I'm having trouble how to find the VHOST currently executing that handler. The only thing which came into my mind is using environment variables per VHOST like in the following examples: PerlSetEnv SOME_ID "0c8c1236-86de-4483-9d4b-999e2cfd17c1" PerlPostConfigRequire "Some.pm" Each VHOST gets it's own ID and that environment variable seems to be uniquely available during execution of the configured package: [Mon Aug 05
