Re: HTTPd Devs Considered Harmful to Apache2::Request users
Simply put, 2.17 was a fraudulent release according to HTTPd's own rules for RM's. Under no circumstances may an RM unilaterally disable any component of the test suite without notifying the remainder of the PMC *on list*, because it is simply a deceptive practice for the rest of the group to have to behave as if the RM is an adversary to both the people expecting to vote on the candidate, and the downstream CPAN users who require the test suite to pass before installing the software. Not only was this never corrected, nor formally addressed by the board, the RM actually failed *up* and became PMC chair. On Sun, Feb 18, 2024 at 4:42 PM Joe Schaefer wrote: > Would you trust any of them at this point? > > I have a copy of svn trunk. I will never use anything they release, no > matter what they call it. > > Joe Schaefer, Ph.D. > <https://sunstarsys.com/orion/features> > Orion - The Enterprise Jamstack Wiki > <https://sunstarsys.com/orion/features> > > 954.253.3732 > > > > > On Sun, Feb 18, 2024 at 4:41 PM Mithun Bhattacharya > wrote: > >> So it will be moved to retired I assume or are they going to break their >> own rules and purge it altogether? >> >> >> On Sun, Feb 18, 2024, 3:33 PM Joe Schaefer wrote: >> >>> 2.18 will never be released. They are shutting down the project. >>> >>> Joe Schaefer, Ph.D. >>> <https://sunstarsys.com/orion/features> >>> Orion - The Enterprise Jamstack Wiki >>> <https://sunstarsys.com/orion/features> >>> >>> 954.253.3732 >>> >>> >>> >>> >>> On Sun, Feb 18, 2024 at 4:32 PM Mithun Bhattacharya >>> wrote: >>> >>>> Could you clarify this - 2.17 has a critical bug and 2.18 is about to >>>> come out which doesn't have a good enough patch so how would trunk be any >>>> better? >>>> >>>> Also how is this passing make test or were the test cases modified to >>>> make the bug pass ? >>>> >>>> >>>> On Sun, Feb 18, 2024, 1:12 PM Joe Schaefer wrote: >>>> >>>>> Trunk is the safe bet. >>>>> >>>>> Joe Schaefer, Ph.D. >>>>> <https://sunstarsys.com/orion/features> >>>>> Orion - The Enterprise Jamstack Wiki >>>>> <https://sunstarsys.com/orion/features> >>>>> >>>>> 954.253.3732 >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Feb 18, 2024 at 2:11 PM Mithun Bhattacharya >>>>> wrote: >>>>> >>>>>> So is there a cleaner/saner version of libapreq2 or is the 2012 >>>>>> version better ? >>>>>> >>>>>> On Sun, Feb 18, 2024, 12:58 PM Joe Schaefer >>>>>> wrote: >>>>>> >>>>>>> For the past 25 years, I have been the lead developer of the >>>>>>> libapreq2 subproject within the Apache HTTPd Server Parent Project. The >>>>>>> original idea of libapreq as a safe/performant HTML form and Cookie >>>>>>> parsing >>>>>>> library came out of a collaboration between Lincoln Stein and Doug >>>>>>> MacEachern in the late 90s. >>>>>>> >>>>>>> It was my vision back then to transform the library into a generic, >>>>>>> non-Perl related C library that would support language bindings from >>>>>>> other >>>>>>> programming languages, which is why I pushed for the project to be homes >>>>>>> under the HTTPd umbrella instead of the Apache-Perl project. >>>>>>> >>>>>>> While this vision was wildly successful, with language bindings >>>>>>> available for several languages like Perl, TCL, R, etc, ever since about >>>>>>> 2010 its proven tragic for the existing user community consisting of >>>>>>> all of >>>>>>> them, not just Perl. >>>>>>> >>>>>>> What happened? Philip Gollucci, a Perl/FreeBSD olleague of mine at >>>>>>> the time, started agitating that we promote the project to be released >>>>>>> from >>>>>>> inside the HTTPd server itself. What Philip didn’t know very well back >>>>>>> then >>>>>>> was how utterly vapid and territorial that team had become, which would >>>>>>> h
Re: HTTPd Devs Considered Harmful to Apache2::Request users
Would you trust any of them at this point? I have a copy of svn trunk. I will never use anything they release, no matter what they call it. Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732 On Sun, Feb 18, 2024 at 4:41 PM Mithun Bhattacharya wrote: > So it will be moved to retired I assume or are they going to break their > own rules and purge it altogether? > > > On Sun, Feb 18, 2024, 3:33 PM Joe Schaefer wrote: > >> 2.18 will never be released. They are shutting down the project. >> >> Joe Schaefer, Ph.D. >> <https://sunstarsys.com/orion/features> >> Orion - The Enterprise Jamstack Wiki >> <https://sunstarsys.com/orion/features> >> >> 954.253.3732 >> >> >> >> >> On Sun, Feb 18, 2024 at 4:32 PM Mithun Bhattacharya >> wrote: >> >>> Could you clarify this - 2.17 has a critical bug and 2.18 is about to >>> come out which doesn't have a good enough patch so how would trunk be any >>> better? >>> >>> Also how is this passing make test or were the test cases modified to >>> make the bug pass ? >>> >>> >>> On Sun, Feb 18, 2024, 1:12 PM Joe Schaefer wrote: >>> >>>> Trunk is the safe bet. >>>> >>>> Joe Schaefer, Ph.D. >>>> <https://sunstarsys.com/orion/features> >>>> Orion - The Enterprise Jamstack Wiki >>>> <https://sunstarsys.com/orion/features> >>>> >>>> 954.253.3732 >>>> >>>> >>>> >>>> >>>> On Sun, Feb 18, 2024 at 2:11 PM Mithun Bhattacharya >>>> wrote: >>>> >>>>> So is there a cleaner/saner version of libapreq2 or is the 2012 >>>>> version better ? >>>>> >>>>> On Sun, Feb 18, 2024, 12:58 PM Joe Schaefer >>>>> wrote: >>>>> >>>>>> For the past 25 years, I have been the lead developer of the >>>>>> libapreq2 subproject within the Apache HTTPd Server Parent Project. The >>>>>> original idea of libapreq as a safe/performant HTML form and Cookie >>>>>> parsing >>>>>> library came out of a collaboration between Lincoln Stein and Doug >>>>>> MacEachern in the late 90s. >>>>>> >>>>>> It was my vision back then to transform the library into a generic, >>>>>> non-Perl related C library that would support language bindings from >>>>>> other >>>>>> programming languages, which is why I pushed for the project to be homes >>>>>> under the HTTPd umbrella instead of the Apache-Perl project. >>>>>> >>>>>> While this vision was wildly successful, with language bindings >>>>>> available for several languages like Perl, TCL, R, etc, ever since about >>>>>> 2010 its proven tragic for the existing user community consisting of all >>>>>> of >>>>>> them, not just Perl. >>>>>> >>>>>> What happened? Philip Gollucci, a Perl/FreeBSD olleague of mine at >>>>>> the time, started agitating that we promote the project to be released >>>>>> from >>>>>> inside the HTTPd server itself. What Philip didn’t know very well back >>>>>> then >>>>>> was how utterly vapid and territorial that team had become, which would >>>>>> have meant having to collaborate with them directly on user-facing >>>>>> decisions about the code base. >>>>>> >>>>>> In 2012, Philip got what he wanted and I stopped resisting, so he >>>>>> forked the existing project and copied the C library components into >>>>>> HTTPd >>>>>> core. >>>>>> >>>>>> In 2016 I resigned from the Foundation en masse. You can guess the >>>>>> reasons. >>>>>> >>>>>> In 2020 or so, Google’s Security Team took advantage of an alpha >>>>>> release of httpd 2.5 by fuzzing its 8 year old copy of apreq. It found a >>>>>> few hotspots that needed repair. >>>>>> >>>>>> Instead of having the courtesy of reaching out to me, or anyone else >>>>>> involved in development of apreq, a junior engineer on the HTTPd team >>>>>> went >>>>>> about the business of “bug fixing” the vulnerabilities Google found. You >>>>>> can see a record of his trial and error work in every release since then. >>>>>> >>>>>> But the coup de grace was the 2022 release of 2.17, wherein the >>>>>> rookie developer purposely introduced a fatal bug into the codebase, >>>>>> breaking a fifteen year old regression test. >>>>>> >>>>>> If you are wondering how something with a broken regression test >>>>>> winds up on CPAN, you’ll have to look into how RELENG is done in the >>>>>> server >>>>>> project. >>>>>> >>>>>> Long story short, they commented out the test and shipped it anyway, >>>>>> and called it a Security Release that fixed a vulnerability every prior >>>>>> release was susceptible to. >>>>>> >>>>>> Why do I care now? Because I’m the sucker users reach out to for >>>>>> answers as a known subject matter expert. >>>>>> >>>>>> This sucks, but I’m sorry to tell you that my days wearing the >>>>>> Superman cape at Apache ended 8 years ago. >>>>>> >>>>>> -- >>>>>> Joe Schaefer, Ph.D. >>>>>> <https://sunstarsys.com/orion/features> >>>>>> Orion - The Enterprise Jamstack Wiki >>>>>> <https://sunstarsys.com/orion/features> >>>>>> >>>>>> 954.253.3732 >>>>>> >>>>>> >>>>>>
Re: HTTPd Devs Considered Harmful to Apache2::Request users
2.18 will never be released. They are shutting down the project. Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732 On Sun, Feb 18, 2024 at 4:32 PM Mithun Bhattacharya wrote: > Could you clarify this - 2.17 has a critical bug and 2.18 is about to come > out which doesn't have a good enough patch so how would trunk be any better? > > Also how is this passing make test or were the test cases modified to make > the bug pass ? > > > On Sun, Feb 18, 2024, 1:12 PM Joe Schaefer wrote: > >> Trunk is the safe bet. >> >> Joe Schaefer, Ph.D. >> <https://sunstarsys.com/orion/features> >> Orion - The Enterprise Jamstack Wiki >> <https://sunstarsys.com/orion/features> >> >> 954.253.3732 >> >> >> >> >> On Sun, Feb 18, 2024 at 2:11 PM Mithun Bhattacharya >> wrote: >> >>> So is there a cleaner/saner version of libapreq2 or is the 2012 version >>> better ? >>> >>> On Sun, Feb 18, 2024, 12:58 PM Joe Schaefer wrote: >>> >>>> For the past 25 years, I have been the lead developer of the libapreq2 >>>> subproject within the Apache HTTPd Server Parent Project. The original idea >>>> of libapreq as a safe/performant HTML form and Cookie parsing library came >>>> out of a collaboration between Lincoln Stein and Doug MacEachern in the >>>> late 90s. >>>> >>>> It was my vision back then to transform the library into a generic, >>>> non-Perl related C library that would support language bindings from other >>>> programming languages, which is why I pushed for the project to be homes >>>> under the HTTPd umbrella instead of the Apache-Perl project. >>>> >>>> While this vision was wildly successful, with language bindings >>>> available for several languages like Perl, TCL, R, etc, ever since about >>>> 2010 its proven tragic for the existing user community consisting of all of >>>> them, not just Perl. >>>> >>>> What happened? Philip Gollucci, a Perl/FreeBSD olleague of mine at the >>>> time, started agitating that we promote the project to be released from >>>> inside the HTTPd server itself. What Philip didn’t know very well back then >>>> was how utterly vapid and territorial that team had become, which would >>>> have meant having to collaborate with them directly on user-facing >>>> decisions about the code base. >>>> >>>> In 2012, Philip got what he wanted and I stopped resisting, so he >>>> forked the existing project and copied the C library components into HTTPd >>>> core. >>>> >>>> In 2016 I resigned from the Foundation en masse. You can guess the >>>> reasons. >>>> >>>> In 2020 or so, Google’s Security Team took advantage of an alpha >>>> release of httpd 2.5 by fuzzing its 8 year old copy of apreq. It found a >>>> few hotspots that needed repair. >>>> >>>> Instead of having the courtesy of reaching out to me, or anyone else >>>> involved in development of apreq, a junior engineer on the HTTPd team went >>>> about the business of “bug fixing” the vulnerabilities Google found. You >>>> can see a record of his trial and error work in every release since then. >>>> >>>> But the coup de grace was the 2022 release of 2.17, wherein the rookie >>>> developer purposely introduced a fatal bug into the codebase, breaking a >>>> fifteen year old regression test. >>>> >>>> If you are wondering how something with a broken regression test winds >>>> up on CPAN, you’ll have to look into how RELENG is done in the server >>>> project. >>>> >>>> Long story short, they commented out the test and shipped it anyway, >>>> and called it a Security Release that fixed a vulnerability every prior >>>> release was susceptible to. >>>> >>>> Why do I care now? Because I’m the sucker users reach out to for >>>> answers as a known subject matter expert. >>>> >>>> This sucks, but I’m sorry to tell you that my days wearing the Superman >>>> cape at Apache ended 8 years ago. >>>> >>>> -- >>>> Joe Schaefer, Ph.D. >>>> <https://sunstarsys.com/orion/features> >>>> Orion - The Enterprise Jamstack Wiki >>>> <https://sunstarsys.com/orion/features> >>>> >>>> 954.253.3732 >>>> >>>> >>>>
Re: HTTPd Devs Considered Harmful to Apache2::Request users
You are welcome, colleague! Keep in mind the SoBs are threatening to release 2.18 as we speak, but like everything else they do, it’s a dog and pony show in a Potemkin Village. They simply are too lazy, inept, and mendacious to execute. Use trunk, while it still exists. Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732 On Sun, Feb 18, 2024 at 2:12 PM Mithun Bhattacharya wrote: > Also thank you for the library ! > > On Sun, Feb 18, 2024, 1:11 PM Mithun Bhattacharya > wrote: > >> So is there a cleaner/saner version of libapreq2 or is the 2012 version >> better ? >> >> On Sun, Feb 18, 2024, 12:58 PM Joe Schaefer wrote: >> >>> For the past 25 years, I have been the lead developer of the libapreq2 >>> subproject within the Apache HTTPd Server Parent Project. The original idea >>> of libapreq as a safe/performant HTML form and Cookie parsing library came >>> out of a collaboration between Lincoln Stein and Doug MacEachern in the >>> late 90s. >>> >>> It was my vision back then to transform the library into a generic, >>> non-Perl related C library that would support language bindings from other >>> programming languages, which is why I pushed for the project to be homes >>> under the HTTPd umbrella instead of the Apache-Perl project. >>> >>> While this vision was wildly successful, with language bindings >>> available for several languages like Perl, TCL, R, etc, ever since about >>> 2010 its proven tragic for the existing user community consisting of all of >>> them, not just Perl. >>> >>> What happened? Philip Gollucci, a Perl/FreeBSD olleague of mine at the >>> time, started agitating that we promote the project to be released from >>> inside the HTTPd server itself. What Philip didn’t know very well back then >>> was how utterly vapid and territorial that team had become, which would >>> have meant having to collaborate with them directly on user-facing >>> decisions about the code base. >>> >>> In 2012, Philip got what he wanted and I stopped resisting, so he forked >>> the existing project and copied the C library components into HTTPd core. >>> >>> In 2016 I resigned from the Foundation en masse. You can guess the >>> reasons. >>> >>> In 2020 or so, Google’s Security Team took advantage of an alpha release >>> of httpd 2.5 by fuzzing its 8 year old copy of apreq. It found a few >>> hotspots that needed repair. >>> >>> Instead of having the courtesy of reaching out to me, or anyone else >>> involved in development of apreq, a junior engineer on the HTTPd team went >>> about the business of “bug fixing” the vulnerabilities Google found. You >>> can see a record of his trial and error work in every release since then. >>> >>> But the coup de grace was the 2022 release of 2.17, wherein the rookie >>> developer purposely introduced a fatal bug into the codebase, breaking a >>> fifteen year old regression test. >>> >>> If you are wondering how something with a broken regression test winds >>> up on CPAN, you’ll have to look into how RELENG is done in the server >>> project. >>> >>> Long story short, they commented out the test and shipped it anyway, and >>> called it a Security Release that fixed a vulnerability every prior release >>> was susceptible to. >>> >>> Why do I care now? Because I’m the sucker users reach out to for answers >>> as a known subject matter expert. >>> >>> This sucks, but I’m sorry to tell you that my days wearing the Superman >>> cape at Apache ended 8 years ago. >>> >>> -- >>> Joe Schaefer, Ph.D. >>> <https://sunstarsys.com/orion/features> >>> Orion - The Enterprise Jamstack Wiki >>> <https://sunstarsys.com/orion/features> >>> >>> 954.253.3732 >>> >>> >>>
Re: HTTPd Devs Considered Harmful to Apache2::Request users
Trunk is the safe bet. Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732 On Sun, Feb 18, 2024 at 2:11 PM Mithun Bhattacharya wrote: > So is there a cleaner/saner version of libapreq2 or is the 2012 version > better ? > > On Sun, Feb 18, 2024, 12:58 PM Joe Schaefer wrote: > >> For the past 25 years, I have been the lead developer of the libapreq2 >> subproject within the Apache HTTPd Server Parent Project. The original idea >> of libapreq as a safe/performant HTML form and Cookie parsing library came >> out of a collaboration between Lincoln Stein and Doug MacEachern in the >> late 90s. >> >> It was my vision back then to transform the library into a generic, >> non-Perl related C library that would support language bindings from other >> programming languages, which is why I pushed for the project to be homes >> under the HTTPd umbrella instead of the Apache-Perl project. >> >> While this vision was wildly successful, with language bindings available >> for several languages like Perl, TCL, R, etc, ever since about 2010 its >> proven tragic for the existing user community consisting of all of them, >> not just Perl. >> >> What happened? Philip Gollucci, a Perl/FreeBSD olleague of mine at the >> time, started agitating that we promote the project to be released from >> inside the HTTPd server itself. What Philip didn’t know very well back then >> was how utterly vapid and territorial that team had become, which would >> have meant having to collaborate with them directly on user-facing >> decisions about the code base. >> >> In 2012, Philip got what he wanted and I stopped resisting, so he forked >> the existing project and copied the C library components into HTTPd core. >> >> In 2016 I resigned from the Foundation en masse. You can guess the >> reasons. >> >> In 2020 or so, Google’s Security Team took advantage of an alpha release >> of httpd 2.5 by fuzzing its 8 year old copy of apreq. It found a few >> hotspots that needed repair. >> >> Instead of having the courtesy of reaching out to me, or anyone else >> involved in development of apreq, a junior engineer on the HTTPd team went >> about the business of “bug fixing” the vulnerabilities Google found. You >> can see a record of his trial and error work in every release since then. >> >> But the coup de grace was the 2022 release of 2.17, wherein the rookie >> developer purposely introduced a fatal bug into the codebase, breaking a >> fifteen year old regression test. >> >> If you are wondering how something with a broken regression test winds up >> on CPAN, you’ll have to look into how RELENG is done in the server project. >> >> Long story short, they commented out the test and shipped it anyway, and >> called it a Security Release that fixed a vulnerability every prior release >> was susceptible to. >> >> Why do I care now? Because I’m the sucker users reach out to for answers >> as a known subject matter expert. >> >> This sucks, but I’m sorry to tell you that my days wearing the Superman >> cape at Apache ended 8 years ago. >> >> -- >> Joe Schaefer, Ph.D. >> <https://sunstarsys.com/orion/features> >> Orion - The Enterprise Jamstack Wiki >> <https://sunstarsys.com/orion/features> >> >> 954.253.3732 >> >> >>
HTTPd Devs Considered Harmful to Apache2::Request users
For the past 25 years, I have been the lead developer of the libapreq2 subproject within the Apache HTTPd Server Parent Project. The original idea of libapreq as a safe/performant HTML form and Cookie parsing library came out of a collaboration between Lincoln Stein and Doug MacEachern in the late 90s. It was my vision back then to transform the library into a generic, non-Perl related C library that would support language bindings from other programming languages, which is why I pushed for the project to be homes under the HTTPd umbrella instead of the Apache-Perl project. While this vision was wildly successful, with language bindings available for several languages like Perl, TCL, R, etc, ever since about 2010 its proven tragic for the existing user community consisting of all of them, not just Perl. What happened? Philip Gollucci, a Perl/FreeBSD olleague of mine at the time, started agitating that we promote the project to be released from inside the HTTPd server itself. What Philip didn’t know very well back then was how utterly vapid and territorial that team had become, which would have meant having to collaborate with them directly on user-facing decisions about the code base. In 2012, Philip got what he wanted and I stopped resisting, so he forked the existing project and copied the C library components into HTTPd core. In 2016 I resigned from the Foundation en masse. You can guess the reasons. In 2020 or so, Google’s Security Team took advantage of an alpha release of httpd 2.5 by fuzzing its 8 year old copy of apreq. It found a few hotspots that needed repair. Instead of having the courtesy of reaching out to me, or anyone else involved in development of apreq, a junior engineer on the HTTPd team went about the business of “bug fixing” the vulnerabilities Google found. You can see a record of his trial and error work in every release since then. But the coup de grace was the 2022 release of 2.17, wherein the rookie developer purposely introduced a fatal bug into the codebase, breaking a fifteen year old regression test. If you are wondering how something with a broken regression test winds up on CPAN, you’ll have to look into how RELENG is done in the server project. Long story short, they commented out the test and shipped it anyway, and called it a Security Release that fixed a vulnerability every prior release was susceptible to. Why do I care now? Because I’m the sucker users reach out to for answers as a known subject matter expert. This sucks, but I’m sorry to tell you that my days wearing the Superman cape at Apache ended 8 years ago. -- Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732
Re: static code analysis for Perl5 code?
In short, you should just be running Perl with the -T flag. Perl::Critic is just a very opinionated linter. Joe Schaefer, Ph.D +1 (954) 253-3732 SunStar Systems, Inc. Orion - The Enterprise Jamstack Wiki From: Joseph He Sent: Thursday, February 15, 2024 10:43:41 AM To: mod_perl list Subject: static code analysis for Perl5 code? All, good day. Our company wants to use some tool to do a static analysis on our Perl5 code like what they can do for Java, etc. I know Perl::Critic can scan the code for the 'best practice'. Other than this, anybody knows that there is another tool supposedly to help find the security loopholes, etc? Thank you very much. Joseph
Re: Case-sensitive $r->param?
You're more than welcome to join our tech blogging community Randolf. Just reach out privately with your preferred username and I'll get you sorted today. On Wed, Feb 14, 2024 at 3:22 PM Randolf Richardson wrote: > Yeah, I can see that being a major undertaking, and then Ruben's > observation that it could break a lot of software is also important. > > By the way, thanks for all the work you've done on Mod Perl. It's > a > great solution for the projects I work on, and I use it extensively > for a lot of different things -- not just building interactive web > sites (that use DBI and PostgreSQL primairly for the database > backends), but also for adding custom Diriective to Apache HTTPd, > hooking into different stages, and for some custom protocol stuff too > (not HTTP). > > I feel that mod_perl2 is an amazing solution that deserves a lot > more publicity than it currently receives, and I'm optimistic about > the future of it as I'm hearing lately that Perl is gaining more > popularity again in recent years. > > > It´s not worth replumbing apr`s table API at this point. > > > > Joe Schaefer, Ph.D. > > <https://sunstarsys.com/orion/features> > > Orion - The Enterprise Jamstack Wiki < > https://sunstarsys.com/orion/features> > > > > 954.253.3732 > > > > > > > > > > On Wed, Feb 14, 2024 at 11:31AM Randolf Richardson > > wrote: > > > > > Thanks Joe. So it's an APR library issue then. > > > > > > I wonder if adding a case_sensitive_keys() method to > > > APR::Request::Param that takes a boolean is something the APR team > > > would be willing to add. Or might there be a better approach? > > > > > > > In short- No. All apreq interfaces use APR tables underneath. > > > > > > > > On Wed, Feb 14, 2024 at 11:12AM Randolf Richardson < > rand...@modperl.pl> > > > > wrote: > > > > > > > > > Is there a way to use $r->param in a case-sensitive manner? > > > The > > > > > documentation indicates that keys are case-insensitive. > > > > > > > > > > Thanks. > > > > > > > > > > Randolf Richardson, CNA - rand...@inter-corporate.com > > > > > Inter-Corporate Computer & Network Services, Inc. > > > > > Beautiful British Columbia, Canada > > > > > https://www.inter-corporate.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > Randolf Richardson, CNA - rand...@inter-corporate.com > > > Inter-Corporate Computer & Network Services, Inc. > > > Beautiful British Columbia, Canada > > > https://www.inter-corporate.com/ > > > > > > > > > > > > > > Randolf Richardson, CNA - rand...@inter-corporate.com > Inter-Corporate Computer & Network Services, Inc. > Beautiful British Columbia, Canada > https://www.inter-corporate.com/ > > >
Re: how to make :Sealed subs reentrant...
Personally, after all the work I have done over the past 25 years to make mod_perl what it is today, I could care less about making it easy for other people to avoid patching source code to perl itself. If you don't like the performance gains of using :Sealed subroutines on your mod_perl handlers, you can always not use it. On Wed, Feb 14, 2024 at 2:42 PM Ed Sabol wrote: > On Feb 14, 2024, at 2:27 PM, Joe Schaefer wrote: > > sealed.pm is really only necessary in a mod_perl context. And really it > only matters if you are using subrequests to reenter :Sealed handlers. > Otherwise I don't see the point of the exercise. > > Well, I suppose one point of the exercise would that a person who wants to > do this wouldn't have patch and compile Perl, but if you don't think > there's any value in that, then OK. > > Regards, > Ed > >
Re: how to make :Sealed subs reentrant...
sealed.pm is really only necessary in a mod_perl context. And really it only matters if you are using subrequests to reenter :Sealed handlers. Otherwise I don't see the point of the exercise. On Wed, Feb 14, 2024 at 2:25 PM Joe Schaefer wrote: > Why would there be? It only impacts :sealed subs, which is not bundled > with Perl. > > On Wed, Feb 14, 2024 at 2:24 PM Ed Sabol wrote: > >> On Feb 14, 2024, at 12:18 PM, Joe Schaefer wrote: >> > pad.c will segfault with an out-of-bounds memory access at line 2460 of >> pad.c. >> >> Is there a Perl/perl5 GitHub issue or pull request for this? >> >> Regards, >> Ed >> >>
Re: how to make :Sealed subs reentrant...
Why would there be? It only impacts :sealed subs, which is not bundled with Perl. On Wed, Feb 14, 2024 at 2:24 PM Ed Sabol wrote: > On Feb 14, 2024, at 12:18 PM, Joe Schaefer wrote: > > pad.c will segfault with an out-of-bounds memory access at line 2460 of > pad.c. > > Is there a Perl/perl5 GitHub issue or pull request for this? > > Regards, > Ed > >
how to make :Sealed subs reentrant...
pad.c will segfault with an out-of-bounds memory access at line 2460 of pad.c. If you are willing to recompile perl with a dirty hotfix, there is one mentioned near the bottom of this page: https://blogs.sunstarsys.com/joe/perl7-sealed-lexicals.html.en.gz -- Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732
Re: Case-sensitive $r->param?
It’s not worth replumbing apr‘s table API at this point. Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732 On Wed, Feb 14, 2024 at 11:31 AM Randolf Richardson wrote: > Thanks Joe. So it's an APR library issue then. > > I wonder if adding a case_sensitive_keys() method to > APR::Request::Param that takes a boolean is something the APR team > would be willing to add. Or might there be a better approach? > > > In short- No. All apreq interfaces use APR tables underneath. > > > > On Wed, Feb 14, 2024 at 11:12AM Randolf Richardson > > wrote: > > > > > Is there a way to use $r->param in a case-sensitive manner? > The > > > documentation indicates that keys are case-insensitive. > > > > > > Thanks. > > > > > > Randolf Richardson, CNA - rand...@inter-corporate.com > > > Inter-Corporate Computer & Network Services, Inc. > > > Beautiful British Columbia, Canada > > > https://www.inter-corporate.com/ > > > > > > > > > > > > > > Randolf Richardson, CNA - rand...@inter-corporate.com > Inter-Corporate Computer & Network Services, Inc. > Beautiful British Columbia, Canada > https://www.inter-corporate.com/ > > >
Re: Case-sensitive $r->param?
In short- No. All apreq interfaces use APR tables underneath. On Wed, Feb 14, 2024 at 11:12 AM Randolf Richardson wrote: > Is there a way to use $r->param in a case-sensitive manner? The > documentation indicates that keys are case-insensitive. > > Thanks. > > Randolf Richardson, CNA - rand...@inter-corporate.com > Inter-Corporate Computer & Network Services, Inc. > Beautiful British Columbia, Canada > https://www.inter-corporate.com/ > > >
Reviving the mod_perl social network
We're making free tech blogs available to our social network on our mod_perl + event_mpm platform. Something like blogs.sunstarsys.com/joe look interesting? Get in on the ground floor and contact me privately for your account. Thanks! Let's revive the mod_perl tech community together, one blog at a time, while running on our own dogfood. -- Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732
Config Primer on mod_perl with mpm_event
Quick reminders on how to get mod_perl working with mpm_event. The primary objective is to never allow mod_perl to garbage collect *any* of your interpreters during ithread-pool management. Two key components of that are: 1/ always set PerlInterpMaxSpare == PerlInterpMax. 2/ always set PerlInterpMaxRequests to be at least 10x greater than your site's daily hit count. 3/ always disable the SetupEnv Option. Yes, it's that simple. Any other core dumps are due to non-ithread-safe 3rd party Perl modules. -- Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732
Re: Resolved: Apache2::Upload v2.17 clobbering remaining CGI parameters + installation notes
Nobody’s forcing you to use it. Joe Schaefer, Ph.D +1 (954) 253-3732 SunStar Systems, Inc. Orion - The Enterprise Jamstack Wiki From: Ed Sabol Sent: Thursday, January 11, 2024 3:56:47 PM To: mod_perl list Cc: steve.m@googlemail.com Subject: Re: Resolved: Apache2::Upload v2.17 clobbering remaining CGI parameters + installation notes Who do we need to beg or plead with to get a proper release of libapreq 2.18? This has been an issue for over a year! On Jan 11, 2024, at 4:00 AM, Randolf Richardson wrote: >Thank you, Joe. Upgrading from libapreq-2.17 (via apt) to > libapreq-2.18 (via svn) resolved my problem -- everything is > functioning as expected now, including HTML POST form handling with > file upload inputs. > >I also attached my installation notes with the hopes that this may > be helpful to anyone else installing this upgrade on Debian 12.4 (or > another similar version of Linux). > >Thanks again for your fast and helpful response. :) > >> You need to build and install libapreq2.so from svn sources.
Re: Apache2::Upload v2.17 clobbering remaining CGI parameters
You need to build and install libapreq2.so from svn sources.
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>
954.253.3732
On Wed, Jan 10, 2024 at 5:21 PM Randolf Richardson
wrote:
> I just recently upgraded my systems to Debian 12, and along with
> it
> came modperl_2.17. Overall, this release is working very well,
> except for one thing...
>
> Handling CGI parameters in HTML forms that support file
> attachments,
> which results all CGI parameters after the file (whether a user
> attaches a file or not makes no difference) are missing.
>
> For any HTML input fields that I move before the file attachment
> input element, then then their CGI parameters come through, while all
> CGI parameters after the first file input field remain missing.
>
> Any HTML forms that don't have any file input fiels are working
> correctly.
>
>
> Text:
>
> File:
>
> More:
>
>
>
>
> In my handling code, using $R->param('one') always functions as
> expected, but $R->param('more') returns undef.
>
> Has anyone else encountered this problem? If so, did you find a
> solution? (If so, what got it working for you?)
>
> Thanks in advance.
>
> Randolf Richardson, CNA - rand...@inter-corporate.com
> Inter-Corporate Computer & Network Services, Inc.
> Beautiful British Columbia, Canada
> https://www.inter-corporate.com/
>
>
>
ithread+event mpm tips for a segfault free ride
1. Never reap ithreads via modperl's Interpreter tune. Once modperl spins up a new ithread for capacity response, leave it alone until you logrotate httpd with a graceful restart. 2. Consistently Disable the use of per-request ENV vars populated by modperl. 3. Enjoy some high-performance efficiency boosts in your modperl handlers with sealed.pm, (but avoid reentrancy/recursion for those subs, or you may segfault). -- Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732
Re: upgrade to Debian Bookworm : use backports for libapache2-request-perl and libapache2-mod-apreq2?
The httpd project fucked it up, and won’t unfuck it with a valid release. On Fri, Aug 18, 2023 at 9:21 PM Vincent Veyron wrote: > > Hi list, > > I upgraded a machine from Debian Bullseye to Debian Bookworm. Kind of a > bumpy road, as libapache2-request-perl ended up uninstalled. I had to add : > > deb http://deb.debian.org/debian bookworm-backports main > > to my sources.list to re-install libapache2-request-perl and upgrade > libapache2-mod-apreq2 to the latest version. This worries me about future > upgrades, as it complicates them. > > Do you know why these packages are now in backports, instead of main? > > > Links to concerned packages : > > https://packages.debian.org/bookworm-backports/libapache2-request-perl > > https://packages.debian.org/bookworm-backports/libapache2-mod-apreq2 > > -- > Bien à vous, Vincent Veyron > > https://marica.fr/ > Logiciel de suivi des contentieux juridiques, des sinistres d'assurance et > des contrats > > -- Joe Schaefer, Ph.D. <https://sunstarsys.com/orion/features> Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features> 954.253.3732
Re: sealed v4.1.9 on CPAN
It’s a general purpose module, so it will enhance performance even outside modperl apps. Joe Schaefer, Ph.D +1 (954) 253-3732 SunStar Systems, Inc. Orion - The Enterprise Jamstack Wiki From: Thomas den Braber Sent: Wednesday, May 10, 2023 8:49:13 AM To: j...@sunstarsys.com ; 'mod_perl list' Subject: Re: sealed v4.1.9 on CPAN Hi Joe, > > Am I beating a dead horse with mod_perl + mpm_event in 2022? > If you are beating a dead horse it at least is one that can still outperform most others. I am still using mpm_winnt in 2023. Are there any 'Sealed' advantages for mpm_prefork or mpm_winnt ? Thomas den Braber
Re: sealed v4.1.9 on CPAN
Because you want to support HTTP/2, and mod_perl +mpm_event is the only way to do it? On Tue, Oct 25, 2022 at 8:31 AM Henry R wrote: > why use mpm_event for mp? I doubt its stability. I am using mpm_prefork > for a long time. > > thanks > > j...@sunstarsys.com wrote: > > Feedback/flames welcome. Am I beating a dead horse with mod_perl + > > mpm_event in 2022? > > > > -- > Henry R > https://openmbox.net/ > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: sealed v4.1.8 deep recursion bugfix is on CPAN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Sorry the test script is for the cms build here: https://github.com/SunStarSys/cms/blob/master/test.sh - -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732 On 2022-09-17 at 17:48, j...@sunstarsys.com wrote: > Be sure to pick up the latest CPAN release of sealed.pm if you want to be able to run this test script successfully: > > https://github.com/SunStarSys/sealed/blob/master/test.sh > > > Joe Schaefer, Ph.D. > > 954.253.3732 > SunStar Systems CMS - The Original Markdown JAM Stack™ > -BEGIN PGP SIGNATURE- Version: FlowCrypt Email Encryption 8.3.5 Comment: Seamlessly send and receive encrypted email wsFzBAEBCgAGBQJjJgjvACEJEEAg7C7WAdUZFiEEf+9TuFcgikzfTrs6QCDs LtYB1RkEDg//URzS7s7jjpL4dD1tJvX7EE6pF9Ve9k6Uo6pTaVgQHmWg1fdQ 06VObzKaka+dSK7Cy22xINVAfBIgg5F7KIH0tqJtaEeGz1HL3ti5IysE1K/D Tfdmi9IK0PMBB7uRMaU3LQAJwejqPc8vF2V1JtmhkMG5kzocnW7KX2KaqugT QVNj4mlty2HyGRciVR/MXzbBR/H0nBXkrkWOWdb0HIaWIoLG9wDbGAcH06q1 RV7fgDiBpXurAyy++LPAV55fdAHeSo4eAApw7iLAz7TthT+d8izvXdgkKswx 2glf6zSamXMiWj2ISy/aimJWEpTadyLW4YP6U1+A7LyLtqLKy9KKbiefDcxB FY+kd/hWsMFYWO1F/oA7XRSa9QY3gGeT4tAxsB7I2f2DyYa00ipHnUgO6PsK VQFPUd10LyrZo+HXDD8olIu6bpIBicMR08hH3J9nE3BRz6j9ZBonkIRXPqeY ag+9Rli8AZV0Ks+SR4bLK36TT4tUI4c9ofSOgQbjVGNGBobAVwBDx0kJB6EM HnxR5KEgDvqbj1b4AZfM1WoDoFLm2Gw97cttndJm2fbCV6b26Pd3HjWvmAkc nJThpvgiWPUnnkxYqo0x/txjTOdSFenf4rovKCl/cRr8q7LNvmCpaBqBAJyQ AzPZ9w/EotccgL7L9dmqLjwshV62febiSOU= =TuSz -END PGP SIGNATURE-
Re: sealed v4.1.1 released to CPAN
4.1.2 has a slightly better tree walker. Please kick the tires on the RegistryCooker patch so the current modperl maintainers will be comfortable releasing a new version with that sealed.pm dependency for registry scripts. On Thu, Sep 1, 2022 at 12:45 PM wrote: > New project home dedicated to sealed.pm maintenance is at > https://github.com/SunStarSys/sealed > > In the interest of saving more time and hassle, I put the best version I > could come up with on CPAN, so you don’t need to clone the repository > unless you want to benchmark the enquiry.pl ModPerl::Registry script. > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: sealed.pm v4.0.0 is out
What I'm saying is that this isn't foolproof, but really neither is doing
mod_perl + ithreads without sealed.pm. A bad tune will blow up under
pressure,
so be careful out there in the brave new world of single-tiered
webstacks using mod_perl and mpm_event plus mod_http2.
On Wed, Aug 31, 2022 at 8:11 PM Joe Schaefer wrote:
> 4.0.1 is going to trap everything bizarre that occurs within the tweak()
> subroutine, and gracefully bail out.
> The only thing this needs your help with is to avoid putting heavy ithread
> pressure on mod_perl during interpreter
> destruction. One simple approach is to make sure your modperl interpreter
> settings never destroy ithreads-
> leave that for httpd during graceful restart.
>
>
> On Wed, Aug 31, 2022 at 7:41 PM Joe Schaefer wrote:
>
>> To throw mod_apreq2 into the benchmarking mix, add items to the query
>> string you are hitting (on enquiry.pl).
>> In particular, lang=.{en,es,de,fr} will generate UTF-8 European-language
>> localized output.
>>
>> On Wed, Aug 31, 2022 at 7:13 PM Joe Schaefer wrote:
>>
>>> I went ahead and copied my company templates over to the github cms
>>> repo, so you can run enquiry.pl yourself
>>> (once you edit the @TEMPLATE_DIRS path to point at your checkout). You
>>> will see sealed.pm at work in the
>>> httpd error logs.
>>>
>>> On Wed, Aug 31, 2022 at 1:02 PM Joe Schaefer wrote:
>>>
>>>> For my part in this story, v4.0.0 is the end of the line. This release
>>>> solves every business problem my own company
>>>> had with prior releases, so I'm satisfied with where it lies.
>>>>
>>>> But it is not perfect by any stretch. To take it to the level where it
>>>> needs to be someday, B::Generate's maintainers need to be reliable
>>>> partners with the future maintainers of sealed.pm, to deal with
>>>> whatever long-range support issues crop up as perlguts invariably
>>>> undergoes changes that break the undocumented assumptions I've made in
>>>> getting this into workable condition.
>>>>
>>>> What do you think about the idea of putting sealed.pm into the modperl
>>>> project, vs. a stand-alone on CPAN?
>>>>
>>>> On Wed, Aug 31, 2022 at 10:53 AM Joe Schaefer
>>>> wrote:
>>>>
>>>>> In the end, the surgery we do (to method_named), is to replace the
>>>>> prior $op's next() pointer to point at the $gv op we copied from
>>>>> a known subroutine's op-tree (that uses a typical subroutine call
>>>>> instead of a method lookup). Since we relocated that next() pointer,
>>>>> we need to decrement the internal refcnt for the method_named op to
>>>>> avoid leaks/segfaults during garbage collection of the ithread.
>>>>>
>>>>> None of the many issues Doug faced back in 2000 to do this on a more
>>>>> generic level actually need to be done for this implementation.
>>>>> You just need to know that any code that tries to walk this tree (eg
>>>>> B::Deparse) post-tweaks may choke on the zombie method_named
>>>>> op lying around in one of the sibling() linked lists. That probably
>>>>> includes the ithread-cloniing mechanism itself, so only use :sealed
>>>>> post ithread construction, not prior to it.
>>>>>
>>>>> On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer
>>>>> wrote:
>>>>>
>>>>>> The :sealed attribute is a statement about a class's @ISA: you are
>>>>>> saying you are using its compile-time setting.
>>>>>> And because we invoke $class->can to do the lookup, module authors
>>>>>> who override UNIVERSAL::can() with a customized
>>>>>> one can support AUTOLOADed methods themselves.
>>>>>>
>>>>>> Under :sealed, you control which lexical object references you want
>>>>>> to use compile-time method lookups (via can()),
>>>>>> by declaring them with a class (type), or avoiding doing that in the
>>>>>> lexical's declaration. It only impacts your subroutine
>>>>>> definitions that declare :sealed and a typed lexicals, not any other
>>>>>> module's code elsewhere.
>>>>>>
>>>>>> You absolutely *can* use sealed.pm outside mod_perl, but you need to
>>>>>> be wary about using typed lexicals on your method
>>>>>> argument stack, because end-users may pass properly derived o
Re: sealed.pm v4.0.0 is out
4.0.1 is going to trap everything bizarre that occurs within the tweak()
subroutine, and gracefully bail out.
The only thing this needs your help with is to avoid putting heavy ithread
pressure on mod_perl during interpreter
destruction. One simple approach is to make sure your modperl interpreter
settings never destroy ithreads-
leave that for httpd during graceful restart.
On Wed, Aug 31, 2022 at 7:41 PM Joe Schaefer wrote:
> To throw mod_apreq2 into the benchmarking mix, add items to the query
> string you are hitting (on enquiry.pl).
> In particular, lang=.{en,es,de,fr} will generate UTF-8 European-language
> localized output.
>
> On Wed, Aug 31, 2022 at 7:13 PM Joe Schaefer wrote:
>
>> I went ahead and copied my company templates over to the github cms repo,
>> so you can run enquiry.pl yourself
>> (once you edit the @TEMPLATE_DIRS path to point at your checkout). You
>> will see sealed.pm at work in the
>> httpd error logs.
>>
>> On Wed, Aug 31, 2022 at 1:02 PM Joe Schaefer wrote:
>>
>>> For my part in this story, v4.0.0 is the end of the line. This release
>>> solves every business problem my own company
>>> had with prior releases, so I'm satisfied with where it lies.
>>>
>>> But it is not perfect by any stretch. To take it to the level where it
>>> needs to be someday, B::Generate's maintainers need to be reliable
>>> partners with the future maintainers of sealed.pm, to deal with
>>> whatever long-range support issues crop up as perlguts invariably
>>> undergoes changes that break the undocumented assumptions I've made in
>>> getting this into workable condition.
>>>
>>> What do you think about the idea of putting sealed.pm into the modperl
>>> project, vs. a stand-alone on CPAN?
>>>
>>> On Wed, Aug 31, 2022 at 10:53 AM Joe Schaefer
>>> wrote:
>>>
>>>> In the end, the surgery we do (to method_named), is to replace the
>>>> prior $op's next() pointer to point at the $gv op we copied from
>>>> a known subroutine's op-tree (that uses a typical subroutine call
>>>> instead of a method lookup). Since we relocated that next() pointer,
>>>> we need to decrement the internal refcnt for the method_named op to
>>>> avoid leaks/segfaults during garbage collection of the ithread.
>>>>
>>>> None of the many issues Doug faced back in 2000 to do this on a more
>>>> generic level actually need to be done for this implementation.
>>>> You just need to know that any code that tries to walk this tree (eg
>>>> B::Deparse) post-tweaks may choke on the zombie method_named
>>>> op lying around in one of the sibling() linked lists. That probably
>>>> includes the ithread-cloniing mechanism itself, so only use :sealed
>>>> post ithread construction, not prior to it.
>>>>
>>>> On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer
>>>> wrote:
>>>>
>>>>> The :sealed attribute is a statement about a class's @ISA: you are
>>>>> saying you are using its compile-time setting.
>>>>> And because we invoke $class->can to do the lookup, module authors who
>>>>> override UNIVERSAL::can() with a customized
>>>>> one can support AUTOLOADed methods themselves.
>>>>>
>>>>> Under :sealed, you control which lexical object references you want to
>>>>> use compile-time method lookups (via can()),
>>>>> by declaring them with a class (type), or avoiding doing that in the
>>>>> lexical's declaration. It only impacts your subroutine
>>>>> definitions that declare :sealed and a typed lexicals, not any other
>>>>> module's code elsewhere.
>>>>>
>>>>> You absolutely *can* use sealed.pm outside mod_perl, but you need to
>>>>> be wary about using typed lexicals on your method
>>>>> argument stack, because end-users may pass properly derived objects to
>>>>> your method, and will expect your module to use
>>>>> the derived-class's overrides of any method calls in your codebase.
>>>>> Basically the law of the land is that consumers of an API
>>>>> expect all method calls to operate the way *virtual* method calls work
>>>>> in Java/C++. However, what you do internally with API's
>>>>> outside of your published API's argument stack is fair game for
>>>>> :sealed. My advice that it's only practical to seal XS method calls
>>>>> remains.
>>>>>
Re: sealed.pm v4.0.0 is out
To throw mod_apreq2 into the benchmarking mix, add items to the query
string you are hitting (on enquiry.pl).
In particular, lang=.{en,es,de,fr} will generate UTF-8 European-language
localized output.
On Wed, Aug 31, 2022 at 7:13 PM Joe Schaefer wrote:
> I went ahead and copied my company templates over to the github cms repo,
> so you can run enquiry.pl yourself
> (once you edit the @TEMPLATE_DIRS path to point at your checkout). You
> will see sealed.pm at work in the
> httpd error logs.
>
> On Wed, Aug 31, 2022 at 1:02 PM Joe Schaefer wrote:
>
>> For my part in this story, v4.0.0 is the end of the line. This release
>> solves every business problem my own company
>> had with prior releases, so I'm satisfied with where it lies.
>>
>> But it is not perfect by any stretch. To take it to the level where it
>> needs to be someday, B::Generate's maintainers need to be reliable
>> partners with the future maintainers of sealed.pm, to deal with whatever
>> long-range support issues crop up as perlguts invariably
>> undergoes changes that break the undocumented assumptions I've made in
>> getting this into workable condition.
>>
>> What do you think about the idea of putting sealed.pm into the modperl
>> project, vs. a stand-alone on CPAN?
>>
>> On Wed, Aug 31, 2022 at 10:53 AM Joe Schaefer wrote:
>>
>>> In the end, the surgery we do (to method_named), is to replace the prior
>>> $op's next() pointer to point at the $gv op we copied from
>>> a known subroutine's op-tree (that uses a typical subroutine call
>>> instead of a method lookup). Since we relocated that next() pointer,
>>> we need to decrement the internal refcnt for the method_named op to
>>> avoid leaks/segfaults during garbage collection of the ithread.
>>>
>>> None of the many issues Doug faced back in 2000 to do this on a more
>>> generic level actually need to be done for this implementation.
>>> You just need to know that any code that tries to walk this tree (eg
>>> B::Deparse) post-tweaks may choke on the zombie method_named
>>> op lying around in one of the sibling() linked lists. That probably
>>> includes the ithread-cloniing mechanism itself, so only use :sealed
>>> post ithread construction, not prior to it.
>>>
>>> On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer
>>> wrote:
>>>
>>>> The :sealed attribute is a statement about a class's @ISA: you are
>>>> saying you are using its compile-time setting.
>>>> And because we invoke $class->can to do the lookup, module authors who
>>>> override UNIVERSAL::can() with a customized
>>>> one can support AUTOLOADed methods themselves.
>>>>
>>>> Under :sealed, you control which lexical object references you want to
>>>> use compile-time method lookups (via can()),
>>>> by declaring them with a class (type), or avoiding doing that in the
>>>> lexical's declaration. It only impacts your subroutine
>>>> definitions that declare :sealed and a typed lexicals, not any other
>>>> module's code elsewhere.
>>>>
>>>> You absolutely *can* use sealed.pm outside mod_perl, but you need to
>>>> be wary about using typed lexicals on your method
>>>> argument stack, because end-users may pass properly derived objects to
>>>> your method, and will expect your module to use
>>>> the derived-class's overrides of any method calls in your codebase.
>>>> Basically the law of the land is that consumers of an API
>>>> expect all method calls to operate the way *virtual* method calls work
>>>> in Java/C++. However, what you do internally with API's
>>>> outside of your published API's argument stack is fair game for
>>>> :sealed. My advice that it's only practical to seal XS method calls
>>>> remains.
>>>>
>>>> On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer
>>>> wrote:
>>>>
>>>>> Submitted a Pull Request for the Generate.xs patch:
>>>>> https://github.com/rurban/b-generate/pull/2
>>>>> Added more comments to sealed.pm to explain the rationale behind the
>>>>> # replace $methop logic,
>>>>> since it differs from what Doug did back in 2000.
>>>>>
>>>>> On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer
>>>>> wrote:
>>>>>
>>>>>> Take a walk down history lane with me here:
>>>>>> https://www.perl.com/pub/2000/06/dougpatch.html/
>>>>&g
Re: sealed.pm v4.0.0 is out
I went ahead and copied my company templates over to the github cms repo, so you can run enquiry.pl yourself (once you edit the @TEMPLATE_DIRS path to point at your checkout). You will see sealed.pm at work in the httpd error logs. On Wed, Aug 31, 2022 at 1:02 PM Joe Schaefer wrote: > For my part in this story, v4.0.0 is the end of the line. This release > solves every business problem my own company > had with prior releases, so I'm satisfied with where it lies. > > But it is not perfect by any stretch. To take it to the level where it > needs to be someday, B::Generate's maintainers need to be reliable > partners with the future maintainers of sealed.pm, to deal with whatever > long-range support issues crop up as perlguts invariably > undergoes changes that break the undocumented assumptions I've made in > getting this into workable condition. > > What do you think about the idea of putting sealed.pm into the modperl > project, vs. a stand-alone on CPAN? > > On Wed, Aug 31, 2022 at 10:53 AM Joe Schaefer wrote: > >> In the end, the surgery we do (to method_named), is to replace the prior >> $op's next() pointer to point at the $gv op we copied from >> a known subroutine's op-tree (that uses a typical subroutine call instead >> of a method lookup). Since we relocated that next() pointer, >> we need to decrement the internal refcnt for the method_named op to avoid >> leaks/segfaults during garbage collection of the ithread. >> >> None of the many issues Doug faced back in 2000 to do this on a more >> generic level actually need to be done for this implementation. >> You just need to know that any code that tries to walk this tree (eg >> B::Deparse) post-tweaks may choke on the zombie method_named >> op lying around in one of the sibling() linked lists. That probably >> includes the ithread-cloniing mechanism itself, so only use :sealed >> post ithread construction, not prior to it. >> >> On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer wrote: >> >>> The :sealed attribute is a statement about a class's @ISA: you are >>> saying you are using its compile-time setting. >>> And because we invoke $class->can to do the lookup, module authors who >>> override UNIVERSAL::can() with a customized >>> one can support AUTOLOADed methods themselves. >>> >>> Under :sealed, you control which lexical object references you want to >>> use compile-time method lookups (via can()), >>> by declaring them with a class (type), or avoiding doing that in the >>> lexical's declaration. It only impacts your subroutine >>> definitions that declare :sealed and a typed lexicals, not any other >>> module's code elsewhere. >>> >>> You absolutely *can* use sealed.pm outside mod_perl, but you need to be >>> wary about using typed lexicals on your method >>> argument stack, because end-users may pass properly derived objects to >>> your method, and will expect your module to use >>> the derived-class's overrides of any method calls in your codebase. >>> Basically the law of the land is that consumers of an API >>> expect all method calls to operate the way *virtual* method calls work >>> in Java/C++. However, what you do internally with API's >>> outside of your published API's argument stack is fair game for >>> :sealed. My advice that it's only practical to seal XS method calls >>> remains. >>> >>> On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer wrote: >>> >>>> Submitted a Pull Request for the Generate.xs patch: >>>> https://github.com/rurban/b-generate/pull/2 >>>> Added more comments to sealed.pm to explain the rationale behind the # >>>> replace $methop logic, >>>> since it differs from what Doug did back in 2000. >>>> >>>> On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer >>>> wrote: >>>> >>>>> Take a walk down history lane with me here: >>>>> https://www.perl.com/pub/2000/06/dougpatch.html/ >>>>> >>>>> Like ithreads, the idea was sparked from Gurusamy's genius, coded up >>>>> by Doug, and largely forgotten by p5p politics. >>>>> It's not that it couldn't be done, they arrived at the place where it >>>>> *shouldn't* be done, which was deflating for mod_perl fans. >>>>> Simon Couzens made a lot of inroads since, with modularized Perl >>>>> compilers and B::Generate, but it wasn't until >>>>> Perl7 that I was motivated to try any way forward, on a more limited, >>>>>
Re: sealed.pm v4.0.0 is out
For my part in this story, v4.0.0 is the end of the line. This release solves every business problem my own company had with prior releases, so I'm satisfied with where it lies. But it is not perfect by any stretch. To take it to the level where it needs to be someday, B::Generate's maintainers need to be reliable partners with the future maintainers of sealed.pm, to deal with whatever long-range support issues crop up as perlguts invariably undergoes changes that break the undocumented assumptions I've made in getting this into workable condition. What do you think about the idea of putting sealed.pm into the modperl project, vs. a stand-alone on CPAN? On Wed, Aug 31, 2022 at 10:53 AM Joe Schaefer wrote: > In the end, the surgery we do (to method_named), is to replace the prior > $op's next() pointer to point at the $gv op we copied from > a known subroutine's op-tree (that uses a typical subroutine call instead > of a method lookup). Since we relocated that next() pointer, > we need to decrement the internal refcnt for the method_named op to avoid > leaks/segfaults during garbage collection of the ithread. > > None of the many issues Doug faced back in 2000 to do this on a more > generic level actually need to be done for this implementation. > You just need to know that any code that tries to walk this tree (eg > B::Deparse) post-tweaks may choke on the zombie method_named > op lying around in one of the sibling() linked lists. That probably > includes the ithread-cloniing mechanism itself, so only use :sealed > post ithread construction, not prior to it. > > On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer wrote: > >> The :sealed attribute is a statement about a class's @ISA: you are saying >> you are using its compile-time setting. >> And because we invoke $class->can to do the lookup, module authors who >> override UNIVERSAL::can() with a customized >> one can support AUTOLOADed methods themselves. >> >> Under :sealed, you control which lexical object references you want to >> use compile-time method lookups (via can()), >> by declaring them with a class (type), or avoiding doing that in the >> lexical's declaration. It only impacts your subroutine >> definitions that declare :sealed and a typed lexicals, not any other >> module's code elsewhere. >> >> You absolutely *can* use sealed.pm outside mod_perl, but you need to be >> wary about using typed lexicals on your method >> argument stack, because end-users may pass properly derived objects to >> your method, and will expect your module to use >> the derived-class's overrides of any method calls in your codebase. >> Basically the law of the land is that consumers of an API >> expect all method calls to operate the way *virtual* method calls work in >> Java/C++. However, what you do internally with API's >> outside of your published API's argument stack is fair game for :sealed. >> My advice that it's only practical to seal XS method calls remains. >> >> On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer wrote: >> >>> Submitted a Pull Request for the Generate.xs patch: >>> https://github.com/rurban/b-generate/pull/2 >>> Added more comments to sealed.pm to explain the rationale behind the # >>> replace $methop logic, >>> since it differs from what Doug did back in 2000. >>> >>> On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer wrote: >>> >>>> Take a walk down history lane with me here: >>>> https://www.perl.com/pub/2000/06/dougpatch.html/ >>>> >>>> Like ithreads, the idea was sparked from Gurusamy's genius, coded up by >>>> Doug, and largely forgotten by p5p politics. >>>> It's not that it couldn't be done, they arrived at the place where it >>>> *shouldn't* be done, which was deflating for mod_perl fans. >>>> Simon Couzens made a lot of inroads since, with modularized Perl >>>> compilers and B::Generate, but it wasn't until >>>> Perl7 that I was motivated to try any way forward, on a more limited, >>>> controllable scale. >>>> >>>> What do you think? How should this piece of the mod_perl puzzle fit in >>>> to the CPAN universe? >>>> >>>> On Tue, Aug 30, 2022 at 2:12 PM Joe Schaefer >>>> wrote: >>>> >>>>> Every method call that's implemented in XS is looked-up at >>>>> compile-time in that script, even for class methods. >>>>> That's the sweet spot for :sealed. The only other things I do with it >>>>> are a few hot methods in Dotiac::DTL::Core, but that's probably not worth >>>>
Re: h2c benchmarks with same Ubuntu tune as before
*100_000 simultaneous requests. On Wed, Aug 31, 2022 at 12:41 PM Joe Schaefer wrote: > To explain the new-new here, with HTTP/2 comes this whole new idea of > multiplexed "HTTP channels" within a single TCP connection. In this > benchmark, each of the 1000 concurrent tcp connections has 100 multiplexed > requests to the same URL as on the command line. > The reason mod_http2 need threads is to explode these multiplexed channels > into independent requests within the same server process context. > Otherwise it'd have to queue them (it could, but really not the point of > multiplexing in the spec). > In effect, you are seeing my laptop respond to 1 simultaneous requests > for that URL. Most of this is serialized by the thread limits baked into > mpm_event.conf and perl.conf, but it's still standing at the end of the > exercise. > > On Mon, Aug 29, 2022 at 10:02 PM wrote: > >> h2load -n 10 -c 1000 -m 100 http://localhost/perl-script/enquiry.pl >> >> starting benchmark... >> >> spawning thread #0: 1000 total client(s). 10 total requests >> >> Application protocol: h2c >> >> progress: 10% done >> >> progress: 20% done >> >> progress: 30% done >> >> progress: 40% done >> >> progress: 50% done >> >> progress: 60% done >> >> progress: 70% done >> >> progress: 80% done >> >> progress: 90% done >> >> progress: 100% done >> >> >> >> finished in 11.60s, 8624.38 req/s, 11.13MB/s >> >> requests: 10 total, 10 started, 10 done, 10 succeeded, 0 >> failed, 0 errored, 0 timeout >> >> status codes: 10 2xx, 0 3xx, 0 4xx, 0 5xx >> >> traffic: 129.04MB (135312547) total, 560.93KB (574391) headers (space >> savings 95.51%), 126.74MB (13290) data min >> max mean sd+/- sd >> >> time for request: 225.73ms 11.31s 5.76s 3.09s58.62% >> >> time for connect:15.40ms 212.74ms 62.57ms 54.73ms87.50% >> >> time to 1st byte: 261.01ms 9.04s 3.00s 2.01s68.00% >> >> req/s : 8.70 68.06 15.649.7385.70% >> >> >> >> >> > > > -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: h2c benchmarks with same Ubuntu tune as before
To explain the new-new here, with HTTP/2 comes this whole new idea of multiplexed "HTTP channels" within a single TCP connection. In this benchmark, each of the 1000 concurrent tcp connections has 100 multiplexed requests to the same URL as on the command line. The reason mod_http2 need threads is to explode these multiplexed channels into independent requests within the same server process context. Otherwise it'd have to queue them (it could, but really not the point of multiplexing in the spec). In effect, you are seeing my laptop respond to 1 simultaneous requests for that URL. Most of this is serialized by the thread limits baked into mpm_event.conf and perl.conf, but it's still standing at the end of the exercise. On Mon, Aug 29, 2022 at 10:02 PM wrote: > h2load -n 10 -c 1000 -m 100 http://localhost/perl-script/enquiry.pl > > starting benchmark... > > spawning thread #0: 1000 total client(s). 10 total requests > > Application protocol: h2c > > progress: 10% done > > progress: 20% done > > progress: 30% done > > progress: 40% done > > progress: 50% done > > progress: 60% done > > progress: 70% done > > progress: 80% done > > progress: 90% done > > progress: 100% done > > > > finished in 11.60s, 8624.38 req/s, 11.13MB/s > > requests: 10 total, 10 started, 10 done, 10 succeeded, 0 > failed, 0 errored, 0 timeout > > status codes: 10 2xx, 0 3xx, 0 4xx, 0 5xx > > traffic: 129.04MB (135312547) total, 560.93KB (574391) headers (space > savings 95.51%), 126.74MB (13290) data min > max mean sd+/- sd > > time for request: 225.73ms 11.31s 5.76s 3.09s58.62% > > time for connect:15.40ms212.74ms 62.57ms 54.73ms87.50% > > time to 1st byte: 261.01ms 9.04s 3.00s 2.01s68.00% > > req/s : 8.70 68.06 15.649.7385.70% > > > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: sealed.pm v4.0.0 is out
In the end, the surgery we do (to method_named), is to replace the prior $op's next() pointer to point at the $gv op we copied from a known subroutine's op-tree (that uses a typical subroutine call instead of a method lookup). Since we relocated that next() pointer, we need to decrement the internal refcnt for the method_named op to avoid leaks/segfaults during garbage collection of the ithread. None of the many issues Doug faced back in 2000 to do this on a more generic level actually need to be done for this implementation. You just need to know that any code that tries to walk this tree (eg B::Deparse) post-tweaks may choke on the zombie method_named op lying around in one of the sibling() linked lists. That probably includes the ithread-cloniing mechanism itself, so only use :sealed post ithread construction, not prior to it. On Wed, Aug 31, 2022 at 10:27 AM Joe Schaefer wrote: > The :sealed attribute is a statement about a class's @ISA: you are saying > you are using its compile-time setting. > And because we invoke $class->can to do the lookup, module authors who > override UNIVERSAL::can() with a customized > one can support AUTOLOADed methods themselves. > > Under :sealed, you control which lexical object references you want to use > compile-time method lookups (via can()), > by declaring them with a class (type), or avoiding doing that in the > lexical's declaration. It only impacts your subroutine > definitions that declare :sealed and a typed lexicals, not any other > module's code elsewhere. > > You absolutely *can* use sealed.pm outside mod_perl, but you need to be > wary about using typed lexicals on your method > argument stack, because end-users may pass properly derived objects to > your method, and will expect your module to use > the derived-class's overrides of any method calls in your codebase. > Basically the law of the land is that consumers of an API > expect all method calls to operate the way *virtual* method calls work in > Java/C++. However, what you do internally with API's > outside of your published API's argument stack is fair game for :sealed. > My advice that it's only practical to seal XS method calls remains. > > On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer wrote: > >> Submitted a Pull Request for the Generate.xs patch: >> https://github.com/rurban/b-generate/pull/2 >> Added more comments to sealed.pm to explain the rationale behind the # >> replace $methop logic, >> since it differs from what Doug did back in 2000. >> >> On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer wrote: >> >>> Take a walk down history lane with me here: >>> https://www.perl.com/pub/2000/06/dougpatch.html/ >>> >>> Like ithreads, the idea was sparked from Gurusamy's genius, coded up by >>> Doug, and largely forgotten by p5p politics. >>> It's not that it couldn't be done, they arrived at the place where it >>> *shouldn't* be done, which was deflating for mod_perl fans. >>> Simon Couzens made a lot of inroads since, with modularized Perl >>> compilers and B::Generate, but it wasn't until >>> Perl7 that I was motivated to try any way forward, on a more limited, >>> controllable scale. >>> >>> What do you think? How should this piece of the mod_perl puzzle fit in >>> to the CPAN universe? >>> >>> On Tue, Aug 30, 2022 at 2:12 PM Joe Schaefer wrote: >>> >>>> Every method call that's implemented in XS is looked-up at compile-time >>>> in that script, even for class methods. >>>> That's the sweet spot for :sealed. The only other things I do with it >>>> are a few hot methods in Dotiac::DTL::Core, but that's probably not worth >>>> the bother. >>>> >>>> On Tue, Aug 30, 2022 at 1:14 PM Joe Schaefer >>>> wrote: >>>> >>>>> Just look through my commit history on this sample Registry script to >>>>> see what's involved in getting sealed activated on your scripts. >>>>> >>>>> https://github.com/SunStarSys/cms/blob/master/enquiry.pl >>>>> >>>>> On Tue, Aug 30, 2022 at 1:12 PM Joe Schaefer >>>>> wrote: >>>>> >>>>>> It'd be pretty harmless to apply the RegistryCooker.pm patch once we >>>>>> find a home for sealed.pm (either in this project or as a >>>>>> stand-alone pragma on CPAN). >>>>>> Nothing will segfault without consciously using types on your lexical >>>>>> object reference declarations; otherwise it's a giant noop. >>>>>> >>>>>> On Tue, Aug 30, 2022 at 12:53 PM
Re: sealed.pm v4.0.0 is out
The :sealed attribute is a statement about a class's @ISA: you are saying you are using its compile-time setting. And because we invoke $class->can to do the lookup, module authors who override UNIVERSAL::can() with a customized one can support AUTOLOADed methods themselves. Under :sealed, you control which lexical object references you want to use compile-time method lookups (via can()), by declaring them with a class (type), or avoiding doing that in the lexical's declaration. It only impacts your subroutine definitions that declare :sealed and a typed lexicals, not any other module's code elsewhere. You absolutely *can* use sealed.pm outside mod_perl, but you need to be wary about using typed lexicals on your method argument stack, because end-users may pass properly derived objects to your method, and will expect your module to use the derived-class's overrides of any method calls in your codebase. Basically the law of the land is that consumers of an API expect all method calls to operate the way *virtual* method calls work in Java/C++. However, what you do internally with API's outside of your published API's argument stack is fair game for :sealed. My advice that it's only practical to seal XS method calls remains. On Wed, Aug 31, 2022 at 9:52 AM Joe Schaefer wrote: > Submitted a Pull Request for the Generate.xs patch: > https://github.com/rurban/b-generate/pull/2 > Added more comments to sealed.pm to explain the rationale behind the # > replace $methop logic, > since it differs from what Doug did back in 2000. > > On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer wrote: > >> Take a walk down history lane with me here: >> https://www.perl.com/pub/2000/06/dougpatch.html/ >> >> Like ithreads, the idea was sparked from Gurusamy's genius, coded up by >> Doug, and largely forgotten by p5p politics. >> It's not that it couldn't be done, they arrived at the place where it >> *shouldn't* be done, which was deflating for mod_perl fans. >> Simon Couzens made a lot of inroads since, with modularized Perl >> compilers and B::Generate, but it wasn't until >> Perl7 that I was motivated to try any way forward, on a more limited, >> controllable scale. >> >> What do you think? How should this piece of the mod_perl puzzle fit in >> to the CPAN universe? >> >> On Tue, Aug 30, 2022 at 2:12 PM Joe Schaefer wrote: >> >>> Every method call that's implemented in XS is looked-up at compile-time >>> in that script, even for class methods. >>> That's the sweet spot for :sealed. The only other things I do with it >>> are a few hot methods in Dotiac::DTL::Core, but that's probably not worth >>> the bother. >>> >>> On Tue, Aug 30, 2022 at 1:14 PM Joe Schaefer wrote: >>> >>>> Just look through my commit history on this sample Registry script to >>>> see what's involved in getting sealed activated on your scripts. >>>> >>>> https://github.com/SunStarSys/cms/blob/master/enquiry.pl >>>> >>>> On Tue, Aug 30, 2022 at 1:12 PM Joe Schaefer >>>> wrote: >>>> >>>>> It'd be pretty harmless to apply the RegistryCooker.pm patch once we >>>>> find a home for sealed.pm (either in this project or as a stand-alone >>>>> pragma on CPAN). >>>>> Nothing will segfault without consciously using types on your lexical >>>>> object reference declarations; otherwise it's a giant noop. >>>>> >>>>> On Tue, Aug 30, 2022 at 12:53 PM Joe Schaefer >>>>> wrote: >>>>> >>>>>> If you really beat the hell out of it thread-wise, sealed.pm v4.0.0 >>>>>> will still segfault, but there's not much more I can do with the code at >>>>>> this point to prevent that. >>>>>> B::Generate doesn't really support what I'm doing here, which is to >>>>>> do surgery on an existing op-tree, instead of just playing around with a >>>>>> user-generated one. >>>>>> There's no good way to remove the target "method_named" op that we're >>>>>> replacing with a gv_op. If that can't be supported using B::OP APIs, >>>>>> then >>>>>> it should >>>>>> be handled from perl itself. The problem is that the politics around >>>>>> the feature were never resolved, because nobody wants to change the >>>>>> default >>>>>> "virtual method" >>>>>> behavior of Perl's OO-runtime-lookups. Now with the new :sealed >>>>>> SUBROUTINE ATTRIBUTE, it's only enabled fo
Re: sealed.pm v4.0.0 is out
Submitted a Pull Request for the Generate.xs patch:
https://github.com/rurban/b-generate/pull/2
Added more comments to sealed.pm to explain the rationale behind the #
replace $methop logic,
since it differs from what Doug did back in 2000.
On Tue, Aug 30, 2022 at 2:52 PM Joe Schaefer wrote:
> Take a walk down history lane with me here:
> https://www.perl.com/pub/2000/06/dougpatch.html/
>
> Like ithreads, the idea was sparked from Gurusamy's genius, coded up by
> Doug, and largely forgotten by p5p politics.
> It's not that it couldn't be done, they arrived at the place where it
> *shouldn't* be done, which was deflating for mod_perl fans.
> Simon Couzens made a lot of inroads since, with modularized Perl compilers
> and B::Generate, but it wasn't until
> Perl7 that I was motivated to try any way forward, on a more limited,
> controllable scale.
>
> What do you think? How should this piece of the mod_perl puzzle fit in to
> the CPAN universe?
>
> On Tue, Aug 30, 2022 at 2:12 PM Joe Schaefer wrote:
>
>> Every method call that's implemented in XS is looked-up at compile-time
>> in that script, even for class methods.
>> That's the sweet spot for :sealed. The only other things I do with it
>> are a few hot methods in Dotiac::DTL::Core, but that's probably not worth
>> the bother.
>>
>> On Tue, Aug 30, 2022 at 1:14 PM Joe Schaefer wrote:
>>
>>> Just look through my commit history on this sample Registry script to
>>> see what's involved in getting sealed activated on your scripts.
>>>
>>> https://github.com/SunStarSys/cms/blob/master/enquiry.pl
>>>
>>> On Tue, Aug 30, 2022 at 1:12 PM Joe Schaefer wrote:
>>>
>>>> It'd be pretty harmless to apply the RegistryCooker.pm patch once we
>>>> find a home for sealed.pm (either in this project or as a stand-alone
>>>> pragma on CPAN).
>>>> Nothing will segfault without consciously using types on your lexical
>>>> object reference declarations; otherwise it's a giant noop.
>>>>
>>>> On Tue, Aug 30, 2022 at 12:53 PM Joe Schaefer
>>>> wrote:
>>>>
>>>>> If you really beat the hell out of it thread-wise, sealed.pm v4.0.0
>>>>> will still segfault, but there's not much more I can do with the code at
>>>>> this point to prevent that.
>>>>> B::Generate doesn't really support what I'm doing here, which is to do
>>>>> surgery on an existing op-tree, instead of just playing around with a
>>>>> user-generated one.
>>>>> There's no good way to remove the target "method_named" op that we're
>>>>> replacing with a gv_op. If that can't be supported using B::OP APIs, then
>>>>> it should
>>>>> be handled from perl itself. The problem is that the politics around
>>>>> the feature were never resolved, because nobody wants to change the
>>>>> default
>>>>> "virtual method"
>>>>> behavior of Perl's OO-runtime-lookups. Now with the new :sealed
>>>>> SUBROUTINE ATTRIBUTE, it's only enabled for people (like us) who want it
>>>>> conditionally applied,
>>>>> just like we do for the :method attribute.
>>>>>
>>>>> On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer
>>>>> wrote:
>>>>>
>>>>>> Someday this patch might be interesting:
>>>>>>
>>>>>> diff -u RegistryCooker.pm~ RegistryCooker.pm
>>>>>> --- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
>>>>>> +++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
>>>>>> @@ -399,7 +399,8 @@
>>>>>> my $eval = join '',
>>>>>> 'package ',
>>>>>> $self->{PACKAGE}, ";",
>>>>>> -"sub handler {",
>>>>>> +"use base 'sealed';",
>>>>>> +"sub handler :Sealed {",
>>>>>> "local \$0 = '$script_name';",
>>>>>> $nph,
>>>>>> $shebang,
>>>>>>
>>>>>> On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer
>>>>>> wrote:
>>>>>>
>>>>>>> Forgive me for the pent up frustration of having our wonderful
>>>>>>> mod_perl project being completely ignored and abandoned by the Perl
Re: sealed.pm v4.0.0 is out
Take a walk down history lane with me here:
https://www.perl.com/pub/2000/06/dougpatch.html/
Like ithreads, the idea was sparked from Gurusamy's genius, coded up by
Doug, and largely forgotten by p5p politics.
It's not that it couldn't be done, they arrived at the place where it
*shouldn't* be done, which was deflating for mod_perl fans.
Simon Couzens made a lot of inroads since, with modularized Perl compilers
and B::Generate, but it wasn't until
Perl7 that I was motivated to try any way forward, on a more limited,
controllable scale.
What do you think? How should this piece of the mod_perl puzzle fit in to
the CPAN universe?
On Tue, Aug 30, 2022 at 2:12 PM Joe Schaefer wrote:
> Every method call that's implemented in XS is looked-up at compile-time in
> that script, even for class methods.
> That's the sweet spot for :sealed. The only other things I do with it are
> a few hot methods in Dotiac::DTL::Core, but that's probably not worth the
> bother.
>
> On Tue, Aug 30, 2022 at 1:14 PM Joe Schaefer wrote:
>
>> Just look through my commit history on this sample Registry script to see
>> what's involved in getting sealed activated on your scripts.
>>
>> https://github.com/SunStarSys/cms/blob/master/enquiry.pl
>>
>> On Tue, Aug 30, 2022 at 1:12 PM Joe Schaefer wrote:
>>
>>> It'd be pretty harmless to apply the RegistryCooker.pm patch once we
>>> find a home for sealed.pm (either in this project or as a stand-alone
>>> pragma on CPAN).
>>> Nothing will segfault without consciously using types on your lexical
>>> object reference declarations; otherwise it's a giant noop.
>>>
>>> On Tue, Aug 30, 2022 at 12:53 PM Joe Schaefer
>>> wrote:
>>>
>>>> If you really beat the hell out of it thread-wise, sealed.pm v4.0.0
>>>> will still segfault, but there's not much more I can do with the code at
>>>> this point to prevent that.
>>>> B::Generate doesn't really support what I'm doing here, which is to do
>>>> surgery on an existing op-tree, instead of just playing around with a
>>>> user-generated one.
>>>> There's no good way to remove the target "method_named" op that we're
>>>> replacing with a gv_op. If that can't be supported using B::OP APIs, then
>>>> it should
>>>> be handled from perl itself. The problem is that the politics around
>>>> the feature were never resolved, because nobody wants to change the default
>>>> "virtual method"
>>>> behavior of Perl's OO-runtime-lookups. Now with the new :sealed
>>>> SUBROUTINE ATTRIBUTE, it's only enabled for people (like us) who want it
>>>> conditionally applied,
>>>> just like we do for the :method attribute.
>>>>
>>>> On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer
>>>> wrote:
>>>>
>>>>> Someday this patch might be interesting:
>>>>>
>>>>> diff -u RegistryCooker.pm~ RegistryCooker.pm
>>>>> --- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
>>>>> +++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
>>>>> @@ -399,7 +399,8 @@
>>>>> my $eval = join '',
>>>>> 'package ',
>>>>> $self->{PACKAGE}, ";",
>>>>> -"sub handler {",
>>>>> +"use base 'sealed';",
>>>>> +"sub handler :Sealed {",
>>>>> "local \$0 = '$script_name';",
>>>>> $nph,
>>>>> $shebang,
>>>>>
>>>>> On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer
>>>>> wrote:
>>>>>
>>>>>> Forgive me for the pent up frustration of having our wonderful
>>>>>> mod_perl project being completely ignored and abandoned by the Perl
>>>>>> Steering Committee's frivolous lingustic interests over the years since
>>>>>> the
>>>>>> Parrot announcement.
>>>>>> SaywerX gave us a reason to be hopeful again. Let's see what they do
>>>>>> with it.
>>>>>>
>>>>>> On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer
>>>>>> wrote:
>>>>>>
>>>>>>> If the Perl steering committee had any brains left it would have
>>>>>>> capitalized on the perl 5.34 release and Co announced modperl2 ithread
>>&g
Re: sealed.pm v4.0.0 is out
Every method call that's implemented in XS is looked-up at compile-time in
that script, even for class methods.
That's the sweet spot for :sealed. The only other things I do with it are
a few hot methods in Dotiac::DTL::Core, but that's probably not worth the
bother.
On Tue, Aug 30, 2022 at 1:14 PM Joe Schaefer wrote:
> Just look through my commit history on this sample Registry script to see
> what's involved in getting sealed activated on your scripts.
>
> https://github.com/SunStarSys/cms/blob/master/enquiry.pl
>
> On Tue, Aug 30, 2022 at 1:12 PM Joe Schaefer wrote:
>
>> It'd be pretty harmless to apply the RegistryCooker.pm patch once we find
>> a home for sealed.pm (either in this project or as a stand-alone pragma
>> on CPAN).
>> Nothing will segfault without consciously using types on your lexical
>> object reference declarations; otherwise it's a giant noop.
>>
>> On Tue, Aug 30, 2022 at 12:53 PM Joe Schaefer wrote:
>>
>>> If you really beat the hell out of it thread-wise, sealed.pm v4.0.0
>>> will still segfault, but there's not much more I can do with the code at
>>> this point to prevent that.
>>> B::Generate doesn't really support what I'm doing here, which is to do
>>> surgery on an existing op-tree, instead of just playing around with a
>>> user-generated one.
>>> There's no good way to remove the target "method_named" op that we're
>>> replacing with a gv_op. If that can't be supported using B::OP APIs, then
>>> it should
>>> be handled from perl itself. The problem is that the politics around
>>> the feature were never resolved, because nobody wants to change the default
>>> "virtual method"
>>> behavior of Perl's OO-runtime-lookups. Now with the new :sealed
>>> SUBROUTINE ATTRIBUTE, it's only enabled for people (like us) who want it
>>> conditionally applied,
>>> just like we do for the :method attribute.
>>>
>>> On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer
>>> wrote:
>>>
>>>> Someday this patch might be interesting:
>>>>
>>>> diff -u RegistryCooker.pm~ RegistryCooker.pm
>>>> --- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
>>>> +++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
>>>> @@ -399,7 +399,8 @@
>>>> my $eval = join '',
>>>> 'package ',
>>>> $self->{PACKAGE}, ";",
>>>> -"sub handler {",
>>>> +"use base 'sealed';",
>>>> +"sub handler :Sealed {",
>>>> "local \$0 = '$script_name';",
>>>> $nph,
>>>> $shebang,
>>>>
>>>> On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer
>>>> wrote:
>>>>
>>>>> Forgive me for the pent up frustration of having our wonderful
>>>>> mod_perl project being completely ignored and abandoned by the Perl
>>>>> Steering Committee's frivolous lingustic interests over the years since
>>>>> the
>>>>> Parrot announcement.
>>>>> SaywerX gave us a reason to be hopeful again. Let's see what they do
>>>>> with it.
>>>>>
>>>>> On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer
>>>>> wrote:
>>>>>
>>>>>> If the Perl steering committee had any brains left it would have
>>>>>> capitalized on the perl 5.34 release and Co announced modperl2 ithread
>>>>>> compatibility now available with Perl7’s new release.
>>>>>>
>>>>>> Instead they are going to kick the tires on the defaults for
>>>>>> strictures and warnings until nobody cares any more.
>>>>>>
>>>>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>>>>> --
>>>>>> *From:* Joe Schaefer
>>>>>> *Sent:* Monday, August 29, 2022 1:17:17 PM
>>>>>> *To:* mod_perl list
>>>>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>>>>
>>>>>> The only reason I’ve been vacillating about glibc/malloc thread
>>>>>> safety is because I couldn’t fathom the fact that people still believed
>>>>>> modperl isn’t compatible with mpm_event at this point in the Perl7
>>>>>> storyline. The old segfaults of the past tha
Re: sealed.pm v4.0.0 is out
Just look through my commit history on this sample Registry script to see
what's involved in getting sealed activated on your scripts.
https://github.com/SunStarSys/cms/blob/master/enquiry.pl
On Tue, Aug 30, 2022 at 1:12 PM Joe Schaefer wrote:
> It'd be pretty harmless to apply the RegistryCooker.pm patch once we find
> a home for sealed.pm (either in this project or as a stand-alone pragma
> on CPAN).
> Nothing will segfault without consciously using types on your lexical
> object reference declarations; otherwise it's a giant noop.
>
> On Tue, Aug 30, 2022 at 12:53 PM Joe Schaefer wrote:
>
>> If you really beat the hell out of it thread-wise, sealed.pm v4.0.0 will
>> still segfault, but there's not much more I can do with the code at this
>> point to prevent that.
>> B::Generate doesn't really support what I'm doing here, which is to do
>> surgery on an existing op-tree, instead of just playing around with a
>> user-generated one.
>> There's no good way to remove the target "method_named" op that we're
>> replacing with a gv_op. If that can't be supported using B::OP APIs, then
>> it should
>> be handled from perl itself. The problem is that the politics around the
>> feature were never resolved, because nobody wants to change the default
>> "virtual method"
>> behavior of Perl's OO-runtime-lookups. Now with the new :sealed
>> SUBROUTINE ATTRIBUTE, it's only enabled for people (like us) who want it
>> conditionally applied,
>> just like we do for the :method attribute.
>>
>> On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer wrote:
>>
>>> Someday this patch might be interesting:
>>>
>>> diff -u RegistryCooker.pm~ RegistryCooker.pm
>>> --- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
>>> +++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
>>> @@ -399,7 +399,8 @@
>>> my $eval = join '',
>>> 'package ',
>>> $self->{PACKAGE}, ";",
>>> -"sub handler {",
>>> +"use base 'sealed';",
>>> +"sub handler :Sealed {",
>>> "local \$0 = '$script_name';",
>>> $nph,
>>> $shebang,
>>>
>>> On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer wrote:
>>>
>>>> Forgive me for the pent up frustration of having our wonderful mod_perl
>>>> project being completely ignored and abandoned by the Perl Steering
>>>> Committee's frivolous lingustic interests over the years since the Parrot
>>>> announcement.
>>>> SaywerX gave us a reason to be hopeful again. Let's see what they do
>>>> with it.
>>>>
>>>> On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer
>>>> wrote:
>>>>
>>>>> If the Perl steering committee had any brains left it would have
>>>>> capitalized on the perl 5.34 release and Co announced modperl2 ithread
>>>>> compatibility now available with Perl7’s new release.
>>>>>
>>>>> Instead they are going to kick the tires on the defaults for
>>>>> strictures and warnings until nobody cares any more.
>>>>>
>>>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>>>> --
>>>>> *From:* Joe Schaefer
>>>>> *Sent:* Monday, August 29, 2022 1:17:17 PM
>>>>> *To:* mod_perl list
>>>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>>>
>>>>> The only reason I’ve been vacillating about glibc/malloc thread safety
>>>>> is because I couldn’t fathom the fact that people still believed modperl
>>>>> isn’t compatible with mpm_event at this point in the Perl7 storyline. The
>>>>> old segfaults of the past that happened in glibc malloc were because Perl
>>>>> was corrupting the heap in some other part of the codebase, and there’s no
>>>>> simple way to track it down without a tool like Valgrind, but we weren’t
>>>>> successful with that effort either.
>>>>>
>>>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>>>> --
>>>>> *From:* Joe Schaefer
>>>>> *Sent:* Monday, August 29, 2022 1:08:00 PM
>>>>> *To:* mod_perl list
>>>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>>>
>>>>> Religiously
Re: sealed.pm v4.0.0 is out
It'd be pretty harmless to apply the RegistryCooker.pm patch once we find a
home for sealed.pm (either in this project or as a stand-alone pragma on
CPAN).
Nothing will segfault without consciously using types on your lexical
object reference declarations; otherwise it's a giant noop.
On Tue, Aug 30, 2022 at 12:53 PM Joe Schaefer wrote:
> If you really beat the hell out of it thread-wise, sealed.pm v4.0.0 will
> still segfault, but there's not much more I can do with the code at this
> point to prevent that.
> B::Generate doesn't really support what I'm doing here, which is to do
> surgery on an existing op-tree, instead of just playing around with a
> user-generated one.
> There's no good way to remove the target "method_named" op that we're
> replacing with a gv_op. If that can't be supported using B::OP APIs, then
> it should
> be handled from perl itself. The problem is that the politics around the
> feature were never resolved, because nobody wants to change the default
> "virtual method"
> behavior of Perl's OO-runtime-lookups. Now with the new :sealed
> SUBROUTINE ATTRIBUTE, it's only enabled for people (like us) who want it
> conditionally applied,
> just like we do for the :method attribute.
>
> On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer wrote:
>
>> Someday this patch might be interesting:
>>
>> diff -u RegistryCooker.pm~ RegistryCooker.pm
>> --- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
>> +++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
>> @@ -399,7 +399,8 @@
>> my $eval = join '',
>> 'package ',
>> $self->{PACKAGE}, ";",
>> -"sub handler {",
>> +"use base 'sealed';",
>> +"sub handler :Sealed {",
>> "local \$0 = '$script_name';",
>> $nph,
>> $shebang,
>>
>> On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer wrote:
>>
>>> Forgive me for the pent up frustration of having our wonderful mod_perl
>>> project being completely ignored and abandoned by the Perl Steering
>>> Committee's frivolous lingustic interests over the years since the Parrot
>>> announcement.
>>> SaywerX gave us a reason to be hopeful again. Let's see what they do
>>> with it.
>>>
>>> On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer wrote:
>>>
>>>> If the Perl steering committee had any brains left it would have
>>>> capitalized on the perl 5.34 release and Co announced modperl2 ithread
>>>> compatibility now available with Perl7’s new release.
>>>>
>>>> Instead they are going to kick the tires on the defaults for strictures
>>>> and warnings until nobody cares any more.
>>>>
>>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>>> --
>>>> *From:* Joe Schaefer
>>>> *Sent:* Monday, August 29, 2022 1:17:17 PM
>>>> *To:* mod_perl list
>>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>>
>>>> The only reason I’ve been vacillating about glibc/malloc thread safety
>>>> is because I couldn’t fathom the fact that people still believed modperl
>>>> isn’t compatible with mpm_event at this point in the Perl7 storyline. The
>>>> old segfaults of the past that happened in glibc malloc were because Perl
>>>> was corrupting the heap in some other part of the codebase, and there’s no
>>>> simple way to track it down without a tool like Valgrind, but we weren’t
>>>> successful with that effort either.
>>>>
>>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>>> --
>>>> *From:* Joe Schaefer
>>>> *Sent:* Monday, August 29, 2022 1:08:00 PM
>>>> *To:* mod_perl list
>>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>>
>>>> Religiously avoid setting up per request ithread environment variables.
>>>> Just use PerlSetEnv in your Webserver config. Everything we did in modperl
>>>> to support CGI scripts is a train wreck.
>>>>
>>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>>> --
>>>> *From:* Joe Schaefer
>>>> *Sent:* Monday, August 29, 2022 1:04:03 PM
>>>> *To:* mod_perl list
>>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>>
>>>> Look into reducing the scope of your int
Re: sealed.pm v4.0.0 is out
If you really beat the hell out of it thread-wise, sealed.pm v4.0.0 will
still segfault, but there's not much more I can do with the code at this
point to prevent that.
B::Generate doesn't really support what I'm doing here, which is to do
surgery on an existing op-tree, instead of just playing around with a
user-generated one.
There's no good way to remove the target "method_named" op that we're
replacing with a gv_op. If that can't be supported using B::OP APIs, then
it should
be handled from perl itself. The problem is that the politics around the
feature were never resolved, because nobody wants to change the default
"virtual method"
behavior of Perl's OO-runtime-lookups. Now with the new :sealed SUBROUTINE
ATTRIBUTE, it's only enabled for people (like us) who want it conditionally
applied,
just like we do for the :method attribute.
On Tue, Aug 30, 2022 at 11:26 AM Joe Schaefer wrote:
> Someday this patch might be interesting:
>
> diff -u RegistryCooker.pm~ RegistryCooker.pm
> --- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
> +++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
> @@ -399,7 +399,8 @@
> my $eval = join '',
> 'package ',
> $self->{PACKAGE}, ";",
> -"sub handler {",
> +"use base 'sealed';",
> +"sub handler :Sealed {",
> "local \$0 = '$script_name';",
> $nph,
> $shebang,
>
> On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer wrote:
>
>> Forgive me for the pent up frustration of having our wonderful mod_perl
>> project being completely ignored and abandoned by the Perl Steering
>> Committee's frivolous lingustic interests over the years since the Parrot
>> announcement.
>> SaywerX gave us a reason to be hopeful again. Let's see what they do
>> with it.
>>
>> On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer wrote:
>>
>>> If the Perl steering committee had any brains left it would have
>>> capitalized on the perl 5.34 release and Co announced modperl2 ithread
>>> compatibility now available with Perl7’s new release.
>>>
>>> Instead they are going to kick the tires on the defaults for strictures
>>> and warnings until nobody cares any more.
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>> --
>>> *From:* Joe Schaefer
>>> *Sent:* Monday, August 29, 2022 1:17:17 PM
>>> *To:* mod_perl list
>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>
>>> The only reason I’ve been vacillating about glibc/malloc thread safety
>>> is because I couldn’t fathom the fact that people still believed modperl
>>> isn’t compatible with mpm_event at this point in the Perl7 storyline. The
>>> old segfaults of the past that happened in glibc malloc were because Perl
>>> was corrupting the heap in some other part of the codebase, and there’s no
>>> simple way to track it down without a tool like Valgrind, but we weren’t
>>> successful with that effort either.
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>> --
>>> *From:* Joe Schaefer
>>> *Sent:* Monday, August 29, 2022 1:08:00 PM
>>> *To:* mod_perl list
>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>
>>> Religiously avoid setting up per request ithread environment variables.
>>> Just use PerlSetEnv in your Webserver config. Everything we did in modperl
>>> to support CGI scripts is a train wreck.
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>> ------
>>> *From:* Joe Schaefer
>>> *Sent:* Monday, August 29, 2022 1:04:03 PM
>>> *To:* mod_perl list
>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>
>>> Look into reducing the scope of your interpreters down from the request
>>> level to the handler level. If all you are doing is running registry
>>> scripts, you will get even better scaling out of just a few ithreads per
>>> worker process.
>>>
>>> Get Outlook for iOS <https://aka.ms/o0ukef>
>>> --
>>> *From:* Joe Schaefer
>>> *Sent:* Monday, August 29, 2022 12:57:14 PM
>>> *To:* mod_perl list
>>> *Subject:* Re: sealed.pm v4.0.0 is out
>>>
>>> The only impact to your work with modperl is that you will need to
>>> assess the ithread-safety of your dependent XS-based modules. For ex
Re: sealed.pm v4.0.0 is out
Someday this patch might be interesting:
diff -u RegistryCooker.pm~ RegistryCooker.pm
--- RegistryCooker.pm~ 2022-08-30 11:10:19.790171019 -0400
+++ RegistryCooker.pm 2022-08-30 11:12:34.319572045 -0400
@@ -399,7 +399,8 @@
my $eval = join '',
'package ',
$self->{PACKAGE}, ";",
-"sub handler {",
+"use base 'sealed';",
+"sub handler :Sealed {",
"local \$0 = '$script_name';",
$nph,
$shebang,
On Mon, Aug 29, 2022 at 2:21 PM Joe Schaefer wrote:
> Forgive me for the pent up frustration of having our wonderful mod_perl
> project being completely ignored and abandoned by the Perl Steering
> Committee's frivolous lingustic interests over the years since the Parrot
> announcement.
> SaywerX gave us a reason to be hopeful again. Let's see what they do with
> it.
>
> On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer wrote:
>
>> If the Perl steering committee had any brains left it would have
>> capitalized on the perl 5.34 release and Co announced modperl2 ithread
>> compatibility now available with Perl7’s new release.
>>
>> Instead they are going to kick the tires on the defaults for strictures
>> and warnings until nobody cares any more.
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 1:17:17 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> The only reason I’ve been vacillating about glibc/malloc thread safety is
>> because I couldn’t fathom the fact that people still believed modperl isn’t
>> compatible with mpm_event at this point in the Perl7 storyline. The old
>> segfaults of the past that happened in glibc malloc were because Perl was
>> corrupting the heap in some other part of the codebase, and there’s no
>> simple way to track it down without a tool like Valgrind, but we weren’t
>> successful with that effort either.
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 1:08:00 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> Religiously avoid setting up per request ithread environment variables.
>> Just use PerlSetEnv in your Webserver config. Everything we did in modperl
>> to support CGI scripts is a train wreck.
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 1:04:03 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> Look into reducing the scope of your interpreters down from the request
>> level to the handler level. If all you are doing is running registry
>> scripts, you will get even better scaling out of just a few ithreads per
>> worker process.
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 12:57:14 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> The only impact to your work with modperl is that you will need to assess
>> the ithread-safety of your dependent XS-based modules. For example, use a
>> JSON::XS thread safe alternative- there are several.
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 12:49:22 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> There is a mountain of awful advice floating around about ithreads,
>> including pretty much everything going on in Raku around adopting the
>> node.js model instead. It is safe to ignore all that now that SawyerX spit
>> polished all of the perl5 internals.
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> --
>> *From:* Joe Schaefer
>> *Sent:* Monday, August 29, 2022 12:40:43 PM
>> *To:* mod_perl list
>> *Subject:* Re: sealed.pm v4.0.0 is out
>>
>> Many of the performance hacks we’ve encouraged over the years, eg around
>> HTTPD’s lingering close effect, are obsoleted with ithreads. Unless you
>> send flush buckets down the output filter stack yourself, the “response
>> handler” phase exits long before the “connection handler” starts making non
>> blocking so
Re: sealed.pm v4.0.0 is out
Forgive me for the pent up frustration of having our wonderful mod_perl project being completely ignored and abandoned by the Perl Steering Committee's frivolous lingustic interests over the years since the Parrot announcement. SaywerX gave us a reason to be hopeful again. Let's see what they do with it. On Mon, Aug 29, 2022 at 1:34 PM Joe Schaefer wrote: > If the Perl steering committee had any brains left it would have > capitalized on the perl 5.34 release and Co announced modperl2 ithread > compatibility now available with Perl7’s new release. > > Instead they are going to kick the tires on the defaults for strictures > and warnings until nobody cares any more. > > Get Outlook for iOS <https://aka.ms/o0ukef> > ------ > *From:* Joe Schaefer > *Sent:* Monday, August 29, 2022 1:17:17 PM > *To:* mod_perl list > *Subject:* Re: sealed.pm v4.0.0 is out > > The only reason I’ve been vacillating about glibc/malloc thread safety is > because I couldn’t fathom the fact that people still believed modperl isn’t > compatible with mpm_event at this point in the Perl7 storyline. The old > segfaults of the past that happened in glibc malloc were because Perl was > corrupting the heap in some other part of the codebase, and there’s no > simple way to track it down without a tool like Valgrind, but we weren’t > successful with that effort either. > > Get Outlook for iOS <https://aka.ms/o0ukef> > -- > *From:* Joe Schaefer > *Sent:* Monday, August 29, 2022 1:08:00 PM > *To:* mod_perl list > *Subject:* Re: sealed.pm v4.0.0 is out > > Religiously avoid setting up per request ithread environment variables. > Just use PerlSetEnv in your Webserver config. Everything we did in modperl > to support CGI scripts is a train wreck. > > Get Outlook for iOS <https://aka.ms/o0ukef> > -- > *From:* Joe Schaefer > *Sent:* Monday, August 29, 2022 1:04:03 PM > *To:* mod_perl list > *Subject:* Re: sealed.pm v4.0.0 is out > > Look into reducing the scope of your interpreters down from the request > level to the handler level. If all you are doing is running registry > scripts, you will get even better scaling out of just a few ithreads per > worker process. > > Get Outlook for iOS <https://aka.ms/o0ukef> > -- > *From:* Joe Schaefer > *Sent:* Monday, August 29, 2022 12:57:14 PM > *To:* mod_perl list > *Subject:* Re: sealed.pm v4.0.0 is out > > The only impact to your work with modperl is that you will need to assess > the ithread-safety of your dependent XS-based modules. For example, use a > JSON::XS thread safe alternative- there are several. > > Get Outlook for iOS <https://aka.ms/o0ukef> > -- > *From:* Joe Schaefer > *Sent:* Monday, August 29, 2022 12:49:22 PM > *To:* mod_perl list > *Subject:* Re: sealed.pm v4.0.0 is out > > There is a mountain of awful advice floating around about ithreads, > including pretty much everything going on in Raku around adopting the > node.js model instead. It is safe to ignore all that now that SawyerX spit > polished all of the perl5 internals. > > Get Outlook for iOS <https://aka.ms/o0ukef> > -- > *From:* Joe Schaefer > *Sent:* Monday, August 29, 2022 12:40:43 PM > *To:* mod_perl list > *Subject:* Re: sealed.pm v4.0.0 is out > > Many of the performance hacks we’ve encouraged over the years, eg around > HTTPD’s lingering close effect, are obsoleted with ithreads. Unless you > send flush buckets down the output filter stack yourself, the “response > handler” phase exits long before the “connection handler” starts making non > blocking socket system calls. So you need an order of magnitude fewer > ithreads than you do prefork children in a multitier arch. > > Get Outlook for iOS <https://aka.ms/o0ukef> > -- > *From:* Joe Schaefer > *Sent:* Sunday, August 28, 2022 11:09:14 AM > *To:* mod_perl list > *Subject:* Re: sealed.pm v4.0.0 is out > > Benchmark ran on my 2021 Dell Precision Laptop w/ 8 cores + HT (so > 16vCPU) and Ubuntu 22.04 inside WSL2. Never topped 50% avg CPU, and almost > all of the CPU was in userland (not system calls). > > On Sat, Aug 27, 2022 at 11:42 AM wrote: > > See https://sunstarsys.com/essays/perl7-sealed-lexicals. For the full > effect, you will need to build B::Generate with this patched version > instead: https://github.com/SunStarSys/cms/blob/master/Generate.xs > > > > Sample mod_perl config + benchmarks: > > > > > > StartServers 2 > > MinSpareThreads1
Re: sealed.pm v4.0.0 is out
If the Perl steering committee had any brains left it would have capitalized on the perl 5.34 release and Co announced modperl2 ithread compatibility now available with Perl7’s new release. Instead they are going to kick the tires on the defaults for strictures and warnings until nobody cares any more. Get Outlook for iOS<https://aka.ms/o0ukef> From: Joe Schaefer Sent: Monday, August 29, 2022 1:17:17 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out The only reason I’ve been vacillating about glibc/malloc thread safety is because I couldn’t fathom the fact that people still believed modperl isn’t compatible with mpm_event at this point in the Perl7 storyline. The old segfaults of the past that happened in glibc malloc were because Perl was corrupting the heap in some other part of the codebase, and there’s no simple way to track it down without a tool like Valgrind, but we weren’t successful with that effort either. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 1:08:00 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Religiously avoid setting up per request ithread environment variables. Just use PerlSetEnv in your Webserver config. Everything we did in modperl to support CGI scripts is a train wreck. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 1:04:03 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Look into reducing the scope of your interpreters down from the request level to the handler level. If all you are doing is running registry scripts, you will get even better scaling out of just a few ithreads per worker process. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:57:14 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out The only impact to your work with modperl is that you will need to assess the ithread-safety of your dependent XS-based modules. For example, use a JSON::XS thread safe alternative- there are several. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:49:22 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out There is a mountain of awful advice floating around about ithreads, including pretty much everything going on in Raku around adopting the node.js model instead. It is safe to ignore all that now that SawyerX spit polished all of the perl5 internals. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:40:43 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Many of the performance hacks we’ve encouraged over the years, eg around HTTPD’s lingering close effect, are obsoleted with ithreads. Unless you send flush buckets down the output filter stack yourself, the “response handler” phase exits long before the “connection handler” starts making non blocking socket system calls. So you need an order of magnitude fewer ithreads than you do prefork children in a multitier arch. Get Outlook for iOS<https://aka.ms/o0ukef> ____ From: Joe Schaefer Sent: Sunday, August 28, 2022 11:09:14 AM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Benchmark ran on my 2021 Dell Precision Laptop w/ 8 cores + HT (so 16vCPU) and Ubuntu 22.04 inside WSL2. Never topped 50% avg CPU, and almost all of the CPU was in userland (not system calls). On Sat, Aug 27, 2022 at 11:42 AM mailto:j...@sunstarsys.com>> wrote: See https://sunstarsys.com/essays/perl7-sealed-lexicals. For the full effect, you will need to build B::Generate with this patched version instead: https://github.com/SunStarSys/cms/blob/master/Generate.xs Sample mod_perl config + benchmarks: StartServers 2 MinSpareThreads100 MaxSpareThreads500 ThreadLimit 1000 ThreadsPerChild100 MaxRequestWorkers 100 MaxConnectionsPerChild 0 PerlSwitches -T -I/home/joesuf4/src/cms/lib PerlInterpStart 2 PerlInterpMax 4 PerlInterpMinSpare 1 PerlInterpMaxSpare 4 PerlInterpMaxRequests 100 PerlOptions +GlobalRequest Require all granted AddHandler perl-script .pl PerlResponseHandler ModPerl::Registry Options +ExecCGI Require all granted ServerName localhost DocumentRoot /home/joesuf4/src/trunk/content Alias /perl-script /home/joesuf4/src/cms ab -n 1 -c 1000 http://localhost/perl-script/enquiry.pl This is ApacheBench, Version 2.3 <$Revision: 1879490 $>
Re: sealed.pm v4.0.0 is out
The only reason I’ve been vacillating about glibc/malloc thread safety is because I couldn’t fathom the fact that people still believed modperl isn’t compatible with mpm_event at this point in the Perl7 storyline. The old segfaults of the past that happened in glibc malloc were because Perl was corrupting the heap in some other part of the codebase, and there’s no simple way to track it down without a tool like Valgrind, but we weren’t successful with that effort either. Get Outlook for iOS<https://aka.ms/o0ukef> From: Joe Schaefer Sent: Monday, August 29, 2022 1:08:00 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Religiously avoid setting up per request ithread environment variables. Just use PerlSetEnv in your Webserver config. Everything we did in modperl to support CGI scripts is a train wreck. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 1:04:03 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Look into reducing the scope of your interpreters down from the request level to the handler level. If all you are doing is running registry scripts, you will get even better scaling out of just a few ithreads per worker process. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:57:14 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out The only impact to your work with modperl is that you will need to assess the ithread-safety of your dependent XS-based modules. For example, use a JSON::XS thread safe alternative- there are several. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:49:22 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out There is a mountain of awful advice floating around about ithreads, including pretty much everything going on in Raku around adopting the node.js model instead. It is safe to ignore all that now that SawyerX spit polished all of the perl5 internals. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:40:43 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Many of the performance hacks we’ve encouraged over the years, eg around HTTPD’s lingering close effect, are obsoleted with ithreads. Unless you send flush buckets down the output filter stack yourself, the “response handler” phase exits long before the “connection handler” starts making non blocking socket system calls. So you need an order of magnitude fewer ithreads than you do prefork children in a multitier arch. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Sunday, August 28, 2022 11:09:14 AM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Benchmark ran on my 2021 Dell Precision Laptop w/ 8 cores + HT (so 16vCPU) and Ubuntu 22.04 inside WSL2. Never topped 50% avg CPU, and almost all of the CPU was in userland (not system calls). On Sat, Aug 27, 2022 at 11:42 AM mailto:j...@sunstarsys.com>> wrote: See https://sunstarsys.com/essays/perl7-sealed-lexicals. For the full effect, you will need to build B::Generate with this patched version instead: https://github.com/SunStarSys/cms/blob/master/Generate.xs Sample mod_perl config + benchmarks: StartServers 2 MinSpareThreads100 MaxSpareThreads500 ThreadLimit 1000 ThreadsPerChild100 MaxRequestWorkers 100 MaxConnectionsPerChild 0 PerlSwitches -T -I/home/joesuf4/src/cms/lib PerlInterpStart 2 PerlInterpMax 4 PerlInterpMinSpare 1 PerlInterpMaxSpare 4 PerlInterpMaxRequests 100 PerlOptions +GlobalRequest Require all granted AddHandler perl-script .pl PerlResponseHandler ModPerl::Registry Options +ExecCGI Require all granted ServerName localhost DocumentRoot /home/joesuf4/src/trunk/content Alias /perl-script /home/joesuf4/src/cms ab -n 1 -c 1000 http://localhost/perl-script/enquiry.pl This is ApacheBench, Version 2.3 <$Revision: 1879490 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed 1 requests Finished 1 requests Server Software:Apache/2.4.52 Server Hostna
Re: sealed.pm v4.0.0 is out
Religiously avoid setting up per request ithread environment variables. Just use PerlSetEnv in your Webserver config. Everything we did in modperl to support CGI scripts is a train wreck. Get Outlook for iOS<https://aka.ms/o0ukef> From: Joe Schaefer Sent: Monday, August 29, 2022 1:04:03 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Look into reducing the scope of your interpreters down from the request level to the handler level. If all you are doing is running registry scripts, you will get even better scaling out of just a few ithreads per worker process. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:57:14 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out The only impact to your work with modperl is that you will need to assess the ithread-safety of your dependent XS-based modules. For example, use a JSON::XS thread safe alternative- there are several. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:49:22 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out There is a mountain of awful advice floating around about ithreads, including pretty much everything going on in Raku around adopting the node.js model instead. It is safe to ignore all that now that SawyerX spit polished all of the perl5 internals. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:40:43 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Many of the performance hacks we’ve encouraged over the years, eg around HTTPD’s lingering close effect, are obsoleted with ithreads. Unless you send flush buckets down the output filter stack yourself, the “response handler” phase exits long before the “connection handler” starts making non blocking socket system calls. So you need an order of magnitude fewer ithreads than you do prefork children in a multitier arch. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Sunday, August 28, 2022 11:09:14 AM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Benchmark ran on my 2021 Dell Precision Laptop w/ 8 cores + HT (so 16vCPU) and Ubuntu 22.04 inside WSL2. Never topped 50% avg CPU, and almost all of the CPU was in userland (not system calls). On Sat, Aug 27, 2022 at 11:42 AM mailto:j...@sunstarsys.com>> wrote: See https://sunstarsys.com/essays/perl7-sealed-lexicals. For the full effect, you will need to build B::Generate with this patched version instead: https://github.com/SunStarSys/cms/blob/master/Generate.xs Sample mod_perl config + benchmarks: StartServers 2 MinSpareThreads100 MaxSpareThreads500 ThreadLimit 1000 ThreadsPerChild100 MaxRequestWorkers 100 MaxConnectionsPerChild 0 PerlSwitches -T -I/home/joesuf4/src/cms/lib PerlInterpStart 2 PerlInterpMax 4 PerlInterpMinSpare 1 PerlInterpMaxSpare 4 PerlInterpMaxRequests 100 PerlOptions +GlobalRequest Require all granted AddHandler perl-script .pl PerlResponseHandler ModPerl::Registry Options +ExecCGI Require all granted ServerName localhost DocumentRoot /home/joesuf4/src/trunk/content Alias /perl-script /home/joesuf4/src/cms ab -n 1 -c 1000 http://localhost/perl-script/enquiry.pl This is ApacheBench, Version 2.3 <$Revision: 1879490 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed 1 requests Finished 1 requests Server Software:Apache/2.4.52 Server Hostname:localhost Server Port:80 Document Path: /perl-script/enquiry.pl<http://enquiry.pl> Document Length:1329 bytes Concurrency Level: 1000 Time taken for tests: 1.218 seconds Complete requests: 1 Failed requests:0 Total transferred: 1501 bytes HTML transferred: 1329 bytes Requests per second:8207.94 [#/sec] (mean) Time per request: 121.833 [ms] (mean) Time per request: 0.122 [ms] (mean, across all concurrent requests) Transfer rate: 12031.37 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:02
Re: sealed.pm v4.0.0 is out
Look into reducing the scope of your interpreters down from the request level to the handler level. If all you are doing is running registry scripts, you will get even better scaling out of just a few ithreads per worker process. Get Outlook for iOS<https://aka.ms/o0ukef> From: Joe Schaefer Sent: Monday, August 29, 2022 12:57:14 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out The only impact to your work with modperl is that you will need to assess the ithread-safety of your dependent XS-based modules. For example, use a JSON::XS thread safe alternative- there are several. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:49:22 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out There is a mountain of awful advice floating around about ithreads, including pretty much everything going on in Raku around adopting the node.js model instead. It is safe to ignore all that now that SawyerX spit polished all of the perl5 internals. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:40:43 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Many of the performance hacks we’ve encouraged over the years, eg around HTTPD’s lingering close effect, are obsoleted with ithreads. Unless you send flush buckets down the output filter stack yourself, the “response handler” phase exits long before the “connection handler” starts making non blocking socket system calls. So you need an order of magnitude fewer ithreads than you do prefork children in a multitier arch. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Sunday, August 28, 2022 11:09:14 AM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Benchmark ran on my 2021 Dell Precision Laptop w/ 8 cores + HT (so 16vCPU) and Ubuntu 22.04 inside WSL2. Never topped 50% avg CPU, and almost all of the CPU was in userland (not system calls). On Sat, Aug 27, 2022 at 11:42 AM mailto:j...@sunstarsys.com>> wrote: See https://sunstarsys.com/essays/perl7-sealed-lexicals. For the full effect, you will need to build B::Generate with this patched version instead: https://github.com/SunStarSys/cms/blob/master/Generate.xs Sample mod_perl config + benchmarks: StartServers 2 MinSpareThreads100 MaxSpareThreads500 ThreadLimit 1000 ThreadsPerChild100 MaxRequestWorkers 100 MaxConnectionsPerChild 0 PerlSwitches -T -I/home/joesuf4/src/cms/lib PerlInterpStart 2 PerlInterpMax 4 PerlInterpMinSpare 1 PerlInterpMaxSpare 4 PerlInterpMaxRequests 100 PerlOptions +GlobalRequest Require all granted AddHandler perl-script .pl PerlResponseHandler ModPerl::Registry Options +ExecCGI Require all granted ServerName localhost DocumentRoot /home/joesuf4/src/trunk/content Alias /perl-script /home/joesuf4/src/cms ab -n 1 -c 1000 http://localhost/perl-script/enquiry.pl This is ApacheBench, Version 2.3 <$Revision: 1879490 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed 1 requests Finished 1 requests Server Software:Apache/2.4.52 Server Hostname:localhost Server Port:80 Document Path: /perl-script/enquiry.pl<http://enquiry.pl> Document Length:1329 bytes Concurrency Level: 1000 Time taken for tests: 1.218 seconds Complete requests: 1 Failed requests:0 Total transferred: 1501 bytes HTML transferred: 1329 bytes Requests per second:8207.94 [#/sec] (mean) Time per request: 121.833 [ms] (mean) Time per request: 0.122 [ms] (mean, across all concurrent requests) Transfer rate: 12031.37 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:02 6.2 0 24 Processing: 4 93 49.6 82 458 Waiting:1 80 44.5 71 455 Total: 17 95 49.5 84 458 Percentage of the requests served within a certain time (ms) 50% 84 66%100 75%112 80%120 90%147 95%173 98%233 99%318 100%458 (longest request) % pgrep -f apache2 | xargs -n1 p
Re: sealed.pm v4.0.0 is out
The only impact to your work with modperl is that you will need to assess the ithread-safety of your dependent XS-based modules. For example, use a JSON::XS thread safe alternative- there are several. Get Outlook for iOS<https://aka.ms/o0ukef> From: Joe Schaefer Sent: Monday, August 29, 2022 12:49:22 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out There is a mountain of awful advice floating around about ithreads, including pretty much everything going on in Raku around adopting the node.js model instead. It is safe to ignore all that now that SawyerX spit polished all of the perl5 internals. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Monday, August 29, 2022 12:40:43 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Many of the performance hacks we’ve encouraged over the years, eg around HTTPD’s lingering close effect, are obsoleted with ithreads. Unless you send flush buckets down the output filter stack yourself, the “response handler” phase exits long before the “connection handler” starts making non blocking socket system calls. So you need an order of magnitude fewer ithreads than you do prefork children in a multitier arch. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Sunday, August 28, 2022 11:09:14 AM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Benchmark ran on my 2021 Dell Precision Laptop w/ 8 cores + HT (so 16vCPU) and Ubuntu 22.04 inside WSL2. Never topped 50% avg CPU, and almost all of the CPU was in userland (not system calls). On Sat, Aug 27, 2022 at 11:42 AM mailto:j...@sunstarsys.com>> wrote: See https://sunstarsys.com/essays/perl7-sealed-lexicals. For the full effect, you will need to build B::Generate with this patched version instead: https://github.com/SunStarSys/cms/blob/master/Generate.xs Sample mod_perl config + benchmarks: StartServers 2 MinSpareThreads100 MaxSpareThreads500 ThreadLimit 1000 ThreadsPerChild100 MaxRequestWorkers 100 MaxConnectionsPerChild 0 PerlSwitches -T -I/home/joesuf4/src/cms/lib PerlInterpStart 2 PerlInterpMax 4 PerlInterpMinSpare 1 PerlInterpMaxSpare 4 PerlInterpMaxRequests 100 PerlOptions +GlobalRequest Require all granted AddHandler perl-script .pl PerlResponseHandler ModPerl::Registry Options +ExecCGI Require all granted ServerName localhost DocumentRoot /home/joesuf4/src/trunk/content Alias /perl-script /home/joesuf4/src/cms ab -n 1 -c 1000 http://localhost/perl-script/enquiry.pl This is ApacheBench, Version 2.3 <$Revision: 1879490 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed 1 requests Finished 1 requests Server Software:Apache/2.4.52 Server Hostname:localhost Server Port:80 Document Path: /perl-script/enquiry.pl<http://enquiry.pl> Document Length:1329 bytes Concurrency Level: 1000 Time taken for tests: 1.218 seconds Complete requests: 1 Failed requests:0 Total transferred: 1501 bytes HTML transferred: 1329 bytes Requests per second:8207.94 [#/sec] (mean) Time per request: 121.833 [ms] (mean) Time per request: 0.122 [ms] (mean, across all concurrent requests) Transfer rate: 12031.37 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:02 6.2 0 24 Processing: 4 93 49.6 82 458 Waiting:1 80 44.5 71 455 Total: 17 95 49.5 84 458 Percentage of the requests served within a certain time (ms) 50% 84 66%100 75%112 80%120 90%147 95%173 98%233 99%318 100%458 (longest request) % pgrep -f apache2 | xargs -n1 ps -uwww USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 442827 0.0 0.1 18180 14244 ?Ss 11:27 0:00 /usr/sbin/apache2 -k start USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND www-data 446387 1.7 1.5 7549352 129692 ? Sl 11:28 0:12 /usr/sbin/apache2 -k start USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND www-d
Re: sealed.pm v4.0.0 is out
There is a mountain of awful advice floating around about ithreads, including pretty much everything going on in Raku around adopting the node.js model instead. It is safe to ignore all that now that SawyerX spit polished all of the perl5 internals. Get Outlook for iOS<https://aka.ms/o0ukef> From: Joe Schaefer Sent: Monday, August 29, 2022 12:40:43 PM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Many of the performance hacks we’ve encouraged over the years, eg around HTTPD’s lingering close effect, are obsoleted with ithreads. Unless you send flush buckets down the output filter stack yourself, the “response handler” phase exits long before the “connection handler” starts making non blocking socket system calls. So you need an order of magnitude fewer ithreads than you do prefork children in a multitier arch. Get Outlook for iOS<https://aka.ms/o0ukef> ________ From: Joe Schaefer Sent: Sunday, August 28, 2022 11:09:14 AM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Benchmark ran on my 2021 Dell Precision Laptop w/ 8 cores + HT (so 16vCPU) and Ubuntu 22.04 inside WSL2. Never topped 50% avg CPU, and almost all of the CPU was in userland (not system calls). On Sat, Aug 27, 2022 at 11:42 AM mailto:j...@sunstarsys.com>> wrote: See https://sunstarsys.com/essays/perl7-sealed-lexicals. For the full effect, you will need to build B::Generate with this patched version instead: https://github.com/SunStarSys/cms/blob/master/Generate.xs Sample mod_perl config + benchmarks: StartServers 2 MinSpareThreads100 MaxSpareThreads500 ThreadLimit 1000 ThreadsPerChild100 MaxRequestWorkers 100 MaxConnectionsPerChild 0 PerlSwitches -T -I/home/joesuf4/src/cms/lib PerlInterpStart 2 PerlInterpMax 4 PerlInterpMinSpare 1 PerlInterpMaxSpare 4 PerlInterpMaxRequests 100 PerlOptions +GlobalRequest Require all granted AddHandler perl-script .pl PerlResponseHandler ModPerl::Registry Options +ExecCGI Require all granted ServerName localhost DocumentRoot /home/joesuf4/src/trunk/content Alias /perl-script /home/joesuf4/src/cms ab -n 1 -c 1000 http://localhost/perl-script/enquiry.pl This is ApacheBench, Version 2.3 <$Revision: 1879490 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed 1 requests Finished 1 requests Server Software:Apache/2.4.52 Server Hostname:localhost Server Port:80 Document Path: /perl-script/enquiry.pl<http://enquiry.pl> Document Length:1329 bytes Concurrency Level: 1000 Time taken for tests: 1.218 seconds Complete requests: 1 Failed requests:0 Total transferred: 1501 bytes HTML transferred: 1329 bytes Requests per second:8207.94 [#/sec] (mean) Time per request: 121.833 [ms] (mean) Time per request: 0.122 [ms] (mean, across all concurrent requests) Transfer rate: 12031.37 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:02 6.2 0 24 Processing: 4 93 49.6 82 458 Waiting:1 80 44.5 71 455 Total: 17 95 49.5 84 458 Percentage of the requests served within a certain time (ms) 50% 84 66%100 75%112 80%120 90%147 95%173 98%233 99%318 100%458 (longest request) % pgrep -f apache2 | xargs -n1 ps -uwww USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 442827 0.0 0.1 18180 14244 ?Ss 11:27 0:00 /usr/sbin/apache2 -k start USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND www-data 446387 1.7 1.5 7549352 129692 ? Sl 11:28 0:12 /usr/sbin/apache2 -k start USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND www-data 451006 15.2 1.5 7483708 128468 ? Sl 11:39 0:10 /usr/sbin/apache2 -k start USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND www-data 451317 11.7 1.4 7483772 119836 ? Sl 11:39 0:07 /usr/sbin/apache2 -k start USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND www-data 451629 6.4 1.3 7483804 113012 ? Sl 11:39 0:
Re: sealed.pm v4.0.0 is out
Many of the performance hacks we’ve encouraged over the years, eg around HTTPD’s lingering close effect, are obsoleted with ithreads. Unless you send flush buckets down the output filter stack yourself, the “response handler” phase exits long before the “connection handler” starts making non blocking socket system calls. So you need an order of magnitude fewer ithreads than you do prefork children in a multitier arch. Get Outlook for iOS<https://aka.ms/o0ukef> From: Joe Schaefer Sent: Sunday, August 28, 2022 11:09:14 AM To: mod_perl list Subject: Re: sealed.pm v4.0.0 is out Benchmark ran on my 2021 Dell Precision Laptop w/ 8 cores + HT (so 16vCPU) and Ubuntu 22.04 inside WSL2. Never topped 50% avg CPU, and almost all of the CPU was in userland (not system calls). On Sat, Aug 27, 2022 at 11:42 AM mailto:j...@sunstarsys.com>> wrote: See https://sunstarsys.com/essays/perl7-sealed-lexicals. For the full effect, you will need to build B::Generate with this patched version instead: https://github.com/SunStarSys/cms/blob/master/Generate.xs Sample mod_perl config + benchmarks: StartServers 2 MinSpareThreads100 MaxSpareThreads500 ThreadLimit 1000 ThreadsPerChild100 MaxRequestWorkers 100 MaxConnectionsPerChild 0 PerlSwitches -T -I/home/joesuf4/src/cms/lib PerlInterpStart 2 PerlInterpMax 4 PerlInterpMinSpare 1 PerlInterpMaxSpare 4 PerlInterpMaxRequests 100 PerlOptions +GlobalRequest Require all granted AddHandler perl-script .pl PerlResponseHandler ModPerl::Registry Options +ExecCGI Require all granted ServerName localhost DocumentRoot /home/joesuf4/src/trunk/content Alias /perl-script /home/joesuf4/src/cms ab -n 1 -c 1000 http://localhost/perl-script/enquiry.pl This is ApacheBench, Version 2.3 <$Revision: 1879490 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed 1 requests Finished 1 requests Server Software:Apache/2.4.52 Server Hostname:localhost Server Port:80 Document Path: /perl-script/enquiry.pl<http://enquiry.pl> Document Length:1329 bytes Concurrency Level: 1000 Time taken for tests: 1.218 seconds Complete requests: 1 Failed requests:0 Total transferred: 1501 bytes HTML transferred: 1329 bytes Requests per second:8207.94 [#/sec] (mean) Time per request: 121.833 [ms] (mean) Time per request: 0.122 [ms] (mean, across all concurrent requests) Transfer rate: 12031.37 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:02 6.2 0 24 Processing: 4 93 49.6 82 458 Waiting:1 80 44.5 71 455 Total: 17 95 49.5 84 458 Percentage of the requests served within a certain time (ms) 50% 84 66%100 75%112 80%120 90%147 95%173 98%233 99%318 100%458 (longest request) % pgrep -f apache2 | xargs -n1 ps -uwww USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 442827 0.0 0.1 18180 14244 ?Ss 11:27 0:00 /usr/sbin/apache2 -k start USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND www-data 446387 1.7 1.5 7549352 129692 ? Sl 11:28 0:12 /usr/sbin/apache2 -k start USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND www-data 451006 15.2 1.5 7483708 128468 ? Sl 11:39 0:10 /usr/sbin/apache2 -k start USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND www-data 451317 11.7 1.4 7483772 119836 ? Sl 11:39 0:07 /usr/sbin/apache2 -k start USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND www-data 451629 6.4 1.3 7483804 113012 ? Sl 11:39 0:03 /usr/sbin/apache2 -k start USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND www-data 451929 1.1 1.4 7483816 116668 ? Sl 11:39 0:00 /usr/sbin/apache2 -k start -- Joe Schaefer, Ph.D. [https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA] We only build what you need built. mailto:j...@sunstarsys.com>> 954.253.3732
Re: Moving away from pure application server tiers
I don't preload any Perl Modules at server startup and don't recommend you do either, if you want new ithread cloning (of the parent) to be quick. The only legitimate knock on ithreads is the spinup lag, but that is completely mitigated by mod_perl's ithread pool mgmt, which is exactly the same (caching) model as prefork when UNIX fork() was slow (1990s). On Sun, Aug 28, 2022 at 11:03 AM wrote: > There is an emerging industry trend towards consolidation an integration > of webstack technology, and mod_perl + mpm_event is well-positioned to eat > everyone else’s lunch in this space. The only real reason fastcgi-like > frameworks won out over the past two decades is because threading was/is > crap in Dynamic Programming Languages. Nobody could successfully embed > into a threaded webserver, so they went around celebrating multi-tiered > architectures instead. > > > > As the posted benchmark shows, you don’t need a massive investment in a > cluster of horizontally scalable docker containers to service your dynamic > content load. Instead, you need to horizontally scale your modestly sized > front-end apache servers running mpm_event+mod_perl with a Network > (TCP-level) Load Balancer in the front. > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: sealed.pm v4.0.0 is out
Benchmark ran on my 2021 Dell Precision Laptop w/ 8 cores + HT (so 16vCPU) and Ubuntu 22.04 inside WSL2. Never topped 50% avg CPU, and almost all of the CPU was in userland (not system calls). On Sat, Aug 27, 2022 at 11:42 AM wrote: > See https://sunstarsys.com/essays/perl7-sealed-lexicals. For the full > effect, you will need to build B::Generate with this patched version > instead: https://github.com/SunStarSys/cms/blob/master/Generate.xs > > > > Sample mod_perl config + benchmarks: > > > > > > StartServers 2 > > MinSpareThreads100 > > MaxSpareThreads500 > > ThreadLimit 1000 > > ThreadsPerChild100 > > MaxRequestWorkers 100 > > MaxConnectionsPerChild 0 > > > > > > > > PerlSwitches -T -I/home/joesuf4/src/cms/lib > > PerlInterpStart 2 > > PerlInterpMax 4 > > PerlInterpMinSpare 1 > > PerlInterpMaxSpare 4 > > PerlInterpMaxRequests 100 > > PerlOptions +GlobalRequest > > > > > > Require all granted > > AddHandler perl-script .pl > > PerlResponseHandler ModPerl::Registry > > Options +ExecCGI > > > > > > > > Require all granted > > > > > > > > ServerName localhost > > DocumentRoot /home/joesuf4/src/trunk/content > > Alias /perl-script /home/joesuf4/src/cms > > > > > > > > > > > > ab -n 1 -c 1000 http://localhost/perl-script/enquiry.pl > > This is ApacheBench, Version 2.3 <$Revision: 1879490 $> > > Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ > > Licensed to The Apache Software Foundation, http://www.apache.org/ > > > > Benchmarking localhost (be patient) > > Completed 1000 requests > > Completed 2000 requests > > Completed 3000 requests > > Completed 4000 requests > > Completed 5000 requests > > Completed 6000 requests > > Completed 7000 requests > > Completed 8000 requests > > Completed 9000 requests > > Completed 1 requests > > Finished 1 requests > > > > > > Server Software:Apache/2.4.52 > > Server Hostname:localhost > > Server Port:80 > > > > Document Path: /perl-script/enquiry.pl > > Document Length:1329 bytes > > > > Concurrency Level: 1000 > > Time taken for tests: 1.218 seconds > > Complete requests: 1 > > Failed requests:0 > > Total transferred: 1501 bytes > > HTML transferred: 1329 bytes > > Requests per second:8207.94 [#/sec] (mean) > > Time per request: 121.833 [ms] (mean) > > Time per request: 0.122 [ms] (mean, across all concurrent requests) > > Transfer rate: 12031.37 [Kbytes/sec] received > > > > Connection Times (ms) > > min mean[+/-sd] median max > > Connect:02 6.2 0 24 > > Processing: 4 93 49.6 82 458 > > Waiting:1 80 44.5 71 455 > > Total: 17 95 49.5 84 458 > > > > Percentage of the requests served within a certain time (ms) > > 50% 84 > > 66%100 > > 75%112 > > 80%120 > > 90%147 > > 95%173 > > 98%233 > > 99%318 > > 100%458 (longest request) > > > > % pgrep -f apache2 | xargs -n1 ps -uwww > > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > > root 442827 0.0 0.1 18180 14244 ?Ss 11:27 0:00 > /usr/sbin/apache2 -k start > > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > > www-data 446387 1.7 1.5 7549352 129692 ? Sl 11:28 0:12 > /usr/sbin/apache2 -k start > > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > > www-data 451006 15.2 1.5 7483708 128468 ? Sl 11:39 0:10 > /usr/sbin/apache2 -k start > > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > > www-data 451317 11.7 1.4 7483772 119836 ? Sl 11:39 0:07 > /usr/sbin/apache2 -k start > > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > > www-data 451629 6.4 1.3 7483804 113012 ? Sl 11:39 0:03 > /usr/sbin/apache2 -k start > > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > > www-data 451929 1.1 1.4 7483816 116668 ? Sl 11:39 0:00 > /usr/sbin/apache2 -k start > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: sealed.pm v4.0.0 is out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 So a <600MB total RSS footprint for the entire show, and I can stably sustain 1000 concurrent ModPerl::Registry requests, in a few milliseconds per request. Good luck doing anything this efficiently with a multi-tiered dynamic content delivery regime. The real tuning effort is to balance mpm_event threads (100 - 1000x) and ithreads. - -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732 On 2022-08-27 at 15:42, j...@sunstarsys.com wrote: > See https://sunstarsys.com/essays/perl7-sealed-lexicals. For the full effect, you will need to build B::Generate with this patched version instead: https://github.com/SunStarSys/cms/blob/master/Generate.xs > > Sample mod_perl config + benchmarks: > > > StartServers 2 > MinSpareThreads100 > MaxSpareThreads500 > ThreadLimit 1000 > ThreadsPerChild100 > MaxRequestWorkers 100 > MaxConnectionsPerChild 0 > > > > PerlSwitches -T -I/home/joesuf4/src/cms/lib > PerlInterpStart 2 > PerlInterpMax 4 > PerlInterpMinSpare 1 > PerlInterpMaxSpare 4 > PerlInterpMaxRequests 100 > PerlOptions +GlobalRequest > > > Require all granted > AddHandler perl-script .pl > PerlResponseHandler ModPerl::Registry > Options +ExecCGI > > > > Require all granted > > > > ServerName localhost > DocumentRoot /home/joesuf4/src/trunk/content > Alias /perl-script /home/joesuf4/src/cms > > > > > > ab -n 1 -c 1000 http://localhost/perl-script/enquiry.pl > This is ApacheBench, Version 2.3 <$Revision: 1879490 $> > Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ > Licensed to The Apache Software Foundation, http://www.apache.org/ > > Benchmarking localhost (be patient) > Completed 1000 requests > Completed 2000 requests > Completed 3000 requests > Completed 4000 requests > Completed 5000 requests > Completed 6000 requests > Completed 7000 requests > Completed 8000 requests > Completed 9000 requests > Completed 1 requests > Finished 1 requests > > > Server Software:Apache/2.4.52 > Server Hostname:localhost > Server Port:80 > > Document Path: /perl-script/enquiry.pl > Document Length:1329 bytes > > Concurrency Level: 1000 > Time taken for tests: 1.218 seconds > Complete requests: 1 > Failed requests:0 > Total transferred: 1501 bytes > HTML transferred: 1329 bytes > Requests per second:8207.94 [#/sec] (mean) > Time per request: 121.833 [ms] (mean) > Time per request: 0.122 [ms] (mean, across all concurrent requests) > Transfer rate: 12031.37 [Kbytes/sec] received > > Connection Times (ms) > min mean[+/-sd] median max > Connect:02 6.2 0 24 > Processing: 4 93 49.6 82 458 > Waiting:1 80 44.5 71 455 > Total: 17 95 49.5 84 458 > > Percentage of the requests served within a certain time (ms) > 50% 84 > 66%100 > 75%112 > 80%120 > 90%147 > 95%173 > 98%233 > 99%318 > 100%458 (longest request) > > % pgrep -f apache2 | xargs -n1 ps -uwww > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > root 442827 0.0 0.1 18180 14244 ?Ss 11:27 0:00 /usr/sbin/apache2 -k start > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > www-data 446387 1.7 1.5 7549352 129692 ? Sl 11:28 0:12 /usr/sbin/apache2 -k start > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > www-data 451006 15.2 1.5 7483708 128468 ? Sl 11:39 0:10 /usr/sbin/apache2 -k start > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > www-data 451317 11.7 1.4 7483772 119836 ? Sl 11:39 0:07 /usr/sbin/apache2 -k start > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > www-data 451629 6.4 1.3 7483804 113012 ? Sl 11:39 0:03 /usr/sbin/apache2 -k start > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > www-data 451929 1.1 1.4 7483816 116668 ? Sl 11:39 0:00 /usr/sbin/apache2 -k start -BEGIN PGP SIGNATURE- Version: FlowCrypt Email Encryption 8.3.3 Comment: Seamlessly send and receive encrypted email wsFzBAEBCgAGBQJjCkWOACEJEEAg7C7WAdUZFiEEf+9TuFcgikzfTrs6QCDs LtYB1RkFAw//ceUc4RCiyAE
Re: Experience running mod_perl2 with mpm_event on Solaris 11
I have a v4.0.0 beta for sealed.pm that I expect will be fully operational with mod_perl+ithreads now, but I will let it soak for a week to see what happens in prod. On Fri, Aug 26, 2022 at 3:30 PM Joe Schaefer wrote: > You're welcome. Pardon my rudeness, but you will understand when I tell > you that I developed sealed.pm after proving ithreads are solid on > Solaris over 2 years ago, and communicated with the Perl5 community on FB > and LI about the same thing I did here last week. There is considerable > racism and dysfunction around the whole ithread effort involving p5p, and > that is plainly evident that those prejudices impact this project’s user > base, which is a real shame to see compared with the interest and > excitement around our work 20y ago. > > On Fri, Aug 26, 2022 at 3:23 PM Edward J. Sabol > wrote: > >> On Aug 26, 2022, at 1:16 PM, Joe Schaefer wrote: >> > AFAICT you guys are just too lazy to look. >> >> That came across as rude, Joe. Not all of us are experts at Perl >> internals or track the latest changes to Perl's ithread support and/or >> glibc, and it's generally been accepted in the mod_perl community for years >> that mod_perl only works reliably with mpm_prefork. To the best of my >> recollection, there haven't been any reports of mod_perl working under >> mpm_event prior to your messages about using it on Solaris a couple weeks >> ago. But thank you for sharing your knowledge and experiences. It does seem >> well worth exploring. >> >> Regards, >> Ed >> >> -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
You're welcome. Pardon my rudeness, but you will understand when I tell you that I developed sealed.pm after proving ithreads are solid on Solaris over 2 years ago, and communicated with the Perl5 community on FB and LI about the same thing I did here last week. There is considerable racism and dysfunction around the whole ithread effort involving p5p, and that is plainly evident that those prejudices impact this project’s user base, which is a real shame to see compared with the interest and excitement around our work 20y ago. On Fri, Aug 26, 2022 at 3:23 PM Edward J. Sabol wrote: > On Aug 26, 2022, at 1:16 PM, Joe Schaefer wrote: > > AFAICT you guys are just too lazy to look. > > That came across as rude, Joe. Not all of us are experts at Perl internals > or track the latest changes to Perl's ithread support and/or glibc, and > it's generally been accepted in the mod_perl community for years that > mod_perl only works reliably with mpm_prefork. To the best of my > recollection, there haven't been any reports of mod_perl working under > mpm_event prior to your messages about using it on Solaris a couple weeks > ago. But thank you for sharing your knowledge and experiences. It does seem > well worth exploring. > > Regards, > Ed > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
LOL IF YOU THINK THE WAIT FOR ITHREAD SUPPORT WAS A LONG TIME COMING. https://github.com/majorz/apache2-rs/tree/master/src On Fri, Aug 26, 2022 at 2:36 PM John D Groenveld wrote: > In message < > cafqgv+yb4bo3k4_hryccyj7ljsnejrh9hwyjw+9172ybc+q...@mail.gmail.com> > , Joe Schaefer writes: > >The entire collective engineering effort for mod_perl and mod_apreq was to > >ensure our code was thread-safe, both from an httpd context and a Perl > one. > >We achieved that twenty years ago, but have been stuck dealing with the > >fact that ithread engineering within Perl5 itself had a ways to go. > > My WAG is that new application development that requires instrumenting > the Apache httpd request phases is now being coded in Rust. > > John > groenv...@acm.org > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
All of the zero-copy design elements of httpd are expanded on within mod_perl in an ithread context. All of those performance optimizations are lost when you bury them behind a mod_proxy gateway to your application server running prefork. Moreover, your scaling model for your application server is a disaster from a resource management perspective, because you are latency bound by all of those system calls that copy data between your servers. Typically you will run an app server with 5-10x the number of vCPU on the host, because of the context switch bottleneck you can't avoid. mod_perl with mpm_event is designed to be tightly integrated with the rest of httpd. For example I have my outbound mod_perl filter stack loaded up with compression and SSI. I also can dynamically add Perl filters to it to do mass-multplexing when I'm interfacing over sockets with my markdown.js node service. Again full zero-copy OOTB. I don't have any context-switches to deal with once mod_perl has hooked an interpreter into my modperl response handler invocation, so I don't need all the wasted overhead involved in multitiered services. Gimme one ithread per vCPU, that's more I will ever need with an httpd worker process, and send the benchmark concurrency into the thousands just to watch your vCPUs burn through the Perl op trees.
Re: Experience running mod_perl2 with mpm_event on Solaris 11
The entire collective engineering effort for mod_perl and mod_apreq was to ensure our code was thread-safe, both from an httpd context and a Perl one. We achieved that twenty years ago, but have been stuck dealing with the fact that ithread engineering within Perl5 itself had a ways to go. What I'm telling this list now is that Perl5 has finally caught up, and we can confidently tell you to familiarize yourself with the entire universe of tooling around ithread pools that is unique to mod_perl, and will blow you away once you are fully versed in how it can be tuned for maximum effect with minimal memory footprint. On Fri, Aug 26, 2022 at 1:49 PM Joe Schaefer wrote: > Why are you still paying attention to mod_perl development, if you don't > even care to use it to full effect? > Running a 2-tiered webserver architecture is anathema to mod_perl. It's > not distinguishable from any other fastcgi thingy out there. > > > On Fri, Aug 26, 2022 at 1:46 PM John D Groenveld > wrote: > >> In message > zhwww5d7fcmmcgpdmxs...@mail.gmail.com> >> , Joe Schaefer writes: >> >Lazy enough never to support HTTP/2? >> >> If HTTP/2 becomes necessary, my lazy first answer is to enable it in my >> mod_proxy front end. >> >> John >> groenv...@acm.org >> > > > -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
Why are you still paying attention to mod_perl development, if you don't even care to use it to full effect? Running a 2-tiered webserver architecture is anathema to mod_perl. It's not distinguishable from any other fastcgi thingy out there. On Fri, Aug 26, 2022 at 1:46 PM John D Groenveld wrote: > In message zhwww5d7fcmmcgpdmxs...@mail.gmail.com> > , Joe Schaefer writes: > >Lazy enough never to support HTTP/2? > > If HTTP/2 becomes necessary, my lazy first answer is to enable it in my > mod_proxy front end. > > John > groenv...@acm.org > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
There isn't anything else on the market that will ever touch mod_perl + mpm_event in terms of HTTP/2 performance. And you don't need to ever spin up more ithreads than you have vCPU cores. On Fri, Aug 26, 2022 at 1:36 PM Joe Schaefer wrote: > Lazy enough never to support HTTP/2? > > On Fri, Aug 26, 2022 at 1:32 PM John D Groenveld > wrote: > >> In message < >> cafqgv+btwpyvvup2ewzfn7ruv4sfgdihadh48cm3n8qxpwb...@mail.gmail.com> >> , Joe Schaefer writes: >> >AFAICT you guys are just too lazy to look. Running latest on CPAN with an >> >> Correct. >> mod_perl's make test mostly passes and does not core with mpm_event under >> OmniOS/illumos, FreeBSD, and Void Linux with Musl, but I haven't tested >> my applications because I am lazy and mpm_prefork just works. >> >> John >> groenv...@acm.org >> > > > -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
Lazy enough never to support HTTP/2? On Fri, Aug 26, 2022 at 1:32 PM John D Groenveld wrote: > In message < > cafqgv+btwpyvvup2ewzfn7ruv4sfgdihadh48cm3n8qxpwb...@mail.gmail.com> > , Joe Schaefer writes: > >AFAICT you guys are just too lazy to look. Running latest on CPAN with an > > Correct. > mod_perl's make test mostly passes and does not core with mpm_event under > OmniOS/illumos, FreeBSD, and Void Linux with Musl, but I haven't tested > my applications because I am lazy and mpm_prefork just works. > > John > groenv...@acm.org > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
AFAICT you guys are just too lazy to look. Running latest on CPAN with an Ubuntu 22.04 stock httpd and the thing just cranks out the hits. (Not with sealed.pm tho, it will leak scalars and cause crashes with mod_perl and mpm_event). If anybody is to thank for this, thank SawyerX for his Pumpking work on the 5.22+ line. On Wed, Aug 24, 2022 at 11:08 PM Joe Schaefer wrote: > Has anybody actually tried running bleadperl with modperl and mpm_event on > Linux? I wouldn’t be surprised if it works without coring in malloc() at > this point, or at least can be tuned to work. > > On Sat, Aug 20, 2022 at 11:31 AM Joe Schaefer wrote: > >> Solaris libc malloc() is also tunable (% man mallopt again), but I can >> tell you that I've yet to have a reason to bother, because it simply >> doesn't dump core on my mod_perl applications. >> >> >> >> On Sat, Aug 20, 2022 at 10:37 AM Joe Schaefer wrote: >> >>> >>> >>> -- Forwarded message - >>> From: Joe Schaefer >>> Date: Fri, Aug 19, 2022 at 10:37 PM >>> Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11 >>> To: pengyh >>> >>> >>> Seriously it’s always been a quality of implementation issue in open >>> source libc implementations (FreeBSD libc isn’t any better than glibc for >>> modperl and event_mpm). >>> >>> I papered over a third player in the memory management regimes in play. >>> The real problem for modperl isn’t apr pool allocations, it’s the bucket >>> brigades in the filter stacks. That stuff is hitting malloc/free multiple >>> times every time you deliver content to the browser. Combine that with a >>> lot of concurrent ithreads and things fall apart on non Solaris libc >>> implementations. >>> >>> >>> On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer >>> wrote: >>> >>>> Lower case t on technology >>>> >>>> On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer >>>> wrote: >>>> >>>>> https://sunstarsys.com/CMS/Technology >>>>> >>>>> On Fri, Aug 19, 2022 at 10:15 PM pengyh wrote: >>>>> >>>>>> i am not a programming expert. but I hear that most scripts like >>>>>> perl/python/ruby support threads not that well. is it? >>>>>> >>>>>> >>>>>> Joe Schaefer wrote: >>>>>> > Yes, with per Interpreter Threads. Everything else uses a Global >>>>>> > Interpreter Lock, which makes it single threaded on the actual op >>>>>> tree >>>>>> > walk (running your script logic, instead of system calls). >>>>>> >>>>> -- >>>>> Joe Schaefer, Ph.D. >>>>> We only build what you need built. >>>>> >>>>> 954.253.3732 >>>>> >>>>> >>>>> -- >>>> Joe Schaefer, Ph.D. >>>> We only build what you need built. >>>> >>>> 954.253.3732 >>>> >>>> >>>> -- >>> Joe Schaefer, Ph.D. >>> We only build what you need built. >>> >>> 954.253.3732 >>> >>> >>> >>> >>> -- >>> Joe Schaefer, Ph.D. >>> We only build what you need built. >>> >>> 954.253.3732 >>> >>> >>> >> >> -- >> Joe Schaefer, Ph.D. >> We only build what you need built. >> >> 954.253.3732 >> >> >> -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
Has anybody actually tried running bleadperl with modperl and mpm_event on Linux? I wouldn’t be surprised if it works without coring in malloc() at this point, or at least can be tuned to work. On Sat, Aug 20, 2022 at 11:31 AM Joe Schaefer wrote: > Solaris libc malloc() is also tunable (% man mallopt again), but I can > tell you that I've yet to have a reason to bother, because it simply > doesn't dump core on my mod_perl applications. > > > > On Sat, Aug 20, 2022 at 10:37 AM Joe Schaefer wrote: > >> >> >> ------ Forwarded message - >> From: Joe Schaefer >> Date: Fri, Aug 19, 2022 at 10:37 PM >> Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11 >> To: pengyh >> >> >> Seriously it’s always been a quality of implementation issue in open >> source libc implementations (FreeBSD libc isn’t any better than glibc for >> modperl and event_mpm). >> >> I papered over a third player in the memory management regimes in play. >> The real problem for modperl isn’t apr pool allocations, it’s the bucket >> brigades in the filter stacks. That stuff is hitting malloc/free multiple >> times every time you deliver content to the browser. Combine that with a >> lot of concurrent ithreads and things fall apart on non Solaris libc >> implementations. >> >> >> On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer wrote: >> >>> Lower case t on technology >>> >>> On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer >>> wrote: >>> >>>> https://sunstarsys.com/CMS/Technology >>>> >>>> On Fri, Aug 19, 2022 at 10:15 PM pengyh wrote: >>>> >>>>> i am not a programming expert. but I hear that most scripts like >>>>> perl/python/ruby support threads not that well. is it? >>>>> >>>>> >>>>> Joe Schaefer wrote: >>>>> > Yes, with per Interpreter Threads. Everything else uses a Global >>>>> > Interpreter Lock, which makes it single threaded on the actual op >>>>> tree >>>>> > walk (running your script logic, instead of system calls). >>>>> >>>> -- >>>> Joe Schaefer, Ph.D. >>>> We only build what you need built. >>>> >>>> 954.253.3732 >>>> >>>> >>>> -- >>> Joe Schaefer, Ph.D. >>> We only build what you need built. >>> >>> 954.253.3732 >>> >>> >>> -- >> Joe Schaefer, Ph.D. >> We only build what you need built. >> >> 954.253.3732 >> >> >> >> >> -- >> Joe Schaefer, Ph.D. >> We only build what you need built. >> >> 954.253.3732 >> >> >> > > -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
Solaris libc malloc() is also tunable (% man mallopt again), but I can tell you that I've yet to have a reason to bother, because it simply doesn't dump core on my mod_perl applications. On Sat, Aug 20, 2022 at 10:37 AM Joe Schaefer wrote: > > > -- Forwarded message - > From: Joe Schaefer > Date: Fri, Aug 19, 2022 at 10:37 PM > Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11 > To: pengyh > > > Seriously it’s always been a quality of implementation issue in open > source libc implementations (FreeBSD libc isn’t any better than glibc for > modperl and event_mpm). > > I papered over a third player in the memory management regimes in play. > The real problem for modperl isn’t apr pool allocations, it’s the bucket > brigades in the filter stacks. That stuff is hitting malloc/free multiple > times every time you deliver content to the browser. Combine that with a > lot of concurrent ithreads and things fall apart on non Solaris libc > implementations. > > > On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer wrote: > >> Lower case t on technology >> >> On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer wrote: >> >>> https://sunstarsys.com/CMS/Technology >>> >>> On Fri, Aug 19, 2022 at 10:15 PM pengyh wrote: >>> >>>> i am not a programming expert. but I hear that most scripts like >>>> perl/python/ruby support threads not that well. is it? >>>> >>>> >>>> Joe Schaefer wrote: >>>> > Yes, with per Interpreter Threads. Everything else uses a Global >>>> > Interpreter Lock, which makes it single threaded on the actual op >>>> tree >>>> > walk (running your script logic, instead of system calls). >>>> >>> -- >>> Joe Schaefer, Ph.D. >>> We only build what you need built. >>> >>> 954.253.3732 >>> >>> >>> -- >> Joe Schaefer, Ph.D. >> We only build what you need built. >> >> 954.253.3732 >> >> >> -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > > > -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Fwd: Experience running mod_perl2 with mpm_event on Solaris 11
-- Forwarded message - From: Joe Schaefer Date: Fri, Aug 19, 2022 at 10:37 PM Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11 To: pengyh Seriously it’s always been a quality of implementation issue in open source libc implementations (FreeBSD libc isn’t any better than glibc for modperl and event_mpm). I papered over a third player in the memory management regimes in play. The real problem for modperl isn’t apr pool allocations, it’s the bucket brigades in the filter stacks. That stuff is hitting malloc/free multiple times every time you deliver content to the browser. Combine that with a lot of concurrent ithreads and things fall apart on non Solaris libc implementations. On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer wrote: > Lower case t on technology > > On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer wrote: > >> https://sunstarsys.com/CMS/Technology >> >> On Fri, Aug 19, 2022 at 10:15 PM pengyh wrote: >> >>> i am not a programming expert. but I hear that most scripts like >>> perl/python/ruby support threads not that well. is it? >>> >>> >>> Joe Schaefer wrote: >>> > Yes, with per Interpreter Threads. Everything else uses a Global >>> > Interpreter Lock, which makes it single threaded on the actual op tree >>> > walk (running your script logic, instead of system calls). >>> >> -- >> Joe Schaefer, Ph.D. >> We only build what you need built. >> >> 954.253.3732 >> >> >> -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732 -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: mod_perl and mod_python
Its got a GIL and it cores frequently and it’s not exposing much of the httpd/apr. It’s not that popular compared to wsgi. On Fri, Aug 19, 2022 at 10:20 PM pengyh wrote: > I know perl and python a bit well, most time use both of them for work. > besides mod_perl, there is also mod_python. > do you know what's the difference between them? > I never heard people using mod_python to make some jobs. > > Thanks > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
Segfaults in glibc malloc should be reported to glibc developers. Not here. There’s nothing we can do about it other than to suggest Solaris for high performance modperl shops. On Fri, Aug 19, 2022 at 9:28 PM Joe Schaefer wrote: > My pleasure. Nobody’s going to fix this from the modperl developer side. > We don’t care any more. That ship sailed 20 years ago. I don’t think it’s > ever not worked on Solaris, so you get what you pay for in the end. > > On Fri, Aug 19, 2022 at 9:25 PM Edward J. Sabol > wrote: > >> Very interesting, Joe! Thank you for sharing your insights into this and >> experience with it. Here’s hoping someone can solve/fix the problem with >> mod_perl threads on Linux. >> >> Regards, >> Ed >> >> On Aug 19, 2022, at 1:44 PM, j...@sunstarsys.com wrote: >> > The problem is really confined to embedded uses of ithreads, because >> Perl itself will mutex-wrap the malloc calls. In httpd, so do all >> apr_pool_t calls to malloc. It's when the two memory management techniques >> are interacting that there is no application-level way to guard against >> thread contention in libc's malloc. >> > >> > Mod_perl+ithreads are awesome, when used intelligently. You gain >> intelligence from experience trying to use it in a lot of ways that suck, >> until you hit one the path that yields success. >> > -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
My pleasure. Nobody’s going to fix this from the modperl developer side. We don’t care any more. That ship sailed 20 years ago. I don’t think it’s ever not worked on Solaris, so you get what you pay for in the end. On Fri, Aug 19, 2022 at 9:25 PM Edward J. Sabol wrote: > Very interesting, Joe! Thank you for sharing your insights into this and > experience with it. Here’s hoping someone can solve/fix the problem with > mod_perl threads on Linux. > > Regards, > Ed > > On Aug 19, 2022, at 1:44 PM, j...@sunstarsys.com wrote: > > The problem is really confined to embedded uses of ithreads, because > Perl itself will mutex-wrap the malloc calls. In httpd, so do all > apr_pool_t calls to malloc. It's when the two memory management techniques > are interacting that there is no application-level way to guard against > thread contention in libc's malloc. > > > > Mod_perl+ithreads are awesome, when used intelligently. You gain > intelligence from experience trying to use it in a lot of ways that suck, > until you hit one the path that yields success. > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
See % man mallopt for ENV tunables on Linux. On the surface, glibc malloc should work as well as Solaris libc malloc re threading, but I don't have the patience to track it down since I don't run Linux in my shop. On Tue, Aug 16, 2022 at 3:50 PM wrote: > We've been plagued by endless Segmentation Faults on non-Solaris systems, > where the backtrace indicated the problem was in mod_perl -> Perl Code -> > malloc (at the top of the frame). For a while I thought p5p fixed this in > 5.30+ releases, but since nobody confirmed that suspicion I think the > problem is more on the OS/Platform level. > > -Original Message- > From: Edward J. Sabol > Sent: Tuesday, August 16, 2022 2:27 PM > To: mod_perl list > Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11 > > On Aug 16, 2022, at 12:27 PM, j...@sunstarsys.com wrote: > > To the best of my knowledge, the underlying problem with > mod_perl+ithread is that it requires a reentrant malloc in libc. > > That's it? This is the first I'm learning this. Is there an option to > compile Perl and mod_perl with a reentrant malloc on Linux? > > Thanks, > Ed > -- Joe Schaefer, Ph.D. 954.253.3732
Experience running mod_perl2 with mpm_event on Solaris 11
You can read about it in the URL below, but I’ve had it running for over two years as the linchpin of a Perl-based CMS that The ASF used to use itself (under prefork). It screams under HTTP2. See https://sunstarsys.com/CMS/ -- Joe Schaefer, Ph.D. 954.253.3732
Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC1
+1, nice job Steve! On Wednesday, May 13, 2015 6:52 PM, David E. Wheeler da...@justatheory.com wrote: On May 13, 2015, at 1:40 PM, Steve Hay steve.m@googlemail.com wrote: http://people.apache.org/~stevehay/mod_perl-2.0.9-rc1.tar.gz If I can vote for my own RC then it's a +1 from me :-) Tested builds on CentOS 6 and 7, with the system Perl and a custom 5.20 build. Both build nicely, with just a simple patch for the system Perl wanting a header with “CentOS” in it instead of “Unix”. Yay! https://github.com/iovation/rpmcpan/blob/master/SOURCES/mod_perl-centos.patch Best, David
Re: Trunk: APR.so won't load
) Start of section headers: 15480 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 6 Size of section headers: 64 (bytes) Number of section headers: 29 Section header string table index: 26 Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0 0 0 [ Lines removed for clarity ] Dynamic section at offset 0x36f8 contains 27 entries: Tag Type Name/Value 0x0001 (NEEDED) Shared library: [libaprutil-1.so.0] 0x0001 (NEEDED) Shared library: [libexpat.so.1] 0x0001 (NEEDED) Shared library: [libapr-1.so.0] 0x0001 (NEEDED) Shared library: [librt.so.1] 0x0001 (NEEDED) Shared library: [libcrypt.so.1] 0x0001 (NEEDED) Shared library: [libpthread.so.0] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x000f (RPATH) Library rpath: [/usr/local/httpd-2.4.12/lib:/lib/../lib64] [ Lines removed for clarity ] Relocation section '.rela.plt' at offset 0x1300 contains 61 entries: Offset Info Type Sym. Value Sym. Name + Addend 00203930 00020007 R_X86_64_JUMP_SLO Perl_mg_get + 0 00203938 00030007 R_X86_64_JUMP_SLO Perl_sv_setiv + 0 00203940 00040007 R_X86_64_JUMP_SLO Perl_sv_bless + 0 00203948 00050007 R_X86_64_JUMP_SLO apr_strerror + 0 00203950 00060007 R_X86_64_JUMP_SLO Perl_require_pv + 0 00203958 00070007 R_X86_64_JUMP_SLO Perl_warn + 0 00203960 00080007 R_X86_64_JUMP_SLO PerlIO_printf + 0 00203968 00090007 R_X86_64_JUMP_SLO ap_strchr + 0 [ Lines removed for clarity ] Symbol table '.dynsym' contains 86 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 18b8 0 SECTION LOCAL DEFAULT 9 2: 0 NOTYPE GLOBAL DEFAULT UND Perl_mg_get 3: 0 NOTYPE GLOBAL DEFAULT UND Perl_sv_setiv 4: 0 NOTYPE GLOBAL DEFAULT UND Perl_sv_bless 5: 0 FUNC GLOBAL DEFAULT UND apr_strerror 6: 0 NOTYPE GLOBAL DEFAULT UND Perl_require_pv 7: 0 NOTYPE GLOBAL DEFAULT UND Perl_warn 8: 0 NOTYPE GLOBAL DEFAULT UND PerlIO_printf 9: 0 NOTYPE GLOBAL DEFAULT UND ap_strchr [ Lines removed for clarity ] Symbol table '.symtab' contains 143 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0190 0 SECTION LOCAL DEFAULT 1 [ Lines removed for clarity ] 69: 0 NOTYPE GLOBAL DEFAULT UND ap_strchr [ Lines removed for clarity ] -- It seems that ap_strchr is not defined anywhere outside httpd, and not in any of the shared libs. This seems to create the problem when building a module with mod_perl or outside the mod_perl source. I find a somewhat related change by Stas in the past in the Changes file: bug reports generating code: [Stas] - add (apr|apu)-config linking info - show the full path to the config file used to get the data for the report The APR and APR::* family of modules can now be used without having to load mod_perl.so. On *nix, this is done by compiling the needed functions from the appropriate sources used to build mod_perl.so into APR.so, and then arranging for APR::* to 'use APR ()'. On Win32, a static library of needed functions is built, and APR/APR::* then link into this library [Stas, Joe Schaefer, Randy Kobes] I hope this helps resolve this issue in any way. Regards, Jie * Jie Gao j@sydney.edu.au wrote: Date: Sun, 1 Mar 2015 17:30:45 +1100 From: Jie Gao j@sydney.edu.au To: modperl@perl.apache.org modperl@perl.apache.org, mod_perl Dev d...@perl.apache.org Subject: Trunk: APR.so won't load User-Agent: Mutt/1.5.21 (2010-09-15) I have got
Fw: Perl Developer / Linux SysAdmin Opportunities in South Florida
On Thursday, April 2, 2015 6:21 PM, Joe Schaefer joe.schae...@biotrackthc.com wrote: Bio-Tech Medical Software Inc. is expanding its South Florida HQ and is looking to grow its small but skilled IT department to meet expected market demand for our products. Our subsidiary, BioTrackTHC, provides market leading seed-to-sale business software for the marijuana industry, together with a comprehensive service offered to state regulators which provides each state with transparency and oversight into each and every event in the regulated products' lifecycle. We are looking for a few good candidates, who are willing to relocate to the Ft. Lauderdale area, to fulfil the following two positions: -- 1) Developer - SQL/Perl We are looking for a few full-time Perl programmers to work with our existing team to further develop and maintain our software projects. The systems use a combination of * Perl * Gtk * SQL (postgresql) * FIX Protocol (financial industry experience a plus) * SSL * Our servers run Linux, business clients run Windows * Standard web technologies: HTML5, CSS, Javascript --- 2) System Administrator We are looking for a few full-time Linux System Administrators to work under my direction primarily in support of our per-state traceability contracts. The contracts will require some travel and on-call activity from each team member, and take advantage of the following technologies: * Slackware * Puppet * HA PostgreSQL * HA Apache httpd/mod_perl * Gtk based websockets * Standard web technologies: HTML5, CSS, Javascript --- When replying to these postings, interested persons should include as much of the following information as possible: * Resume / LinkedIn Profile * Desired Compensation * Sample code, preferably on github or similar open source code repository To apply for a position simply reply to this email with the requisite information and please specify the job (1 or 2) for which you are applying.You will note in particular that these are not devops jobs. There's a reason why product development is kept separate from operations activity, fads of late notwithstanding. We are looking for bright candidates who show potential to learn quickly on the job within a collaborative, professional environment. Breadth of experience is less important to us than depth in a few key areas. The company will offer new hires relocation subsidies, an employee stock program and potential bonuses, health insurance, and a beautiful building location in central Ft. Lauderdale. Check us out at https://www.biotrackthc.com/ ! -- Joe Schaefer, Ph.D. Director of Information Technology joe.schae...@biotrackthc.com (954) 253-3732
Re: mod_perl and utf8 and CGI-param
apreq validates anything it presents as utf8, otherwise it marks it as ISO88591 or some windows encoding I don't remember the name of if that fails. On Monday, September 8, 2014 3:17 PM, André Warnier a...@ice-sa.com wrote: Michael Schout wrote: On 9/2/14, 4:19 PM, Randal L. Schwartz wrote: ## ensure utf8 CGI params: $CGI::PARAM_UTF8 = 1; Sorry to chime in late on this, but part of the problem with CGI.pm and UTF-8 is that PARAM_UTF8 gets clobbered by a cleanup handler that CGI.pm itself registers if its running under mod_perl. This caused major headaches for me at one time until I figured this out. You have to make sure to set $CGI::PARAM_UTF8 early, and FOR EVERY REQUEST, because if you just set it globally (e.g.: in a startup perl script), then it only works for the first request. Hi. Just an addendum to the discussion : There are really two distinct approaches to this issue, and they work at different levels : 1) is to fix CGI.pm so that it delivers the parameters in the way which you expect. As shown by the previous valuable and technical contributions, this generally works, but it requires a certain level of expertise; and it does not necessarily work backwards with all versions of mod_perl and CGI.pm. 2) is to take whatever CGI.pm does deliver to the calling script or module, and use a couple of tricks and some additional code in ditto script or module, to ensure that whatever CGI.pm delivers under whatever mod_perl version, the receiving script or module always knows in the end what it is dealing with. That is the method which I presented early in the discussion. As stated in that contribution, it is not necessarily the most elegant or efficient way to deal with the issue, but it has the advantage of working always, no matter which version of CGI.pm and/or mod_perl are in use. The real crux of the matter is this, in my view : as things stand today in terms of protocol and RFCs, there is no real way for CGI.pm (or any comparable framework) to be *sure* of the encoding of the data sent by a browser or another HTTP client agent. Even the RFCs do not really provide a way by which this can be enforced. (*) So if you are sure of what the client is sending, and the matter consists of *forcing* CGI.pm to always communicate POST (or GET) data as UTF-8 encoded and utf8-marked (or the opposite) to the calling script/module, then method 1 will work, and it is more elegant and probably more efficient than method 2. But if the matter consists of ensuring that the receiving code in the script/module which handles the data submitted by the HTTP client, is resilient and does the right thing whatever the submitted data really was, then in my opinion method 2 is better. (But that's only my opinion of the moment, and I stand ready to be corrected). (*) and if you believe this not to be true, please send me some references about it, because I am really interested. It might save me some code in all my web-facing applications.
Re: Interrupting a POST with file upload
You probably don't want to do this with a hook if you can avoid it. The reason is that once httpd sends the 100 Continue it will read the entire upload, even after CGI.pm or apreq has stopped parsing it. - Original Message - From: André Warnier a...@ice-sa.com To: mod_perl list modperl@perl.apache.org Cc: Sent: Wednesday, February 8, 2012 4:14 AM Subject: Interrupting a POST with file upload T his refers to and follows another thread originally entitled mod perl installed but not running, started by Mike Cardeiro. It seemed better to start a new thread with a subject more to the point of this issue. Perrin Harkins wrote: On Tue, Feb 7, 2012 at 7:26 PM, André Warnier a...@ice-sa.com wrote: You can also look at $CGI::POST_MAX in the same documentation. See also LimitRequestBody: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody As long as we have an expert.. What Mike wants to do (and me too), is to limit the size of a file that a specific user is uploading via a POST, in real-time and depending on a limit variable on a per-user, per-POST manner. And he wants to do this in such a way as to interrupt the POST itself, while it is taking place (aka if possible while the browser is still sending data to the server), to avoid a waste of time and bandwidth when a user is exceeding his quota e.g. As far as I know, LimitRequestBody is an absolute POST size limit set once and for all in the server config, and valid for all POSTs (and PUTs) after server restart. And it is calculated on the base of the real bytes being sent by the browser, this including the overhead caused by Base64 encoding the content of a file sent for example. (So that if you set the limit to 1MB, this will actually kick in as soon as the net unencoded size of the file being uploaded exceeds 660KB or so.) Then there is the $CGI_POST_MAX, which may very well be the same server value being manipulated by the CGI module, or it may be a private copy by CGI.pm. What is not really clear is if that value is thread-safe in all scenarios. In the normal scenario, when retrieving the uploaded file's handle via the CGI.pm call to param(file_input_name) or upload(file_input_name), what one actually gets is a handle onto a local temporary file, into which Apache/CGI.pm has already stored the whole content of the uploaded file. By that time, the original file upload from the browser has already happened, so doing something at this point would be too late to interrupt the browser POST itself (and the bandwidth and time have already been spent). On the other hand, the CGI.pm documentation seems to say that if one uses the hook functionality for a file upload, then Apache/CGI.pm do not use a temporary file, and one gets a handle directly into the POST body content (so to speak), as it is being received by Apache. And thus this could be a way to achieve what Mike wants. (I suppose that we can assume that even though we get a handle into the POST body content, what we are reading is the decoded data, right ?). Now the question is, are my above interpretations correct ?
Re: Interrupting a POST with file upload
Sorry slight clarification here after rereading httpd source: If you send anything other than that Continue: 100 interim response to the client, httpd will NOT attempt to read the body, considering it empty. But even if you do send the Continue: 100, httpd will NOT block the response from being sent until the body has been exhausted. Instead it will send your response as expected, and then finalize the request by calling ap_discard_request_body(r) which WILL exhaust the POST data in order to retain protocol compliance. OTOH I have no idea how browsers deal with the timing issues here, so buyer beware. My point still stands: interrupt the POST prior to sending the Continue, not afterwards. - Original Message - From: Joe Schaefer joe_schae...@yahoo.com To: Vincent Veyron vv.li...@wanadoo.fr; mike cardeiro mcarde...@yahoo.com Cc: Torsten Förtsch torsten.foert...@gmx.net; modperl@perl.apache.org modperl@perl.apache.org Sent: Wednesday, February 8, 2012 4:35 PM Subject: Re: Interrupting a POST with file upload I don't think people groked my point very well. When you POST via HTTP/1.1, httpd will send a Continue: 100 header before it starts doing blocking reads on the client socket (any attempts to read from the client will trigger this behavior). If you really want to interrupt an upload, the time to do it is *before* httpd sends that header. Afterwards httpd commits to reading the entire request in *before it lets you send a response* in order to maintain protocol compliance. For reasons that escape me it doesn't look like mod_perl exposes r-remaining, which is the thing to check when looking at the pending number of bytes the client wants to send. If I'm not wrong that should be easy enough for us to address. apreq won't read anything in in this situation tho, so you're good on that front. CGI.pm I'd bet doesn't try to read either if the pending data is too big, but I haven't looked at that codebase in a long time. - Original Message - From: Vincent Veyron vv.li...@wanadoo.fr To: mike cardeiro mcarde...@yahoo.com Cc: Torsten Förtsch torsten.foert...@gmx.net; modperl@perl.apache.org modperl@perl.apache.org Sent: Wednesday, February 8, 2012 4:24 PM Subject: Re: Interrupting a POST with file upload Le mercredi 08 février 2012 à 05:53 -0800, mike cardeiro a écrit : This is a fantastic list! Agreed. On the same note : I was recently presenting the legal case management app in my sig to an institutional client in the south of France, and the IT guy said that it had a 'fantastic architecture' (I assume he was talking about mod_perl). -- Vincent Veyron http://marica.fr/ Logiciel de gestion des sinistres et des contentieux pour le service juridique
Re: cms as an apache incubator project?
It was written by me under the terms of my contract with the ASF as a sysadmin. The rationale document discusses the motivations for doing the work as part of my work arrangement with Apache versus as a volunteer contributor. It is by design a cost-effective, highly-scalable,enterprise-grade CMS, but fairly bare-bones when compared to similaropen-sourceCMS's in terms of bundled features. It is very sysadminfriendly thowith very few administrative aspects that require activemanagement. Other than setting up and tearing down projects and tweaking svn authz files,it largely manages itself. I am not all that proficient at HTML/CSS design, so there's certainly room for improvement in the webgui. You can check out the current setup by visiting https://cms.apache.org with user 'anonymous' and empty password. The mod_perl based code itself is fairly advanced and makes heavy use of subrequests, so if anything you will learn how to do that properly in a mod_perl application once you've studied the codebase. mod_perl is one of the rare apps that fully supports subrequest calls in a dynamic language, so this aspect differentiates it from non-mod_perl based solutions. IOW what I've done with the webgui simply couldn't be done in any other httpd-based programming environment other than C itself, and that would've taken at least 20X the number of LOC just to write, much less debug. HTH - Original Message - From: Jim Schueler jschue...@eloquency.com To: Joe Schaefer joe_schae...@yahoo.com Cc: modperl@perl.apache.org modperl@perl.apache.org Sent: Thursday, January 12, 2012 9:44 AM Subject: Re: cms as an apache incubator project? T hanks for the quick response, Joe. Based on the links you forwarded earlier, I understand that this application was written in-house by ASF operations staff. Is that you? Reading the rationale discussion reminds me of tooth-pulling conversations I've had with managers convinced that there's an out-of-the-box turnkey solution that *exactly* meets their business requirements and has no life-cycle costs. When these managers eventually concede the need to hire software professionals, the conversation starts all over again. Essentially: OK, we'll invest in software development, then we'll release the code to the OS community, where it will be supported and maintained indefinitely by volunteers. These sunny optimists make it hard to earn a living. So while I'm thrilled to participate in an ASF project, I'm trying to establish some justification. Some examples: 1. Learn best practices in application development 2. Develop marketable expertise in CMS technology 3. Support mod_perl's viability as an enterprise solution Where I live, most of the local economy is supported by foundation and government grants. (Sign of the times.) I'm sure I know people who could capitalize on the right FOSS project. Justification is always the first step in any undertaking. And I couldn't find it anywhere using your links. Is there anything else you can send along? Thanks again! Sincerely, Jim Schueler
Re: Obtaining the Apache Content-type for a file
From the ASF CMS codebase: my $subr = $r-lookup_file($file); my $content_type = $subr-content_type || ; an undefined content-type will eventually defer to the default content-type if you've set that in your httpd config. - Original Message - From: André Warnier a...@ice-sa.com To: mod_perl list modperl@perl.apache.org Cc: Sent: Friday, January 13, 2012 2:17 PM Subject: Re: Obtaining the Apache Content-type for a file André Warnier wrote: David Booth wrote: On Fri, 2012-01-13 at 12:09 -0500, David Booth wrote: On Fri, 2012-01-13 at 16:06 +0100, André Warnier wrote: I have a PerlResponseHandler which processes some kind of logical document-id provided in a request, locates the corresponding real document on the filesystem, and returns it to the client via sendfile(). At the moment, this handler uses its own custom logic to determine the MIME type of the document and return it to the client as a Content-type HTTP header. My question is : instead of this custom logic, does there exist a way, via mod_perl, to obtain this target file's MIME-type from Apache, using Apache's own logic (mod_mime, AddType etc..) for that ? This isn't exactly what you asked for, but if you don't need to server anything else along with it, then perhaps you could use internal_redirect http://perl.apache.org/docs/2.0/api/Apache2/SubRequest.html#C_internal_redirect_ and let Apache set the Content-Type for you. If you do find the direct answer to your question, please post it, as I'm interested in this question also. P.S. I just noticed lookup_file: http://perl.apache.org/docs/2.0/api/Apache2/SubRequest.html#C_lookup_file_ I haven't tried it, but it sounds like it *might* do what you want. Thanks. I will have a look at both. I don't think I an use the internal_redirect in my case, lookup_file sounds interesting. I didn't think of looking there. I had a look, and it looks a bit like a circular argument.. I can do $r-lookup_file($my_path), but lookup_file is a method of Apache2::SubRequest (and returns an Apache2::SubRequest object). Apache2::SubRequest is a subclass of Apache2::RequestRec. Apache2::RequestRec has a finfo method, which returns an APR::Finfo object. The APR::Finfo object has wealth of information (see below), unfortunately apparently not what I'm after (the MIME type of $mypath, as resolved by mod_mime e.g.). $device = $finfo-device; # (stat $file)[0] $inode = $finfo-inode; # (stat $file)[1] # stat returns an octal number while protection is hex $prot = $finfo-protection; # (stat $file)[2] $nlink = $finfo-nlink; # (stat $file)[3] $gid = $finfo-group; # (stat $file)[4] $uid = $finfo-user; # (stat $file)[5] $size = $finfo-size; # (stat $file)[7] $atime = $finfo-atime; # (stat $file)[8] $mtime = $finfo-mtime; # (stat $file)[9] $ctime = $finfo-ctime; # (stat $file)[10] $csize = $finfo-csize; # consumed size: not portable! $filetype = $finfo-filetype; # file/dir/socket/etc $fname = $finfo-fname; $name = $finfo-name; # in filesystem case: Any other idea anyone ? We're now two to be interested in the answer.
Re: cms as an apache incubator project?
I originally developed the code as part of my job at the ASF. If we do go the incubator route i'd certainly want to participate as a committer. There have been a handful of responses on other lists but nobody with experience with modperl other than you and me. There is no time commitment that you need to make. It would be a volunteer driven effort going forward. Sent from my iPhone On Jan 8, 2012, at 5:04 PM, Jim Schueler jschue...@eloquency.com wrote: Hello Joe. I'm definitely interested and I'll take look at the links below. What is your role in this process? How many volunteers are you looking for? Any other response? About how much time is required.? Thanks! Jim Schueler On Mon, 2 Jan 2012, Joe Schaefer wrote: FYI: mod_perl based CMS currently in use at the ASF: http://www.apache.org/dev/cms http://www.apache.org/dev/cmsref Looking for a few volunteers to start an Apache project based on it... - Forwarded Message - From: Joe Schaefer joe_schae...@yahoo.com To: Apache Infrastructure infrastruct...@apache.org Sent: Tuesday, December 27, 2011 1:41 PM Subject: cms as an apache incubator project? Way back when the cms was first being implemented some people suggested making it a formal project. I pushed back on that issue at the time because it was so heavily tied into our infra that trying to productize it made little sense to me. As time progressed it became clear tho that I was the only person willing and able to work on the cms plumbing, and maybe now that there are several projects using the cms it's time to reask the question. Would it make sense to anyone to volunteer to work on the cms towards making it adoptable by other orgs? Keep in mind people can work on and adopt the current code right now as the svn tree is public: https://svn.apache.org/repos/infra/websites/cms The real issue becomes whether or not this community has the right skills and interests to help other orgs adopt it, and to modify the software to make that a feasible proposition. Any takers?
Fw: cms as an apache incubator project?
FYI: mod_perl based CMS currently in use at the ASF: http://www.apache.org/dev/cms http://www.apache.org/dev/cmsref Looking for a few volunteers to start an Apache project based on it... - Forwarded Message - From: Joe Schaefer joe_schae...@yahoo.com To: Apache Infrastructure infrastruct...@apache.org Sent: Tuesday, December 27, 2011 1:41 PM Subject: cms as an apache incubator project? Way back when the cms was first being implemented some people suggested making it a formal project. I pushed back on that issue at the time because it was so heavily tied into our infra that trying to productize it made little sense to me. As time progressed it became clear tho that I was the only person willing and able to work on the cms plumbing, and maybe now that there are several projects using the cms it's time to reask the question. Would it make sense to anyone to volunteer to work on the cms towards making it adoptable by other orgs? Keep in mind people can work on and adopt the current code right now as the svn tree is public: https://svn.apache.org/repos/infra/websites/cms The real issue becomes whether or not this community has the right skills and interests to help other orgs adopt it, and to modify the software to make that a feasible proposition. Any takers?
Re: How do you use mod_perl for your web application?
- Original Message From: Fred Moyer f...@redhotpenguin.com To: Perrin Harkins per...@elem.com Cc: David E. Wheeler da...@kineticode.com; mod_perl list modperl@perl.apache.org Sent: Thu, June 16, 2011 4:18:17 PM Subject: Re: How do you use mod_perl for your web application? On Thu, Jun 16, 2011 at 1:13 PM, Perrin Harkins per...@elem.com wrote: On Thu, Jun 16, 2011 at 4:07 PM, David E. Wheeler da...@kineticode.com wrote: Whatever old man! I know, it's just a reality of working on applications that have been around for years. These tools are so reliable that they tend to stick around. If I started something new I would probably use Plack, since I've enjoyed using similar stuff in Python. Maybe I'm not completely grokking how people are starting new projects using Plack, but it seems like the way to go is to not use Plack itself to write the code, but to use one of the many web frameworks (Mason2, Catalyst, Mojolicious) and then use Plack to specify what webserver is used. Plack is just middleware. There is a Mason handler for Plack, so it almost seems like you could migrate your existing application to the Plack middleware stack while changing little in your Mason codebase. I see the role of mod_perl2 going forward as not something that applications are written on, but something that webserver middleware interfaces with. Sigh. The big win with mod_perl2 is you get to interface with the rest of the C modules for httpd, often via subrequests. At the ASF we've been running mod_perl2 as our frontline mailserver for over 5y, and recently I wrote an ASF-wide CMS with it that's gaining more and more users as time goes on, in under 5K LOC. Haven't seen the need for app frameworks because most of my code is mod_perl2 specific- it just won't work in any other webserver.
Re: How do you use mod_perl for your web application?
- Original Message From: Fred Moyer f...@redhotpenguin.com To: Joe Schaefer joe_schae...@yahoo.com Cc: mod_perl list modperl@perl.apache.org Sent: Thu, June 16, 2011 5:01:49 PM Subject: Re: How do you use mod_perl for your web application? On Thu, Jun 16, 2011 at 1:30 PM, Joe Schaefer joe_schae...@yahoo.com wrote: Sigh. The big win with mod_perl2 is you get to interface with the rest of the C modules for httpd, often via subrequests. At the ASF we've been running mod_perl2 as our frontline mailserver for over 5y This is Apache2::Qpsmtpd right? Nice module. , and recently I wrote an ASF-wide CMS with it that's gaining more and more users as time goes on, in under 5K LOC. Haven't seen the need for app frameworks because most of my code is mod_perl2 specific- it just won't work in any other webserver. I guess I should rephrase what I said earlier; I don't see use of mod_perl2 for web applications going away. I see the usage pattern for Perl based web applications that use frameworks like Catalyst et al becoming one where there is less usage of tightly coupled modules such as Apache::Session and Apache::DBI. To me writing to a generic webserver API is not all that exciting. Python people love it, but they've never had a proper exposure to httpd in the first place. Yes it means you gain some portability, but the downside is that you lose an awful lot of power that comes from the existing open source module ecosystem for httpd. That's not easily replaced, no matter what others may say. The ability to interface with the httpd C modules is a big win that I don't think a lot of users appreciate until their application gets big enough to cause pain. Output compression is one area I've seen people struggle with in Perl land, and write elaborate hacks into their Catalyst application, when they could do the same thing in httpd.conf with 'Include conf/deflate.conf' and just stuff all the mod_deflate directives in that file. Yup. Content negotiation is another area where people come up with lotsa sloppy hacks. Just run a subrequest with content-negotiation enabled and be happy- it just works.
Re: undefined symbol modperl_xs_sv2request_rec
The next release of apreq will contain a package called
APR::Request::Magic, for apps that are meant to be portable
between cgi and mp2. What you've reported isn't a bug in
apreq or mp2, it's a bug in how your app uses apreq. APR::Request::Apache2
shouldn't be used outside a running modperl server. If
you change your code to use APR::Request::Magic, it'll
work in both contexts.
HTH
- Original Message
From: Mark Hedges hed...@formdata.biz
To: modperl@perl.apache.org
Sent: Thu, February 3, 2011 4:06:59 PM
Subject: undefined symbol modperl_xs_sv2request_rec
A change in Module::Build recently brought it in line with
the behavior of ExtUtils::MakeMaker, which caused an error
to crop up in test cases that 'require_ok'.
# Error: Can't load
'/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/APR/Request/Apache2/Apache2.so'
for module APR::Request::Apache2:
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/APR/Request/Apache2/Apache2.so:
undefined symbol: modperl_xs_sv2request_rec at
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line 230.
# at
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Apache2/Request.pm
line 3
# Compilation failed in require at
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Apache2/Request.pm line
3.
# BEGIN failed--compilation aborted at
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Apache2/Request.pm line
3.
... but only with `Build test` and not `prove -r t/`.
This is because $ENV{PERL_DL_NONLAZY} is now always set by
Module::Build::Base when running the test suite, which makes
it try to resolve all undefined symbols.
This only seems to happen in the test script trying to
'require' packages that use Apache2::Request (libapreq2) but
people seem inclined to think it is a problem with mod_perl
and not apreq.
mod_perl 2.0.4 6.el5, perl 5.8.8 32.el5_5.2 CentOS
Any ideas? Thanks. --mark--
-- Forwarded message --
Date: Thu, 3 Feb 2011 01:02:16 -0500
From: Michael G Schwern via RT bug-module-bu...@rt.cpan.org
To: mar...@cpan.org
Subject: Re: [rt.cpan.org #65382]
URL: https://rt.cpan.org/Ticket/Display.html?id=65382
If that fixes it then you're likely papering over an error.
perlrun explains PERL_DL_NONLAZY and why you'd set it to true for tests.
PERL_DL_NONLAZY
Set to one to have perl resolve all undefined symbols when
it loads a dynamic library. The default behaviour is to
resolve symbols when they are used. Setting this variable
is useful during testing of extensions as it ensures that
you get an error on misspelled function names even if the
test suite doesn't call it.
So the test is trying to tell you that modperl_xs_sv2request_rec is not
defined in your shared library.
Also, `prove -I blib` is not correct. You want `prove -b` which will pull
in
blib/lib and blib/arch.
On 2011.2.3 9:08 AM, Mark Hedges via RT wrote:
It looks like this is the problem, or at least, this fixes it for me.
Why does do_tests() need to explicitly set this? --m--
--- /usr/lib/perl5/site_perl/5.8.8/Module/Build/Base.pm.orig 2011-02-02
15:04:07.0 -0800
+++ /usr/lib/perl5/site_perl/5.8.8/Module/Build/Base.pm 2011-02-02
15:07:21.0 -0800
@@ -2667,8 +2667,6 @@
my $tests = $self-find_test_files;
- local $ENV{PERL_DL_NONLAZY} = 1;
-
if(@$tests) {
my $args = $self-tap_harness_args;
if($self-use_tap_harness or ($args and %$args)) {
--
10. Not allowed to purchase anyone's soul on government time.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: failure to build Apache2::Request
FreeBSD has a port for www/p5-libapreq2 - Original Message From: William Bulley w...@umich.edu To: modperl@perl.apache.org Cc: Issac Goldstand mar...@beamartyr.net Sent: Thu, January 27, 2011 2:16:45 PM Subject: failure to build Apache2::Request According to Issac Goldstand mar...@beamartyr.net on Thu, 01/27/11 at 13:59: It looks like it's missing .h files from mod_perl... Might I suggest you post this question (with the build output) to modperl@perl.apache.org? There are some people there who knwo mod_perl better than myself who might be able to quickly figure out what's wrong... Issac On 27/01/2011 20:40, William Bulley wrote: According to Issac Goldstand mar...@beamartyr.net on Thu, 01/27/11 at 13:37: I must have missed that bit, but yes, it does need mod_perl (unless you want to disable the Perl glue, which judging by your getting it from CPAN, I assume you want). The reason is that the APR C library Perl glue, needed by the apreq Perl glue (aka Apache2::Request) is bundled in mod_perl 2 I don't understand everything you say above. I was forced to use CPAN since there was no Apache2::Request port on my FreeBSD workstation. I ended up building mod_perl2 and things seemed to work better with respect to installing Apache2::Request via CPAN. Yet it still errors out (see the attachment I last sent you). I need to build Apache2::Request so I can build other Perl modules that depend on it (and the application which depends on all these and more). What do I need to do to get the CPAN module to build correctly? The needed file is there, but the INC chain is missing the full path to that include file. I don't know if I should change the *.c (or *.xs in this case) source file, of somehow change the Makefile so that the correct path is included in the INC make variable. Your advice is urgently sought! Thanks.:-) I have attached the complete build log for Apache2::Request which shows the failure (near the end) to compile Request.c due to an incorrect INC path for an include file that does exist, but not where the Request.xs file thinks it is (using a #include file.h statement). This is on FreeBSD 8.2-PRERELEASE with the following ports in place: ap22-mod_perl2-2.0.4_2,3 apache-2.2.17_1 Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: Authentication and cookies
OP, see
https://svn.apache.org/repos/infra/websites/cms/webgui/lib/ASF/CMS/Cookie.pm
for typical APR::Request::Cookie usage with FreezeThaw as serializer. Unless
you
want to use arrays this is one of the ways to deal with hashrefs as cookie
values.
In your calling code you'd do something like this
my $apreq = APR::Request::Apache2-handle($r);
my $jar = $apreq-jar;
$jar-cookie_class($cookie_package);
my $cookie = $jar-get('ls_authentication');
my $hashref = $cookie-thaw if $cookie;
...
- Original Message
From: André Warnier a...@ice-sa.com
To: mod_perl list modperl@perl.apache.org
Sent: Sun, January 23, 2011 3:09:01 PM
Subject: Re: Authentication and cookies
Hi.
This is a suggestion to solve what I understand of your problem, but
slightly
differently.
(And I admit that it is because I do not know if you can do that with a
cookie-jar, I have never tried; but what is below, I did try and it works).
The idea is as follows.
A cookie is useful in the sense that it is an information store which you
can offload to the browser by means of a Set-Cookie header /at the moment
when you send a response to the browser/, and of which you can be (almost)
sure
that when the browser sends its next request to your server, it will re-send
this same cookie along with the new request (in a Cookie header.
So it saves you from creating a local store on the server, and anyway have
to
manage some way for the browser to receive and send back some session-id
that
allows your server to retrieve the corresponding local store entry.
But a cookie is less useful at the server level, as a means to save
information between Apache (and mod_perl) request processing phases.
For that, you have a better choice : the pnotes.
http://perl.apache.org/docs/2.0/api/Apache2/RequestUtil.html#C_pnotes_
In your first handler (e.g. PerlAccessHandler), you get and decode the
cookie
sent by the browser; you store the user-id, and whatever else you have from
the
cookie, in a perl hash for example, and then store this perl hash as an entry
in
the $r-pnotes.
$r-pnotes(key = $hashref);
In later phases of the same request, another handler can retrieve this same
hash from the $hashref = $r-pnotes(key).
E.g. in the PerlAuthenHandler, instead of decoding the cookie again, you
retrieve the hash, and check the values stored in the hash.
Same thing in a PerlAuthzHandler.
Then right before you create the response to the user (e.g. a
PerlFixupHandler), you retrieve this hash again, and you create the cookie to
send along with the response, in the HTTP response headers.
At the end of the request, the pnotes disappear automatically.
Actually, it is a bit more complicated than that, because Web AAA is quite
spaghetti-like in terms of logic. But that, I suppose, you have already
found
out.
Dan Axtell wrote:
I'm trying to upgrade mod_perl authentication/authorization handlers for
application menu to be more fine-grained by using cookies. The basic idea is
- restrict a script alias in httpd.conf with basic authentication calling
the custon handlers
- validate the user ID/password in the authentication handler, and look up
role and client access info; stash in cookie. If a valid cookie is already
there, authenticat
- in authorization, check for cookie, reset if it's not there, and
authorize
based on role and client information
- in menu app, check for cookie, and configure output depending on user's
role.
What happens is that even though the browser shows a cookie with the
correct
info, the menu ends up with a no cookie found error, and the logs show
neither the authorization handler nor app are seeing the cookie. Hitting
refresh on the menu shows both handlers seeing the cookie and the menu comes
up
correctly.
I've tried using both CGI::Cookie and Apache2::Cookie; I get the same
problem either way. Currently the authentication handler sets the cookie as
follows:
my $cookie = Apache2::Cookie-new($r, -name = 'ls_authentication',
value = { user_id = $user, digest = crypt($password, $salt),
role_id = $ur{role_id}, clients = $client_list });
if ($cookie) {
$cookie-bake($r);
} else {
warn Unable to make cookie;
}
I get no warning, and the cookie looks fine in the browser's debug tool,
but the next handler and app just don't see it. This is how I try and read
it
in the authorization handler:
my $jar = Apache2::Cookie::Jar-new($r);
my $cookie = $jar-cookies('ls_authentication');
if ($cookie) {
$have_cookie = 1;
my %fields = $cookie-value;
if ($fields{'user_id'}) {
$user = $fields{'user_id'};
}
if ( $fields{'role_id'} ) {
$user_role = $fields{'role_id'};
}
if (
Re: Uploading Files bigger the 64M
It's a bug in the merge code for mod_apreq2. Basically you have to set APREQ_ReadLimit to its max value in the main server's context (not in a vhost or Location or Directory config). Otherwise use the code in apreq's trunk. From: Hibbard, Timothy hibb...@ohio.edu To: modperl@perl.apache.org modperl@perl.apache.org Sent: Tue, January 25, 2011 1:23:45 PM Subject: Uploading Files bigger the 64M Uploading Files bigger the 64M I am having all sorts of troubles uploading files bigger then 64M using mod_perl2. Any file I try to upload that is bigger then 63M I get the following error. (20014)Internal error: Content-Length header (723283299) exceeds configured max_body limit (67108864) So I told myself lets do a little research It is Perl so this should be easy to fix. After a little of researching I found the APREQ2_ReadLimit parameter for the httpd.conf. So I added this to my httpd.conf. APREQ2_ReadLimit 1024M (1 Gig) Restarted Apache and tried again Still no luck with same error message. Back to researching. I found 2 more things which I thought would solve my problem. I found POST_MAX: my $req = Apache2::Request-new($r,POST_MAX =100 * 1024 * 1024); And also $req-read_limit(100 * 1024 * 1024); So I tried playing with these settings and all I get now is “Conflicting information” in my log files. As soon as I set POST_MAX or read_limit to anything below 67108864 it works fine for all files less then 64M in size. How can I get mod_perl2 to upload a 700mb file. If you need sample code of what I am doing I am more then happy to provide it. Thanks in advance, Tim Hibbard Senior Program Engineer Ohio University Athens, Ohio 457-1
Re: Internal apreq error
I doubt that helps much. Looking more carefully at the mfd parser code, the only places I can see where it will return an APREQ_ERROR_GENERAL (initial) status are when 1) the Content-Disposition headers in a part have a form-data element but no name attribute. 2) the level of nested parts exceeds 8. The parser *should* return APR_EOF in cases where the stream has aborted prematurely. - Original Message From: Issac Goldstand mar...@beamartyr.net To: modperl@perl.apache.org Sent: Sat, December 4, 2010 11:09:01 AM Subject: Re: Internal apreq error Try setting LogLevel to debug? On 03/12/2010 18:24, Rolf Schaufelberger wrote: Hi, (server Apache/2.2.14, OS Ubunto 10.04 LTS, libapreq 2.12.2 ) I'm getting sometimes an Internal apreq error which appears in my apache log with no more information that just that string. I would like to know where this error happens and why. Can I force apreq to be a bit more verbose about errors ? The problem is, I can't reproduce the error, so running apache in debugger is no option. The only thing I (mean to) know so far: The error happens during large file uploads. I have a form where a user can uploald 13 files which may have have more than 100MB. The apreq is patched to allow more that that (MAX set to 1000MB). Regards Rolf Schaufelberger
Re: Internal apreq error
- Original Message From: Rolf Schaufelberger r...@plusw.de To: Mod_perl users modperl@perl.apache.org Sent: Fri, December 3, 2010 11:24:06 AM Subject: Internal apreq error Hi, (server Apache/2.2.14, OS Ubunto 10.04 LTS, libapreq 2.12.2 ) I'm getting sometimes an Internal apreq error which appears in my apache log with no more information that just that string. I would like to know where this error happens and why. Can I force apreq to be a bit more verbose about errors ? The problem is, I can't reproduce the error, so running apache in debugger is no option. The only thing I (mean to) know so far: The error happens during large file uploads. I have a form where a user can uploald 13 files which may have have more than 100MB. Most likely the user interrupted the upload. It generally means the parser's input stream was missing expected stuff. The apreq is patched to allow more that that (MAX set to 1000MB). You shouldn't have to patch apreq. There is a config setting for that: APREQ2_ReadLimit.
Re: [RELEASE CANDIDATE] libapreq2 2.13 RC
There are still some build issues surrounding gmake on FreeBSD, but I assume the ports dude knows how to deal with those. +1 for release. - Original Message From: Issac Goldstand mar...@beamartyr.net To: apreq-...@httpd.apache.org Cc: d...@httpd.apache.org; mod_perl Dev d...@perl.apache.org; modperl@perl.apache.org Sent: Thu, November 25, 2010 2:34:47 PM Subject: [RELEASE CANDIDATE] libapreq2 2.13 RC -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After a year and a half, the apreq team would like to release version 2.13 of libapreq. Please test and vote on the following tarball: http://people.apache.org/~issac/libapreq2-2.13.tar.gz http://people.apache.org/~issac/libapreq2-2.13.tar.gz.asc http://people.apache.org/~issac/libapreq2-2.13.tar.gz.md5 Thanks, folks! Issac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzuulcACgkQ7bEFiW+VIthPngCeN1V8AzC9lsuCWjJt/EsJnZ0r DS0AniVDbyqUi6GO74mefdyTACi2wa+5 =OF6j -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
Re: Getting a / when regex should produce nothing
- Original Message
From: Chris Bennett ch...@bennettconstruction.biz
To: ch...@bennettconstruction.biz; modperl@perl.apache.org
Sent: Sun, April 25, 2010 8:17:07 AM
Subject: Re: Getting a / when regex should produce nothing
Is there a better regex for .?\w?\w?
I want a . letter letter not . letter
or just two letters etc.
(?:\.\w{2})?
This regex is to prevent read or write access to
files up the directory
tree or non html files. There is also a username
password for any write
access.
undef my $variable is not a common
idiom but is seen in Programming Perl
and other places. Is there any reason
I should use my $variable = undef?
More typing. :)
What's wrong with just typing my $variable;?
Why was I getting
a / back? Is that an artifact
from the perl internals?
In your previous code you didn't check that the pattern
had matched before using $1. In the case when your pattern
doesn't match, $1 remains unchanged from whatever last
set it. There's probably some code earlier on, or internal
to mod-perl, which does a (successful) pattern match that
sets $1 to /.
The lesson here should be to always check the return value
of your regexps for success, especially when you've used
capture variables in your code like $1-$9.
Re: APR::Request gets Symbol Not Found
Did you remember to load mod_apreq2 into httpd? Typically requires a LoadModule apreq_module modules/mod_apreq2.so - Original Message From: Bill Karwin b...@karwin.com To: modperl@perl.apache.org Sent: Sat, November 21, 2009 1:27:31 PM Subject: Re: APR::Request gets Symbol Not Found Perrin Harkins-3 wrote: You can't load some of the Apache:: modules from the command-line. They depend on the apache environment to run. Try loading it from your httpd.conf instead. Hi Perrin, thanks for your quick reply. I tried your suggestion but I got a similar error as I got from the command line. I added this in httpd-vhosts.conf: PerlModule APR::Request I tried restarting Apache and this appeared in my Apache error_log: [Fri Nov 20 23:22:36 2009] [error] Can't load '/opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/APR/Request/Request.bundle' for module APR::Request: dlopen(/opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/APR/Request/Request.bundle, 1): Symbol not found: _apreq_hook_disable_uploads\n Referenced from: /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/APR/Request/Request.bundle\n Expected in: dynamic lookup\n at (eval 2) line 3\nCompilation failed in require at (eval 2) line 3.\n Regards, Bill Karwin -- View this message in context: http://old.nabble.com/APR%3A%3ARequest-gets-Symbol-Not-Found-tp26419579p26459073.html Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: Confusion over Apache2::Request and Apache2::RequestRec
Apache2::Request is a derived class of Apache2::RequestRec,
so what you're doing is perfectly ok.
From: Douglas Sims ratsb...@gmail.com
To: modperl modperl@perl.apache.org
Sent: Thursday, August 20, 2009 3:20:59 AM
Subject: Confusion over Apache2::Request and Apache2::RequestRec
I'm confused about something and I wonder if anyone can help me to understand
what's going on. The code shown below works fine but as I was looking over
this before changing something else I realized that it probably shouldn't.
I'm using an Apache2::Request object to return a connection object to get the
remote_ip but the documentation for Apache2::Request doesn't show a connection
method - that's in Apache2::RequestRec.
Why does connection() work on an Apache2::Request object?
Thanks!
-Doug
Apache2::Request:
http://httpd.apache.org/apreq/docs/libapreq2/group__apreq__xs__request.html
Apache2::RequestRec:
http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_connection_
In the PerlResponseHandler:
my $requestrec = shift if $ENV{MOD_PERL};
my $request = Apache2::Request-new($requestrec);
my $session = Sessions-new($request, $mysql);
{package Sessions;
sub new {
my $class=shift;
my $self={};
bless ($self, $class);
$self-{REQUEST}=shift;
$self-{DBH}=shift;
{...snip...}
$self-{DBH}-do('INSERT INTO failedloginattempts (username, password,
ip, session, attempttime) VALUES
('.$self-{DBH}-quote($username).','.$self-{DBH}-quote($password).',
INET_ATON('.$self-{DBH}-quote($self-{REQUEST}-connection()-remote_ip).'),
'.$self-{DBH}-quote($self-{SESSION}).', NOW())');
Re: decline and fall of modperl?
- Original Message From: john edstrom edst...@teleport.com To: Octavian Rasnita orasn...@gmail.com Cc: modperl modperl@perl.apache.org Sent: Friday, March 27, 2009 1:13:18 PM Subject: Re: decline and fall of modperl? FWIW, I'm enjoying this diverting discussion and think it should stay here. Clearly, its an organic outgrowth meeting a need of the other business in this list. Anybody whose been here a couple of years knows this discussion is 100% offtopic for this mailing list. Hell, it isn't even topical of the Subject header. That won't stop people who have nothing else to offer the list except for their opinion to mutter onwards, because we tend not to boot people off the list who abuse it unless it is obviously habitual. Comparative analysis of programming languages has nothing whatsoever to do with modperl, or even anything to do with the real needs of this community of users. It's simply an exercise in argumentation based on personal experience alone by people who have absolutely no knowledge of any actual relevant statistics on the subject (assuming there even *are* any such things). On Fri, 2009-03-27 at 10:35 +0200, Octavian Rasnita wrote: From: David Ihnen en the newer perl modules on cpan started to use OOP, and I guess this is because OOP is better, even though under perl it usually makes the programs run slower. Perl's speed, even under oop, is good enough. OOP makes the libraries easier to maintain and extend. You should well be an advocate of good-enough - thats what the php programmers are all about, right? I know this, but the perl docs tell the truth that perl OOP is slower than functional perl and the beginners don't like to hear that using OOP under Perl make it slower. Its also worth noting that it is often the case that using an efficient OO package of, say 500 lines of code, will obviate the need for maybe 1,000 lines of procedural code that might be needed to do the same thing. Its not always a simple comparison. Doing y = x + y in OO perl is certainly a losing strategy, but manipulating a large XML document in OO perl is almost certainly better than a procedural approach. Somewhat off topic, I've noticed that nobody has yet mentioned Perl's fabulous Inline module. On more than one occasion I've had to resort to Inline::Java to take advantage of some proprietary jar or standard java class that does some obscure jiggery-pokery so deeply buried in vast tangled class hierarchies that it can't be found, fathomed or faked by mortal man. Just write a simple java shim to massage data transfer between java and perl domains and you're off to the races! If the off-loaded work is big enough the performance hit is negligible. (The first hit takes some time to instantiate a java interpreter thread but everything after that runs quick as a bunny.) I've also had to invoke perl inside php on occasion because the available php html parser was just too clunky to do what I needed. (that was in a Drupal site) Once I learned that trick my toughest php programming challenge was to not use it everywhere. :-) The barriers between languages aren't insuperable; you needn't swing a project to one language just to use some key package you need/want in that language. One last gratuitous point in passing is that one of my chief gripes about php (chiefly, but also Java with its ever-growing uncountable infinity of classes and interfaces) is that php is TOO function-rich. I find I spend a lot of time thumbing through documentation looking for which of the two dozen regex thingies to use in a particular case instead of thinking about the program I'm writing. Perl only has one, really. Although there are more than one way to do things in both perl and php, it seems to me that in perl you can often do it by something as simple as rearranging your brackets while in php you have to suss out the best reserved special function for that particular task if you want to benefit from its inherent efficiencies. My point is that discussions of how easy/difficult it is to learn one language or another rarely come to grips with the real finite cognitive limit of the human mind to keep more than 5 balls in the air at one time. Its really hard to be think creatively about evaluating 5 different strategies when you're forever changing mental contexts to look up a dozen damned functions in some damned index. I've been writing php and perl for about the same length of time but I have never once felt that I understood php. On the other hand I haven't had to consult my Programming Perl book more than a dozen times in the past few years. There needs to be an objective and quantitative measure of ease-of-learning based on empirical measures of how badly beaten up your copy of Programming
Re: decline and fall of modperl?
- Original Message From: john edstrom edst...@teleport.com To: Joe Schaefer joe_schae...@yahoo.com Sent: Friday, March 27, 2009 2:21:08 PM Subject: Re: decline and fall of modperl? If you say so. I'll respect that, but I don't agree with it. I already subscribe to about 30 mail lists and won't subscribe to the advocacy list because I have no particular interest in advocacy per se. Seeing it discussed in a context I care about does interest me though. Apache operates on the notion of people volunteering to help make the community's goals come to fruition. The utility of this particular list is that users can communicate with one another to solve common problems, and maybe even offer a patch for the developers to incorporate into the next release. That sort of activity has all but dried up here, and I don't know what the reasons for that are. It could be that the codebase is too good, in the sense that there isn't a lot of stuff that people need fixed. That has happened to other projects at the ASF, and knowing all the hard work Stas Bekman and company put into this project, it may very well be true here. The goal of modperl is to provide access to httpd's guts so people with advanced needs can tweak httpd using a scripting language. Speed is a nice bonus, but not the full story. For example, every email sent to apache.org passes through a mail server that's implemented in mod_perl2. That's very cool IMO; it solved a major scaling problem for Apache, and it's the type of application that wasn't even remotely possible with the 1.x codebase.
Re: decline and fall of modperl?
- Original Message From: Octavian Râsnita orasn...@gmail.com To: modperl modperl@perl.apache.org Sent: Friday, March 27, 2009 3:25:44 PM Subject: Re: decline and fall of modperl? From: Joe Schaefer Comparative analysis of programming languages has nothing whatsoever to do with modperl, or even anything to do with the real needs of this community of users. It's simply an exercise in argumentation based on personal experience alone by people who have absolutely no knowledge of any actual relevant statistics on the subject (assuming there even *are* any such things). The original message that started this thread was: One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. Consultants who don't contribute anything to this community aren't our concern- nor should they be. Of course this question should be answered with language comparisons, Hardly. What matters is the quality of the software and whether or not it meets the customer's needs. There's nothing wrong with recommending the right tool for the job, even if the right tool isn't implemented in perl. and of course that those answers should be based on our opinions and experience, because if there would be very scientific studies that show which of the languages are modern and which are obsolete, which are good and which are bad, it could be very simple to find the sites with those scientific studies using Google and it wouldn't need to be asked on a mailing list. Here is a good article written by Ovid - Perl 5 is dying: http://use.perl.org/~Ovid/journal/38010?from=rss We should also remember that somebody discovered that perl 5 is dying 9 years ago, and this was the thing that created the idea of perl 6, that should be totally different. Languages don't die, they aren't people. People will continue to use perl5 for the forseeable future, even after perl 6 is finally released.
Re: decline and fall of modperl?
- Original Message From: Octavian Râsnita orasn...@gmail.com To: modperl modperl@perl.apache.org Sent: Friday, March 27, 2009 5:26:43 PM Subject: Re: decline and fall of modperl? From: Joe Schaefer The original message that started this thread was: One of our customers is doing a detailed review of a mason/modperl ERP app we've built for them since 2001. Prodded by some buzzword-compliant consultants they are expressing concerns that the app's underlying technologies - perl, modperl and mason - are becoming obsolete. They feel that a web application framework must have 'rails' or some other buzzword in its name. Consultants who don't contribute anything to this community aren't our concern- nor should they be. If they are consultants, it means that they contribute. The contribution is not only made of code and POD documentation or translations, but also of answers to the questions put by others. You're not even in the ballpark. Consultants are hired and fired based on the quality and relevance of the information they provide. They're supposed to make recommendations based on what is in their client's best interests. That's not a contribution to this community nor any other, it is a *paid for* service. A contribution to a *community* would be to offer gratis advice on a mailing list, ostensibly to help the community reach its objectives. Nothing I see in this thread looks like a contribution to the mod_perl community, sorry. Of course this question should be answered with language comparisons, Hardly. What matters is the quality of the software and whether or not it meets the customer's needs. There's nothing wrong with recommending the right tool for the job, even if the right tool isn't implemented in perl. The question wasn't about the quality of perl, but the poster wanted to know if Perl/Mason/mod_perl are obsolete. A language could be very good but obsolete because there are other better tools, or because other tools are prefered even if they are not so good, and it could be easier to find programmers that use those new tools. and of course that those answers should be based on our opinions and experience, because if there would be very scientific studies that show which of the languages are modern and which are obsolete, which are good and which are bad, it could be very simple to find the sites with those scientific studies using Google and it wouldn't need to be asked on a mailing list. Here is a good article written by Ovid - Perl 5 is dying: http://use.perl.org/~Ovid/journal/38010?from=rss We should also remember that somebody discovered that perl 5 is dying 9 years ago, and this was the thing that created the idea of perl 6, that should be totally different. Languages don't die, they aren't people. People will continue to use perl5 for the forseeable future, even after perl 6 is finally released. Die is just an expression that wants to tell that the language is not used by more and more programmers, but by fewer. Usage statistics are irrelevent to the vitality of a language. What's relevant to the perl community is something like how many module maintainers have abandoned their codebases. Do you have any information about how many modules are on CPAN that are no longer supported? And to bring it back to mod_perl, how many of those are Apache modules?
Re: decline and fall of modperl?
- Original Message From: David Stewart david.stew...@eviesays.com To: modperl modperl@perl.apache.org Sent: Friday, March 27, 2009 6:39:08 PM Subject: Re: decline and fall of modperl? I'm not really sure why it wouldn't be a good idea to try and educate consultants about the value of Perl / mod_perl. That's called advocacy, and as I said before, there's a mailing list set up for that for people who actually want to *do* some of that instead of issue general gripes on a thread called decline and fall of mod_perl. I don't mean to suggest that such activity is unimportant, just to point out again that it's not topical on a user support list like this one. It seems to be consultants have a lot of influence over what tools get used for projects they work on. The fact that many don't have much if any exposure/knowledge of Perl and mod_perl certainly hurts the Perl community. Discussing the advantages / disadvantages of Perl and mod_perl so that we can all help educate the consultants and institutions we work with about how mod_perl can benefit certain projects seems like a rather important task. [...more advocacy stuff...] It's hard to argue that Latin is on the same footing as English when Latin is only spoken by a tiny handful of people even though it has a lot of great history. Technology, like language, generally lives and dies by its user-base. Usage is also directly related to developer enthusiasm in most cases. A developer isn't going to want to spend time maintaining a module if no one is using it. Having lots of users of your code doesn't necessarily translate to putting food on a developer's dinner table. TicketMaster funded a lot of the work that went into mod_perl2, largely out of their own self- interest, but that is a *contribution* that many of us are thankful for. It's a lot easier to justify spending weeks or months getting a module ready for CPAN if you have some reasonable expectation that a lot of people are going to benefit from it. I would like to think that ego stroking isn't what motivates developers to write perl code. They do it because the perl community is still by and large a gift culture, and if you want to be a full partner in the community you really should pony up to the table and contribute something. Whether or not 10 people use your code or 100,000, if your users are happy and you are approachable regarding bug reports, then the fact that you are *contributing* to intellectual assets a user community means something.
[OT] Advocacy (was Re: decline and fall of modperl?)
Could we PLEASE move this lovely conversation to the advoc...@perl.apache.org mailing list? We have an entire mailing list dedicated to baloney of this sort; please use it so the rest of us trying to provide this little community with meaningful software and support don't have to wade through it. Thanks! From: David Ihnen dav...@norchemlab.com To: Octavian Râsnita orasn...@gmail.com Cc: modperl modperl@perl.apache.org Sent: Thursday, March 26, 2009 5:10:58 PM Subject: Re: decline and fall of modperl? Octavian Râsnita wrote: From: Rolf Banting Functions are first class citizens in Perl - so you get functional programming built in. You don't in Java. Even the newer perl modules on cpan started to use OOP, and I guess this is because OOP is better, even though under perl it usually makes the programs run slower. Perl's speed, even under oop, is good enough. OOP makes the libraries easier to maintain and extend. You should well be an advocate of good-enough - thats what the php programmers are all about, right? How are standards of OO quantified and compared? Simple. They should follow the modern standards, standards made by those who have the power to promote their way - Sun, Oracle, IBM, Microsoft. This is because if a student learns C#, and learns Java, he will find easier to learn an OOP style similar to that from Java than a way like the one used in Perl. I can't believe you would say that the particular syntactical constructs used in the object oriented declaration is even slightly relevant to the usability of the language. saying 'package' instead of 'class'? Saying 'use' instead of 'import'? I'm agog. Any language transition involves learning new syntactical constructs for the new environment you're in. And thats the only real difference between The Java/C# 'style' and perl, is it not? THe keyword syntaxes? As for design patterns, perl does them with fewer hoops than the other languages - which is what a learning student needs to learn. And anyway, for the beginners, this is not a big problem. The biggest problem is that perl is harder to learn. The programmers might want to learn a language for a year, and get a job, and after this they hope that they will find time to learn the chosen language better while they have a job. Harder to learn than what? Is there any evidence for this? Yes. Most PHP programmers I know, that also tried to learn Perl told me that PHP is more easy to learn and to use. And C is easier to use than C++, but you don't see anybody going around saying that they should use C to write enterprise applications these days. Unfortunately I think some are trying to be written in php. There are very many recent books that teach Perl. Why is recent important? The language features haven't changed much so why would the learning resources? Because Catalyst is very fast changing, DBIx::Class the same, HTML::FormFu the same, CGI::Application the same, because Moose appeared, but there are no very many books that talk about them (or other modules). The moment a fast-changing thing is documented, the documentation is out of date. Its a fundamental problem with dead-tree editions of anything. I'm not surprised that there aren't books on these things. Mostly because the documentation is readily available online and anything written is obsolete before it hits the presses. Perl is great, but I think it will remain a niche language for a long period, even though we know that we can do everything with it. The truth is that we can't do really everything with it. There are applications made in Java that do annimation, graphic games, search engines, and many other things that we can't do only by using perl, without C or other languages. Yes, we cannot do everything with perl. But that is okay. What is important to remember is what we CAN do with perl. Even when you have a high-performance graphical processor module written in C/C++/Java, the business rules, glue, and associated logic that is not fine-grained performance critical are best implemented in a scripting language just like Perl. Implementing your application in C++ because you need *some* fine-grained performance critical code is, in my experience, foolish. Yes, implement your critical code in a tight language. But when most of the application just comes down to glue, field name translation, and rules checking - this is better scripted than coded in a compiled language. I've wasted tens of thousands of dollars of my employers time compiling and debugging because of the application's shortsighted architecture put many of the business rules in C++ instead of a script like perl! (it was all the worse because at an arbitrary divider, some of the rules WERE in a not-quite-perl like configuration language - if they had taken it all the way a job of months would have taken weeks) It was quite a mind-blow when I realized that the c++ application that took a gig of
Re: dealing with empty field names in query
- Original Message From: Jonathan Vanasco jvana...@2xlp.com To: modperl modperl@perl.apache.org Sent: Friday, February 13, 2009 3:30:20 PM Subject: Re: dealing with empty field names in query On Feb 6, 2009, at 4:58 PM, Phil Carmody wrote: In those name/value pairs, according to HTML 4 at least, the names must begin with a letter [A-Za-z]. The empty string does not do so. Garbage in, garbage out. Part of me agrees with that philosophy. Another part of me is more practical. We had to stop using libapreq2 for cookies, because we found out that wordpress (being a shoddy piece of software) was generating invalid cookies at times. when apreq encountered it, it segfaulted. What version of apreq was this? And did you report it to the apreq-dev@ mailing list? so while the engineering part of me is okay with garbage in / garbage out, the management side of me says sometimes you have to expect bad data and try to make the best of it - otherwise you lose customers and revenue.
Re: [RELEASE CANDIDATE] libapreq2 2.11
+1 for me (tested on debian). - Original Message From: Issac Goldstand mar...@beamartyr.net To: apreq-...@httpd.apache.org Cc: d...@httpd.apache.org; modperl@perl.apache.org Sent: Tuesday, January 20, 2009 4:48:30 AM Subject: [RELEASE CANDIDATE] libapreq2 2.11 The apreq developers are planning a maintenance release of libapreq2. This version addresses several bugfixes and includes new features. Changes since the last release version include: - Interactive CGI module [issac] Allow cgi module to interactively prompt for parameters and cookies when running a script from the command line and not from a CGI interface - Perl Glue [joes] Fix the linking of the perl modules to libapreq2 and libapr on Solaris. - Perl Glue [joes] Fix install-time linking issue of the .so modules. Previously they would remain linked against the src library path, not the install path. - C API [joes] Add optional interface for apreq_handle_apache2(). - C API [joes] Clean up buggy apreq_hook_find_param(). - Perl Glue Build [Philip M. Gollucci] config.status format changed format yet again in autoconf 2.62+. - License [Mladen Turk] Add libapreq.rc and generate libapreq.res - Build [Mladen Turk] Add APREQ_DECLARE_EXPORT/APREQ_DECLARE_STATIC in the same way as APR declares so that dllexport/dllimport get correctly handled. - Build [Randy Kobes] Add appropriate manifest command to embed manifest files on Win32 when using VC8 - C API [Andy Grundman, joes] Add missing bytes_read initializer to apreq_handle_custom(). - C API [suggested by Vinay Y S, tested by Steve Hay and Peter Walsham] For Win32, remove the flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK; in apreq_file_cleanup, to avoid problems with file uploads. - C API [joes] Fix leak associated to calling apreq_brigade_fwrite() on an upload brigade. - Build [Philip M. Gollucci] SunOS (Solaris) Users must use gmake not make for building. - Build [Philip M. Gollucci] SunOS (Solaris) Code around bug in libtool (at least in 1.5.18, 1.5.20, 1.5.22) causing mod_apreq2 to be built instead of mod_apreq2.so - C API [Philip M. Gollucci] Fix comparison signed vs unsigned comparison in apreq_fwritev() on SunOS/gcc where iovec.iov_len is a long. - Build [Philip M. Gollucci] SunOS (Solaris) fix duplicate link error to libexpat.so -- by using the one from httpd exclusively now. - Build [Philip M. Gollucci] code around |#_!!_#| autoconf 2.60 bug. Please give the tarball at http://people.apache.org/~issac/libapreq2-2.11.tar.gz a try and report comments/problems/etc. to the apreq-dev list at apreq-...@httpd.apache.org. Thanks, Issac
Re: [libapreq2] Should there be two temp (spool) files?
--- On Wed, 9/24/08, Ryan Gies [EMAIL PROTECTED] wrote:
When I post a multipart-form request I see two files being
written
in my temp directory:
-rw--- 1 ryan users 8318656 2008-09-24 10:51
apreqK5Oiyc
-rw--- 1 ryan users 8318484 2008-09-24 10:51
apreqQ1qs6C
And:
Apache2::Request-new($r)-upload('file')-tempname()
indicates the spool file is apreqQ1qs6C.
So I wonder what the file apreqK5Oiyc is all
about.
It's spooling the contents of the raw (unparsed) body.
You can tell apreq not to do this by calling $r-discard_request_body
in your handler after invoking Apache2::Request::new.
Re: [libapreq2] Should there be two temp (spool) files?
--- On Wed, 9/24/08, Ryan Gies [EMAIL PROTECTED] wrote: When discarding the request body, I receive the error: End of file found (which happens when APR_BUCKET_IS_EOS). I can see the spool file being written and *presume* the multi-part boundary is missing. In a PerlHeaderParserHandler I am executing: 1) Apache2::Request-new() 2) $r-add_input_filter() 3) $r-discard_request_body() Why are you doing step 2? You shouldn't need to add an input filter for apreq to work. Swapping steps 2 3 will yield same error. If calling $r-discard_request_body() like this is not commonly known to work maybe I should follow-up with the libapreq2 development list? If this is known to work then obviously I need to isolate error. It's known to work for a few people, but it's not the default behavior. If you can't decipher why it's not working for you then asking on apreq-dev@ makes sense.
