Re: HTTP and MPM support

[Sive Lindmark]

Hi!

about André’s post, I agree 100 % .

> I believe that we could all collectively start by making a financial 
> contribution to such a preliminary effort, if that is also what it takes to 
> get it going.
yes!!

Sive

Re: HTTP and MPM support

[Румен Палов]

Hello all,

we feel in the same situation.

We are using mod_perl mostly as users and all of our production business 
activity is based and rely on perl / mod_perl.


We are able to secure finance funds, hardware and people hands( perl , 
DevOps ) to support mod_perl project and secure it's future.


I'm not familiar with the oraganisation and logsitics behind mod_perl 
development,but what André Warnier propose sounds resonable.


This Feb we was at FOSDEM 2019, Belgium, I was very sad because of lag 
of any serios interes, devrooms or presentaions for perl.


It was only one presentaion for perl: 
https://fosdem.org/2019/schedule/event/perl11/ , author Will the Chill 
Braswell.


Great Job Will.

Mod_perl is great implementation and it will be shame for all of us ( 
mod_perl users ) to leave it die because of all modern tendencies :)



Cheers
--
Rumen Palov
CTO
E-CARD LTD.

On 02/08/19 10:59, André Warnier (tomcat) wrote:

I would like to add my voice to (at least) Russel's and Sive's.
Our situation (and I understand most of the non-Perl-PMC's interventors' 
in this thread is similar) is :
- we are interested in the future development of mod_perl, and are 
willing to "support" or "sponsor" such development
- we understand that nobody is actively working on mod_perl currently. 
What we do not know/understand clearly is "why not ?", and how to 
possibly change this situation
- we all have some programming resources available, but none of which 
have the current competences that we feel are necessary to undertake 
such development efficiently in the short term. That is because our 
organisations are mostly *users* of mod_perl, in the course of our main 
activity, which is to develop end-user-oriented application software, of 
which a part is currently based on Apache and mod_perl.
- we know that there are people in the mod_perl PMC which do have such 
competences. We do not know about their practical 
availability/willingness to do so.
- we have no hands-on experience of such kinds of open-source, "free" 
development projects, and we do not really know "what makes them tick"
- we all have some form of possible contribution in mind and among our 
possibilities, but so far, short apparently of providing ourselves some 
qualified programming staff to do the work (as Adam mentions below, and 
William did before him), it does not seem that there is any obvious 
avenue open to do so.


To wrap this up somewhat naively and roughly : if we just wanted to pour 
some money in such a project, to revive the interest of the current 
group of people which do have the competences and experience to work on 
this efficiently, how would we go about it ?

Or is this not possible/practical/sufficient ?
Could someone of the mod_perl PMC (or the Apache Foundation) take the 
lead about something like this, and somehow ask the right questions, and 
put together a proposal that could lead to such a "revival" of the 
Apache/mod_perl project ?
I believe that we could all collectively start by making a financial 
contribution to such a preliminary effort, if that is also what it takes 
to get it going.




On 07.02.2019 03:39, Adam Prime wrote:
I can tell you that at least some of the PMC members are on this list. 
But I can
also tell you that there is essentially no development going on right 
now. The
PMC is essentially idle, and there aren't any plans to do anything 
with regards
to improving support for newer MPM's. That said, the project is open 
source, and
if there are people or companies out there with the skills and desire 
to work on
those features, things can get merged, and people can get added to the 
PMC, or

as project commiters to enable that.

Adam


On 1/28/19 1:30 PM, Russell Lundberg wrote:

As a long-time fan and user of mod_perl, I like so much the way this
conversation is turning.

I also wonder if there is a formal process, perhaps an ASF process, for
coordinating the objectives voiced in this thread with the resources
required to achieve them?

For example, I believe Steve Hay has led mod_perl2 development lately,
versions 2.0.9 and 2.0.10, anyway. Should he be engaged, or if the 
leadership
of the project has been handed off, whoever has taken over?  Do the 
project

steward(s) follow this mailing list?

I don't mean to get in the way of positive and well-intended 
progress. I love

mod_perl and only want the best for its future development.

But there might be other development plans in progress with which 
coordination

would be helpful.

--
Read my Latest Blog Post for Telecom Pros: _Excel Telecom Tricks - 
Sequential

Numbering _
Russell Lundberg
Bangkok, Thailand +66 91 546 4539
https://bangkokbeachtelecom.com/
LinkedIn Profile 


On Mon, Jan 28, 2019 at 8:04 AM John Dunlap mailto:j...@lariat.co>> wrote:

    I will second what Sive is saying. My organization does not have 
in-house
    experience writing

Re: HTTP and MPM support

[tomcat]

I would like to add my voice to (at least) Russel's and Sive's.
Our situation (and I understand most of the non-Perl-PMC's interventors' in this thread is 
similar) is :
- we are interested in the future development of mod_perl, and are willing to "support" or 
"sponsor" such development
- we understand that nobody is actively working on mod_perl currently. What we do not 
know/understand clearly is "why not ?", and how to possibly change this situation
- we all have some programming resources available, but none of which have the current 
competences that we feel are necessary to undertake such development efficiently in the 
short term. That is because our organisations are mostly *users* of mod_perl, in the 
course of our main activity, which is to develop end-user-oriented application software, 
of which a part is currently based on Apache and mod_perl.
- we know that there are people in the mod_perl PMC which do have such competences. We do 
not know about their practical availability/willingness to do so.
- we have no hands-on experience of such kinds of open-source, "free" development 
projects, and we do not really know "what makes them tick"
- we all have some form of possible contribution in mind and among our possibilities, but 
so far, short apparently of providing ourselves some qualified programming staff to do the 
work (as Adam mentions below, and William did before him), it does not seem that there is 
any obvious avenue open to do so.


To wrap this up somewhat naively and roughly : if we just wanted to pour some money in 
such a project, to revive the interest of the current group of people which do have the 
competences and experience to work on this efficiently, how would we go about it ?

Or is this not possible/practical/sufficient ?
Could someone of the mod_perl PMC (or the Apache Foundation) take the lead about something 
like this, and somehow ask the right questions, and put together a proposal that could 
lead to such a "revival" of the Apache/mod_perl project ?
I believe that we could all collectively start by making a financial contribution to such 
a preliminary effort, if that is also what it takes to get it going.




On 07.02.2019 03:39, Adam Prime wrote:

I can tell you that at least some of the PMC members are on this list. But I can
also tell you that there is essentially no development going on right now. The
PMC is essentially idle, and there aren't any plans to do anything with regards
to improving support for newer MPM's. That said, the project is open source, and
if there are people or companies out there with the skills and desire to work on
those features, things can get merged, and people can get added to the PMC, or
as project commiters to enable that.

Adam


On 1/28/19 1:30 PM, Russell Lundberg wrote:

As a long-time fan and user of mod_perl, I like so much the way this
conversation is turning.

I also wonder if there is a formal process, perhaps an ASF process, for
coordinating the objectives voiced in this thread with the resources
required to achieve them?

For example, I believe Steve Hay has led mod_perl2 development lately,
versions 2.0.9 and 2.0.10, anyway. Should he be engaged, or if the leadership
of the project has been handed off, whoever has taken over?  Do the project
steward(s) follow this mailing list?

I don't mean to get in the way of positive and well-intended progress. I love
mod_perl and only want the best for its future development.

But there might be other development plans in progress with which coordination
would be helpful.

--
Read my Latest Blog Post for Telecom Pros: _Excel Telecom Tricks - Sequential
Numbering _
Russell Lundberg
Bangkok, Thailand +66 91 546 4539
https://bangkokbeachtelecom.com/
LinkedIn Profile 


On Mon, Jan 28, 2019 at 8:04 AM John Dunlap mailto:j...@lariat.co>> wrote:

I will second what Sive is saying. My organization does not have in-house
experience writing C code(our internal skill sets are web application and
database development) but we are potentially interested in sponsoring some
development on mod_perl with the goal of adding support for mpm_worker and
or mpm_event because we are interested in taking advantage of mod_http2.
In addition to our sponsorship, we could also assist in testing changes
and provided segfaults and debugging/environmental information from out
development and testing environments. Is anyone who is able to do this
kind of development interested in having a conversation with Sive and
myself with respect to sponsoring some development?

On Mon, Jan 28, 2019 at 1:11 AM Sive Lindmark mailto:s...@capestream.se>> wrote:

Hi William!

Count on us, my firm can sponsor work as I stated before, and also
contribute setting up test cases and perhaps also do some coding if we
have the knowledge to do whats needed.
  

Re: HTTP and MPM support

[Adam Prime]

I can tell you that at least some of the PMC members are on this list. 
But I can also tell you that there is essentially no development going 
on right now. The PMC is essentially idle, and there aren't any plans to 
do anything with regards to improving support for newer MPM's. That 
said, the project is open source, and if there are people or companies 
out there with the skills and desire to work on those features, things 
can get merged, and people can get added to the PMC, or as project 
commiters to enable that.


Adam


On 1/28/19 1:30 PM, Russell Lundberg wrote:
As a long-time fan and user of mod_perl, I like so much the way this 
conversation is turning.


I also wonder if there is a formal process, perhaps an ASF process, 
for coordinating the objectives voiced in this thread with the 
resources required to achieve them?


For example, I believe Steve Hay has led mod_perl2 development lately, 
versions 2.0.9 and 2.0.10, anyway. Should he be engaged, or if the 
leadership of the project has been handed off, whoever has taken 
over?  Do the project steward(s) follow this mailing list?


I don't mean to get in the way of positive and well-intended progress. 
I love mod_perl and only want the best for its future development.


But there might be other development plans in progress with which 
coordination would be helpful.


--
Read my Latest Blog Post for Telecom Pros: _Excel Telecom Tricks - 
Sequential Numbering 
_

Russell Lundberg
Bangkok, Thailand +66 91 546 4539
https://bangkokbeachtelecom.com/
LinkedIn Profile 


On Mon, Jan 28, 2019 at 8:04 AM John Dunlap > wrote:


I will second what Sive is saying. My organization does not have
in-house experience writing C code(our internal skill sets are web
application and database development) but we are potentially
interested in sponsoring some development on mod_perl with the
goal of adding support for mpm_worker and or mpm_event because we
are interested in taking advantage of mod_http2. In addition to
our sponsorship, we could also assist in testing changes and
provided segfaults and debugging/environmental information from
out development and testing environments. Is anyone who is able to
do this kind of development interested in having a conversation
with Sive and myself with respect to sponsoring some development?

On Mon, Jan 28, 2019 at 1:11 AM Sive Lindmark mailto:s...@capestream.se>> wrote:

Hi William!

Count on us, my firm can sponsor work as I stated before, and
also contribute setting up test cases and perhaps also do some
coding if we have the knowledge to do whats needed.
My coders are not used to be part of any open source project,
so we can not take any leading roll though.

How could a sponsor model work?

I have followed crypto world for some time now, and they
sometimes set up price for someone thats achieve a goal.
Something we can do here?

/Sive



-- 
John Dunlap

/CTO | Lariat/
/
/
/*Direct:*/
/j...@lariat.co /
/
*Customer Service:*/
877.268.6667
supp...@lariat.co 

Re: HTTP and MPM support

[John D Groenveld]

In message 
, John Dunlap writes:
>extensive discussions about this problem internally and, In the absence of
>a better MPM and http/2 support, our best option appears to be putting a
>more performant web server in front of Apache, proxying dynamic requests to

Please us know using a lighter weight http/2 reverse proxy impacts
your performance.

John
groenv...@acm.org

Re: HTTP and MPM support

[John Dunlap]

The issue, at least for us, has very little to do with static files as we
are already serving them from a CDN(AWS Cloudfront). We have a very large
ember.js application which, on our more complicated screens, can hit the
server 5+ times fetching data just to render the page(all 5+ requests are
initiated simultaneously). We follow a SOFEA(Service Oriented Front End
Architecture) design pattern so we try to build a web service API in
mod_perl and then call it from ember-data. We can then tell our customers
that anything they can do through our UI can also be done through our API.
This helps us kill 2 birds with 1 stone. However, this also means that we
can't create web service endpoints which have a 1:1 correspondence with our
UI and we often have to hit the server 5-6 times to render the page(once
for each drop down box, once per data grid, etc). In this use case, the
concurrency limitations of mod_perl and http/1.1 have become an issue for
us. We've tried throwing bigger servers and memory caches at the problem
but that isn't always enough at peak hours. It's rare that a week goes by
that someone doesn't report slowness at one point or another. Our best
remaining options are to decrease the number of customers(our application
uses a sharded tenancy model) on each server or attempt to scale
horizontally(which would require some rework to stop storing files on the
web server) and both options increase our hosting costs. We've had
extensive discussions about this problem internally and, In the absence of
a better MPM and http/2 support, our best option appears to be putting a
more performant web server in front of Apache, proxying dynamic requests to
Apache, and re-writing our more commonly used endpoints in a language with
a better concurrency model. However, taking that step would effectively
begin our migration away from perl. I know mod_perl has a lot of features
that aren't available in other languages but none of them are an absolute
necessity in our use case and I will be unable to justify staying on
mod_perl if it means ceding fundamental technical advantages to our
competitors. I was hopeful that sponsoring some development could improve
mod_perl's concurrency model but if mod_perl and http/2 are "fundamentally
incompatible", as Mark said, then perhaps we have outgrown mod_perl.

On Wed, Feb 6, 2019 at 9:30 AM Pavel Merdin 
wrote:

> Hi.
> Sorry I'm late in taking a part in the conversation.
>
> I agree with Mark on many points.
> Just wanted to add that if static content is served via a CDN (which it
> should ideally) then maybe there is not much point rushing to support
> HTTP/2 purely for dynamic content. I'm sure HTTP/1.1 will stay for a while
> anyway.
> If static content is served by the same server then it perfectly makes
> sense to add something like nginx to the frontend to serve static content.
> It can also even cache some slow changing dynamic content if needed (making
> user experience better).
> Even with custom authentication handlers nginx supports internal
> redirects, so it's possible to free up perl a process and still serve
> static files via nginx no matter how slow the clients are to get it.
>
> On Mon, 28 Jan 2019 at 20:38, Mark Blackman  wrote:
>
>>
>>
>> On 27 Jan 2019, at 20:13, William A Rowe Jr  wrote:
>>
>> On Fri, Jan 25, 2019 at 11:35 AM John Dunlap  wrote:
>>
>>> I'm in the process of optimizing our web application for performance and
>>> one thing that I was really excited to try was mod_http2 because it allows
>>> the browser to send multiple requests through the same TCP connection with
>>> compressed headers. However, when I enabled it and restarted apache I was
>>> greeted with this:
>>>
>>> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The
>>> mpm module (prefork.c) is not supported by mod_http2. The mpm determines
>>> how things are processed in your server. HTTP/2 has more demands in this
>>> regard and the currently selected mpm will just not do. This is an advisory
>>> warning. Your server will continue to work, but the HTTP/2 protocol will be
>>> inactive.
>>>
>>
>> To this question, the answer should be blatantly obvious; http2 doesn't
>> simply support multiple requests (connection: keepalive solved that)
>> but supports parallel requests. This clearly isn't compatible with any
>> single-threaded/single-worker per connection strategy.
>>
>> A hybrid mod_prefork could be coded to dispatch all worker requests
>> across to distinct worker processes for a single connection, but I
>> don't anticipate anyone interested in doing such development.
>>
>>
>>> The last time I tried to use either mpm_worker or mpm_event my
>>> application was plagued by seemingly random segfaults. Are there any plans
>>> to support other MPM's? If not, the benefits of HTTP2 appear to be
>>> permanently out of reach for our mod_perl applications and that, honestly,
>>> might force us into seriously reevaluating our technology stack. :(
>>>
>>
>> Your compatibility

Re: HTTP and MPM support

[John Dunlap]

We use Redis to share information between mod_perl processes(including our
HTTP sessions). This has the added advantage of allowing all servers in a
cluster to share the same session/cache.

On Tue, Jan 29, 2019 at 7:38 PM Narbey Derbekyan  wrote:

> We've used Cache::FastMmap at my work to share data between mod_perl
> processes. We did not consider using threads because they're not
> lightweight.
> What the rules you guys are following when it comes to using threads?
>
> On Tue, Jan 29, 2019 at 9:48 AM John Deighan 
> wrote:
>
>> We also use threads without any problem in production. Main use is
>> sharing caches so that multiple mod_perl interpreters don'teach store the
>> same cached information. Following a few simple and documented rules, we've
>> had no issues with using threads.
>>
>> On Mon, Jan 28, 2019 at 6:18 PM Mark Blackman  wrote:
>>
>>>
>>>
>>> > On 28 Jan 2019, at 23:00, Paul B. Henson  wrote:
>>> >
>>> > On 1/28/2019 1:53 PM, Mark Blackman wrote:
>>> >> https://perldoc.perl.org/threads.html#WARNING  Threads are
>>> discouraged in Perl these days
>>> >
>>> > Yes, that is indeed what the documentation says; however, there is a
>>> far cry between "Perl is single-threaded by design and history and has no
>>> reliable support for threading" and "use of threads is discouraged in perl".
>>> >
>>> > Looking back to the original discussion that led to that caveat
>>> https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html
>>> a good summary of why it is there is:
>>> >
>>> > "The patch came about because unmanaged expectations of support are
>>> causing social problems"
>>> >
>>> > And further discussion about it
>>> https://www.perlmonks.org/?node_id=1107534 has a similar insight:
>>> >
>>> > "that this particular formulation is just smoke and mirrors to repel
>>> 'annoying newbies"
>>> >
>>> > Then in this bug discussing the verbiage
>>> https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer
>>> comments:
>>> >
>>> > "The fact is that threads work, they are maintained, and they
>>> currently do not have any bugs preventing their use."
>>> >
>>> > Basically, perl threads are heavyweight, not lightweight, and use of
>>> non-thread safe Perl code whether your own or in third-party modules will
>>> cause potentially nondeterministic problems. The warning is basically there
>>> to scare away people who don't have sufficient expertise to make it work
>>> and will likely come complain and ask for help with something the
>>> developers don't want to have to explain over and over again.
>>> >
>>> > Back when I was running DCE/DFS and maintaining the perl modules on
>>> top of that, I used threaded perl heavily with no issues. As long as the
>>> mechanism of and caveats regarding Perl threads are understood, and there
>>> is a justifiable reason to be using them rather than some other construct,
>>> discouraged is not deprecated nor unavailable/unreliable.
>>>
>>> "Threads are implemented in a way that make them easy to misuse." ==
>>> "single threaded by design” in my book, but your mileage may vary. I
>>> believe threads were retrofitted to Perl and I see very little use of
>>> threads in the wild myself. Relying on threads in Perl with real-world
>>> third-party XS modules that aren’t thread-safe is equivalent to unreliable.
>>> Base Perl might be safe enough, but nobody runs real-world apps with pure
>>> Perl alone IME.
>>>
>>> I am glad you made threads work well in production, but I suspect you’re
>>> in a minority.
>>>
>>> - Mark
>>>
>>>
>>>
>>>

-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*j...@lariat.co *

*Customer Service:*
877.268.6667
supp...@lariat.co

Re: HTTP and MPM support

[Narbey Derbekyan]

 We've used Cache::FastMmap at my work to share data between mod_perl
processes. We did not consider using threads because they're not
lightweight.
What the rules you guys are following when it comes to using threads?

On Tue, Jan 29, 2019 at 9:48 AM John Deighan  wrote:

> We also use threads without any problem in production. Main use is sharing
> caches so that multiple mod_perl interpreters don'teach store the same
> cached information. Following a few simple and documented rules, we've had
> no issues with using threads.
>
> On Mon, Jan 28, 2019 at 6:18 PM Mark Blackman  wrote:
>
>>
>>
>> > On 28 Jan 2019, at 23:00, Paul B. Henson  wrote:
>> >
>> > On 1/28/2019 1:53 PM, Mark Blackman wrote:
>> >> https://perldoc.perl.org/threads.html#WARNING  Threads are
>> discouraged in Perl these days
>> >
>> > Yes, that is indeed what the documentation says; however, there is a
>> far cry between "Perl is single-threaded by design and history and has no
>> reliable support for threading" and "use of threads is discouraged in perl".
>> >
>> > Looking back to the original discussion that led to that caveat
>> https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html
>> a good summary of why it is there is:
>> >
>> > "The patch came about because unmanaged expectations of support are
>> causing social problems"
>> >
>> > And further discussion about it
>> https://www.perlmonks.org/?node_id=1107534 has a similar insight:
>> >
>> > "that this particular formulation is just smoke and mirrors to repel
>> 'annoying newbies"
>> >
>> > Then in this bug discussing the verbiage
>> https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer
>> comments:
>> >
>> > "The fact is that threads work, they are maintained, and they currently
>> do not have any bugs preventing their use."
>> >
>> > Basically, perl threads are heavyweight, not lightweight, and use of
>> non-thread safe Perl code whether your own or in third-party modules will
>> cause potentially nondeterministic problems. The warning is basically there
>> to scare away people who don't have sufficient expertise to make it work
>> and will likely come complain and ask for help with something the
>> developers don't want to have to explain over and over again.
>> >
>> > Back when I was running DCE/DFS and maintaining the perl modules on top
>> of that, I used threaded perl heavily with no issues. As long as the
>> mechanism of and caveats regarding Perl threads are understood, and there
>> is a justifiable reason to be using them rather than some other construct,
>> discouraged is not deprecated nor unavailable/unreliable.
>>
>> "Threads are implemented in a way that make them easy to misuse." ==
>> "single threaded by design” in my book, but your mileage may vary. I
>> believe threads were retrofitted to Perl and I see very little use of
>> threads in the wild myself. Relying on threads in Perl with real-world
>> third-party XS modules that aren’t thread-safe is equivalent to unreliable.
>> Base Perl might be safe enough, but nobody runs real-world apps with pure
>> Perl alone IME.
>>
>> I am glad you made threads work well in production, but I suspect you’re
>> in a minority.
>>
>> - Mark
>>
>>
>>
>>

Re: HTTP and MPM support

[John Deighan]

We also use threads without any problem in production. Main use is sharing
caches so that multiple mod_perl interpreters don'teach store the same
cached information. Following a few simple and documented rules, we've had
no issues with using threads.

On Mon, Jan 28, 2019 at 6:18 PM Mark Blackman  wrote:

>
>
> > On 28 Jan 2019, at 23:00, Paul B. Henson  wrote:
> >
> > On 1/28/2019 1:53 PM, Mark Blackman wrote:
> >> https://perldoc.perl.org/threads.html#WARNING  Threads are discouraged
> in Perl these days
> >
> > Yes, that is indeed what the documentation says; however, there is a far
> cry between "Perl is single-threaded by design and history and has no
> reliable support for threading" and "use of threads is discouraged in perl".
> >
> > Looking back to the original discussion that led to that caveat
> https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html
> a good summary of why it is there is:
> >
> > "The patch came about because unmanaged expectations of support are
> causing social problems"
> >
> > And further discussion about it
> https://www.perlmonks.org/?node_id=1107534 has a similar insight:
> >
> > "that this particular formulation is just smoke and mirrors to repel
> 'annoying newbies"
> >
> > Then in this bug discussing the verbiage
> https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer
> comments:
> >
> > "The fact is that threads work, they are maintained, and they currently
> do not have any bugs preventing their use."
> >
> > Basically, perl threads are heavyweight, not lightweight, and use of
> non-thread safe Perl code whether your own or in third-party modules will
> cause potentially nondeterministic problems. The warning is basically there
> to scare away people who don't have sufficient expertise to make it work
> and will likely come complain and ask for help with something the
> developers don't want to have to explain over and over again.
> >
> > Back when I was running DCE/DFS and maintaining the perl modules on top
> of that, I used threaded perl heavily with no issues. As long as the
> mechanism of and caveats regarding Perl threads are understood, and there
> is a justifiable reason to be using them rather than some other construct,
> discouraged is not deprecated nor unavailable/unreliable.
>
> "Threads are implemented in a way that make them easy to misuse." ==
> "single threaded by design” in my book, but your mileage may vary. I
> believe threads were retrofitted to Perl and I see very little use of
> threads in the wild myself. Relying on threads in Perl with real-world
> third-party XS modules that aren’t thread-safe is equivalent to unreliable.
> Base Perl might be safe enough, but nobody runs real-world apps with pure
> Perl alone IME.
>
> I am glad you made threads work well in production, but I suspect you’re
> in a minority.
>
> - Mark
>
>
>
>

Re: HTTP and MPM support

[Mark Blackman]

> On 28 Jan 2019, at 23:00, Paul B. Henson  wrote:
> 
> On 1/28/2019 1:53 PM, Mark Blackman wrote:
>> https://perldoc.perl.org/threads.html#WARNING  Threads are discouraged in 
>> Perl these days
> 
> Yes, that is indeed what the documentation says; however, there is a far cry 
> between "Perl is single-threaded by design and history and has no reliable 
> support for threading" and "use of threads is discouraged in perl".
> 
> Looking back to the original discussion that led to that caveat 
> https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html a 
> good summary of why it is there is:
> 
> "The patch came about because unmanaged expectations of support are causing 
> social problems"
> 
> And further discussion about it https://www.perlmonks.org/?node_id=1107534 
> has a similar insight:
> 
> "that this particular formulation is just smoke and mirrors to repel 
> 'annoying newbies"
> 
> Then in this bug discussing the verbiage 
> https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer comments:
> 
> "The fact is that threads work, they are maintained, and they currently do 
> not have any bugs preventing their use."
> 
> Basically, perl threads are heavyweight, not lightweight, and use of 
> non-thread safe Perl code whether your own or in third-party modules will 
> cause potentially nondeterministic problems. The warning is basically there 
> to scare away people who don't have sufficient expertise to make it work and 
> will likely come complain and ask for help with something the developers 
> don't want to have to explain over and over again.
> 
> Back when I was running DCE/DFS and maintaining the perl modules on top of 
> that, I used threaded perl heavily with no issues. As long as the mechanism 
> of and caveats regarding Perl threads are understood, and there is a 
> justifiable reason to be using them rather than some other construct, 
> discouraged is not deprecated nor unavailable/unreliable.

"Threads are implemented in a way that make them easy to misuse." == "single 
threaded by design” in my book, but your mileage may vary. I believe threads 
were retrofitted to Perl and I see very little use of threads in the wild 
myself. Relying on threads in Perl with real-world third-party XS modules that 
aren’t thread-safe is equivalent to unreliable. Base Perl might be safe enough, 
but nobody runs real-world apps with pure Perl alone IME.

I am glad you made threads work well in production, but I suspect you’re in a 
minority.

- Mark

Re: HTTP and MPM support

[Paul B. Henson]

On 1/28/2019 1:53 PM, Mark Blackman wrote:


https://perldoc.perl.org/threads.html#WARNING  Threads are discouraged 
in Perl these days


Yes, that is indeed what the documentation says; however, there is a far 
cry between "Perl is single-threaded by design and history and has no 
reliable support for threading" and "use of threads is discouraged in perl".


Looking back to the original discussion that led to that caveat 
https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html 
a good summary of why it is there is:


"The patch came about because unmanaged expectations of support are 
causing social problems"


And further discussion about it 
https://www.perlmonks.org/?node_id=1107534 has a similar insight:


"that this particular formulation is just smoke and mirrors to repel 
'annoying newbies"


Then in this bug discussing the verbiage 
https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer comments:


"The fact is that threads work, they are maintained, and they currently 
do not have any bugs preventing their use."


Basically, perl threads are heavyweight, not lightweight, and use of 
non-thread safe Perl code whether your own or in third-party modules 
will cause potentially nondeterministic problems. The warning is 
basically there to scare away people who don't have sufficient expertise 
to make it work and will likely come complain and ask for help with 
something the developers don't want to have to explain over and over again.


Back when I was running DCE/DFS and maintaining the perl modules on top 
of that, I used threaded perl heavily with no issues. As long as the 
mechanism of and caveats regarding Perl threads are understood, and 
there is a justifiable reason to be using them rather than some other 
construct, discouraged is not deprecated nor unavailable/unreliable.

Re: HTTP and MPM support

[Mark Blackman]

> On 28 Jan 2019, at 21:34, Paul B. Henson  wrote:
> 
> On 1/28/2019 12:38 PM, Mark Blackman wrote:
> >
>> Given that Perl is single-threaded by design and history and has no reliable 
>> support for threading, I think that mod_perl and direct http/2 
> 
> Perhaps I am confused, but I do not necessarily agree with this statement. 
> See, for example:
> 
> https://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support
> 
> Both perl and mod_perl support threads, typically the problem arises not with 
> native Perl thread support, but rather thread-unsafe user code or modules.
> 

https://perldoc.perl.org/threads.html#WARNING 
  Threads are discouraged in 
Perl these days

- Mark

Re: HTTP and MPM support

[Paul B. Henson]

On 1/28/2019 12:38 PM, Mark Blackman wrote:
>
Given that Perl is single-threaded by design and history and has no 
reliable support for threading, I think that mod_perl and direct http/2 


Perhaps I am confused, but I do not necessarily agree with this 
statement. See, for example:


https://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support

Both perl and mod_perl support threads, typically the problem arises not 
with native Perl thread support, but rather thread-unsafe user code or 
modules.

Re: HTTP and MPM support

[Mark Blackman]

I think Perl is fine, but naive Perl (or anything else) doesn’t scale. Are you 
actually maxing out your CPU (re-examine your code) or are your mod_perl 
instances all hanging around waiting for a database to return (re-examine your 
queries/indices). 

- Mark

> On 28 Jan 2019, at 21:27, John Dunlap  wrote:
> 
> Yes! Lots of traffic is arguably the best kind of problem to have! :) We can 
> definitely throw servers at the problem and scale horizontally but those 
> costs add up and I'm afraid that, unless we can somehow get more concurrency 
> out of mod_perl, a day will come when we're forced to acknowledge that we can 
> do more work for less money in a different language. I was really hoping that 
> a different MPM and http/2 would help in that regard but it's not sounding 
> hopeful. :(
> 
> On Mon, Jan 28, 2019 at 9:18 PM Mark Blackman  > wrote:
> 
> 
>> On 28 Jan 2019, at 21:14, John Dunlap > > wrote:
>> 
>> Our servers already have 32 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 
>> cores(if you count hyper threading) so optimization is the road I've been 
>> going down. I've also Apache::VMonitor to get, at least, *some* insight into 
>> the internals of mod_perl but I'm uncertain how to use the information it 
>> gives me to optimize the server.
> 
> Plenty of traffic sounds like a nice problem to have, more machines then? :)  
> I have a hosting business (UK) on the side (http://www.exonetric.com 
> ) and would love to sell you some hosting!  On the 
> other hand, if your Perl just needs some TLC, then plenty of contractors can 
> help find the hotspots and optimise for you.
> 
> - Mark
> 
> 
> -- 
> John Dunlap
> CTO | Lariat 
> 
> Direct:
> j...@lariat.co 
> 
> Customer Service:
> 877.268.6667 <>
> supp...@lariat.co 
> <100x60.png>
> <100x60.png>

Re: HTTP and MPM support

[John Dunlap]

Yes! Lots of traffic is arguably the best kind of problem to have! :) We
can definitely throw servers at the problem and scale horizontally but
those costs add up and I'm afraid that, unless we can somehow get more
concurrency out of mod_perl, a day will come when we're forced to
acknowledge that we can do more work for less money in a different
language. I was really hoping that a different MPM and http/2 would help in
that regard but it's not sounding hopeful. :(

On Mon, Jan 28, 2019 at 9:18 PM Mark Blackman  wrote:

>
>
> On 28 Jan 2019, at 21:14, John Dunlap  wrote:
>
> Our servers already have 32 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
> cores(if you count hyper threading) so optimization is the road I've been
> going down. I've also Apache::VMonitor to get, at least, *some* insight
> into the internals of mod_perl but I'm uncertain how to use the information
> it gives me to optimize the server.
>
>
> Plenty of traffic sounds like a nice problem to have, more machines then?
> :)  I have a hosting business (UK) on the side (http://www.exonetric.com)
> and would love to sell you some hosting!  On the other hand, if your Perl
> just needs some TLC, then plenty of contractors can help find the hotspots
> and optimise for you.
>
> - Mark
>


-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*j...@lariat.co *

*Customer Service:*
877.268.6667
supp...@lariat.co

Re: HTTP and MPM support

[Mark Blackman]

time for more cores or optimising your Perl?

> On 28 Jan 2019, at 21:10, John Dunlap  wrote:
> 
> I'm pretty sure that they are but, unfortunately, we make a lot of dynamic 
> requests.
> 
> On Mon, Jan 28, 2019 at 9:08 PM Mark Blackman  > wrote:
> Ok, hopefully Amazon Cloudfront is already using HTTP/2 on your behalf and 
> proxying just the dynamic content requests via HTTP/1.1 to your mod_perl 
> instances.
> 
> 
>> On 28 Jan 2019, at 21:02, John Dunlap > > wrote:
>> 
>> We can give that a try but I'm not sure how much it would help us because 
>> we're already pulling all of our static content directly from Amazon 
>> Cloudfront. The vast majority of our requests are for dynamic content.
>> 
>> On Mon, Jan 28, 2019 at 8:38 PM Mark Blackman > > wrote:
>> 
>> Given that Perl is single-threaded by design and history and has no reliable 
>> support for threading, I think that mod_perl and direct http/2 support in 
>> the same instance are probably fundamentally incompatible. I.e. if you have 
>> 10 perl threads running (each in a single process), then it doesn’t matter 
>> if you can multiplex 20 http/2 connections, they will all just block.  If 
>> you’re very attached to mod_perl, you should already be using a 2-tier 
>> strategy anyway, with N fat mod_perl Apache instances handling only HTTP/1.1 
>> requests and a second front-end proxy layer of whatever front-end proxy 
>> makes sense handling HTTP/2 requests for both static and dynamic content 
>> requests. This was standard advice 20 years ago as far as I recall and is 
>> even more prudent now.
>> 
>> - Mark
>> 
>> 
>> -- 
>> John Dunlap
>> CTO | Lariat 
>> 
>> Direct:
>> j...@lariat.co 
>> 
>> Customer Service:
>> 877.268.6667 <>
>> supp...@lariat.co 
>> <100x60.png>
>> <100x60.png>
> 
> 
> 
> -- 
> John Dunlap
> CTO | Lariat 
> 
> Direct:
> j...@lariat.co 
> 
> Customer Service:
> 877.268.6667 <>
> supp...@lariat.co 
> <100x60.png>
> <100x60.png>

Re: HTTP and MPM support

[Mark Blackman]

> On 28 Jan 2019, at 21:14, John Dunlap  wrote:
> 
> Our servers already have 32 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 
> cores(if you count hyper threading) so optimization is the road I've been 
> going down. I've also Apache::VMonitor to get, at least, *some* insight into 
> the internals of mod_perl but I'm uncertain how to use the information it 
> gives me to optimize the server.

Plenty of traffic sounds like a nice problem to have, more machines then? :)  I 
have a hosting business (UK) on the side (http://www.exonetric.com 
) and would love to sell you some hosting!  On the 
other hand, if your Perl just needs some TLC, then plenty of contractors can 
help find the hotspots and optimise for you.

- Mark

Re: HTTP and MPM support

[John Dunlap]

Our servers already have 32 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
cores(if you count hyper threading) so optimization is the road I've been
going down. I've also Apache::VMonitor to get, at least, *some* insight
into the internals of mod_perl but I'm uncertain how to use the information
it gives me to optimize the server.

On Mon, Jan 28, 2019 at 9:12 PM Mark Blackman  wrote:

> time for more cores or optimising your Perl?
>
> On 28 Jan 2019, at 21:10, John Dunlap  wrote:
>
> I'm pretty sure that they are but, unfortunately, we make a lot of dynamic
> requests.
>
> On Mon, Jan 28, 2019 at 9:08 PM Mark Blackman  wrote:
>
>> Ok, hopefully Amazon Cloudfront is already using HTTP/2 on your behalf
>> and proxying just the dynamic content requests via HTTP/1.1 to your
>> mod_perl instances.
>>
>>
>> On 28 Jan 2019, at 21:02, John Dunlap  wrote:
>>
>> We can give that a try but I'm not sure how much it would help us because
>> we're already pulling all of our static content directly from Amazon
>> Cloudfront. The vast majority of our requests are for dynamic content.
>>
>> On Mon, Jan 28, 2019 at 8:38 PM Mark Blackman  wrote:
>>
>>>
>>> Given that Perl is single-threaded by design and history and has no
>>> reliable support for threading, I think that mod_perl and direct http/2
>>> support in the same instance are probably fundamentally incompatible. I.e.
>>> if you have 10 perl threads running (each in a single process), then it
>>> doesn’t matter if you can multiplex 20 http/2 connections, they will all
>>> just block.  If you’re very attached to mod_perl, you should already be
>>> using a 2-tier strategy anyway, with N fat mod_perl Apache instances
>>> handling only HTTP/1.1 requests and a second front-end proxy layer of
>>> whatever front-end proxy makes sense handling HTTP/2 requests for both
>>> static and dynamic content requests. This was standard advice 20 years ago
>>> as far as I recall and is even more prudent now.
>>>
>>> - Mark
>>>
>>
>>
>> --
>> John Dunlap
>> *CTO | Lariat *
>>
>> *Direct:*
>> *j...@lariat.co *
>>
>> *Customer Service:*
>> 877.268.6667
>> supp...@lariat.co
>> <100x60.png>
>> <100x60.png>
>>
>>
>>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *j...@lariat.co *
>
> *Customer Service:*
> 877.268.6667
> supp...@lariat.co
> <100x60.png>
> <100x60.png>
>
>
>

-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*j...@lariat.co *

*Customer Service:*
877.268.6667
supp...@lariat.co

Re: HTTP and MPM support

[John Dunlap]

I'm pretty sure that they are but, unfortunately, we make a lot of dynamic
requests.

On Mon, Jan 28, 2019 at 9:08 PM Mark Blackman  wrote:

> Ok, hopefully Amazon Cloudfront is already using HTTP/2 on your behalf and
> proxying just the dynamic content requests via HTTP/1.1 to your mod_perl
> instances.
>
>
> On 28 Jan 2019, at 21:02, John Dunlap  wrote:
>
> We can give that a try but I'm not sure how much it would help us because
> we're already pulling all of our static content directly from Amazon
> Cloudfront. The vast majority of our requests are for dynamic content.
>
> On Mon, Jan 28, 2019 at 8:38 PM Mark Blackman  wrote:
>
>>
>> Given that Perl is single-threaded by design and history and has no
>> reliable support for threading, I think that mod_perl and direct http/2
>> support in the same instance are probably fundamentally incompatible. I.e.
>> if you have 10 perl threads running (each in a single process), then it
>> doesn’t matter if you can multiplex 20 http/2 connections, they will all
>> just block.  If you’re very attached to mod_perl, you should already be
>> using a 2-tier strategy anyway, with N fat mod_perl Apache instances
>> handling only HTTP/1.1 requests and a second front-end proxy layer of
>> whatever front-end proxy makes sense handling HTTP/2 requests for both
>> static and dynamic content requests. This was standard advice 20 years ago
>> as far as I recall and is even more prudent now.
>>
>> - Mark
>>
>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *j...@lariat.co *
>
> *Customer Service:*
> 877.268.6667
> supp...@lariat.co
> <100x60.png>
> <100x60.png>
>
>
>

-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*j...@lariat.co *

*Customer Service:*
877.268.6667
supp...@lariat.co

Re: HTTP and MPM support

[John Dunlap]

We can give that a try but I'm not sure how much it would help us because
we're already pulling all of our static content directly from Amazon
Cloudfront. The vast majority of our requests are for dynamic content.

On Mon, Jan 28, 2019 at 8:38 PM Mark Blackman  wrote:

>
>
> On 27 Jan 2019, at 20:13, William A Rowe Jr  wrote:
>
> On Fri, Jan 25, 2019 at 11:35 AM John Dunlap  wrote:
>
>> I'm in the process of optimizing our web application for performance and
>> one thing that I was really excited to try was mod_http2 because it allows
>> the browser to send multiple requests through the same TCP connection with
>> compressed headers. However, when I enabled it and restarted apache I was
>> greeted with this:
>>
>> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The
>> mpm module (prefork.c) is not supported by mod_http2. The mpm determines
>> how things are processed in your server. HTTP/2 has more demands in this
>> regard and the currently selected mpm will just not do. This is an advisory
>> warning. Your server will continue to work, but the HTTP/2 protocol will be
>> inactive.
>>
>
> To this question, the answer should be blatantly obvious; http2 doesn't
> simply support multiple requests (connection: keepalive solved that)
> but supports parallel requests. This clearly isn't compatible with any
> single-threaded/single-worker per connection strategy.
>
> A hybrid mod_prefork could be coded to dispatch all worker requests
> across to distinct worker processes for a single connection, but I
> don't anticipate anyone interested in doing such development.
>
>
>> The last time I tried to use either mpm_worker or mpm_event my
>> application was plagued by seemingly random segfaults. Are there any plans
>> to support other MPM's? If not, the benefits of HTTP2 appear to be
>> permanently out of reach for our mod_perl applications and that, honestly,
>> might force us into seriously reevaluating our technology stack. :(
>>
>
> Your compatibility with the worker MPM is likely much stronger than
> with the event MPM; however... all request workers can behave in a
> "free threaded" manner under mod_http2, eliminating the relative
> simplicity of the worker MPM. Working out each and any of these
> specific segfaults occurs is the only way to improve the situation.
>
> For the general mod_perl activity to increase, the Apache Perl Project
> needs active volunteers and contributions. Consider this entire thread
> an open invitation to participate.
>
>
> Given that Perl is single-threaded by design and history and has no
> reliable support for threading, I think that mod_perl and direct http/2
> support in the same instance are probably fundamentally incompatible. I.e.
> if you have 10 perl threads running (each in a single process), then it
> doesn’t matter if you can multiplex 20 http/2 connections, they will all
> just block.  If you’re very attached to mod_perl, you should already be
> using a 2-tier strategy anyway, with N fat mod_perl Apache instances
> handling only HTTP/1.1 requests and a second front-end proxy layer of
> whatever front-end proxy makes sense handling HTTP/2 requests for both
> static and dynamic content requests. This was standard advice 20 years ago
> as far as I recall and is even more prudent now.
>
> - Mark
>


-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*j...@lariat.co *

*Customer Service:*
877.268.6667
supp...@lariat.co

Re: HTTP and MPM support

[Mark Blackman]

Ok, hopefully Amazon Cloudfront is already using HTTP/2 on your behalf and 
proxying just the dynamic content requests via HTTP/1.1 to your mod_perl 
instances.


> On 28 Jan 2019, at 21:02, John Dunlap  wrote:
> 
> We can give that a try but I'm not sure how much it would help us because 
> we're already pulling all of our static content directly from Amazon 
> Cloudfront. The vast majority of our requests are for dynamic content.
> 
> On Mon, Jan 28, 2019 at 8:38 PM Mark Blackman  > wrote:
> 
> Given that Perl is single-threaded by design and history and has no reliable 
> support for threading, I think that mod_perl and direct http/2 support in the 
> same instance are probably fundamentally incompatible. I.e. if you have 10 
> perl threads running (each in a single process), then it doesn’t matter if 
> you can multiplex 20 http/2 connections, they will all just block.  If you’re 
> very attached to mod_perl, you should already be using a 2-tier strategy 
> anyway, with N fat mod_perl Apache instances handling only HTTP/1.1 requests 
> and a second front-end proxy layer of whatever front-end proxy makes sense 
> handling HTTP/2 requests for both static and dynamic content requests. This 
> was standard advice 20 years ago as far as I recall and is even more prudent 
> now.
> 
> - Mark
> 
> 
> -- 
> John Dunlap
> CTO | Lariat 
> 
> Direct:
> j...@lariat.co 
> 
> Customer Service:
> 877.268.6667 <>
> supp...@lariat.co 
> <100x60.png>
> <100x60.png>

Re: HTTP and MPM support

[Mark Blackman]

> On 27 Jan 2019, at 20:13, William A Rowe Jr  wrote:
> 
> On Fri, Jan 25, 2019 at 11:35 AM John Dunlap  > wrote:
> I'm in the process of optimizing our web application for performance and one 
> thing that I was really excited to try was mod_http2 because it allows the 
> browser to send multiple requests through the same TCP connection with 
> compressed headers. However, when I enabled it and restarted apache I was 
> greeted with this:
> 
> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The mpm 
> module (prefork.c) is not supported by mod_http2. The mpm determines how 
> things are processed in your server. HTTP/2 has more demands in this regard 
> and the currently selected mpm will just not do. This is an advisory warning. 
> Your server will continue to work, but the HTTP/2 protocol will be inactive.
> 
> To this question, the answer should be blatantly obvious; http2 doesn't 
> simply support multiple requests (connection: keepalive solved that) 
> but supports parallel requests. This clearly isn't compatible with any
> single-threaded/single-worker per connection strategy.
> 
> A hybrid mod_prefork could be coded to dispatch all worker requests
> across to distinct worker processes for a single connection, but I 
> don't anticipate anyone interested in doing such development.
>  
> The last time I tried to use either mpm_worker or mpm_event my application 
> was plagued by seemingly random segfaults. Are there any plans to support 
> other MPM's? If not, the benefits of HTTP2 appear to be permanently out of 
> reach for our mod_perl applications and that, honestly, might force us into 
> seriously reevaluating our technology stack. :(
> 
> Your compatibility with the worker MPM is likely much stronger than
> with the event MPM; however... all request workers can behave in a
> "free threaded" manner under mod_http2, eliminating the relative
> simplicity of the worker MPM. Working out each and any of these
> specific segfaults occurs is the only way to improve the situation.
> 
> For the general mod_perl activity to increase, the Apache Perl Project
> needs active volunteers and contributions. Consider this entire thread
> an open invitation to participate.

Given that Perl is single-threaded by design and history and has no reliable 
support for threading, I think that mod_perl and direct http/2 support in the 
same instance are probably fundamentally incompatible. I.e. if you have 10 perl 
threads running (each in a single process), then it doesn’t matter if you can 
multiplex 20 http/2 connections, they will all just block.  If you’re very 
attached to mod_perl, you should already be using a 2-tier strategy anyway, 
with N fat mod_perl Apache instances handling only HTTP/1.1 requests and a 
second front-end proxy layer of whatever front-end proxy makes sense handling 
HTTP/2 requests for both static and dynamic content requests. This was standard 
advice 20 years ago as far as I recall and is even more prudent now.

- Mark

Re: HTTP and MPM support

[Russell Lundberg]

As a long-time fan and user of mod_perl, I like so much the way this
conversation is turning.

I also wonder if there is a formal process, perhaps an ASF process, for
coordinating the objectives voiced in this thread with the resources
required to achieve them?

For example, I believe Steve Hay has led mod_perl2 development lately,
versions 2.0.9 and 2.0.10, anyway.  Should he be engaged, or if the
leadership of the project has been handed off, whoever has taken over?  Do
the project steward(s) follow this mailing list?

I don't mean to get in the way of positive and well-intended progress. I
love mod_perl and only want the best for its future development.

But there might be other development plans in progress with which
coordination would be helpful.

--
Read my Latest Blog Post for Telecom Pros:  *Excel Telecom Tricks -
Sequential Numbering
*
Russell Lundberg
Bangkok, Thailand +66 91 546 4539
https://bangkokbeachtelecom.com/
LinkedIn Profile 


On Mon, Jan 28, 2019 at 8:04 AM John Dunlap  wrote:

> I will second what Sive is saying. My organization does not have in-house
> experience writing C code(our internal skill sets are web application and
> database development) but we are potentially interested in sponsoring some
> development on mod_perl with the goal of adding support for mpm_worker and
> or mpm_event because we are interested in taking advantage of mod_http2. In
> addition to our sponsorship, we could also assist in testing changes and
> provided segfaults and debugging/environmental information from out
> development and testing environments. Is anyone who is able to do this kind
> of development interested in having a conversation with Sive and myself
> with respect to sponsoring some development?
>
> On Mon, Jan 28, 2019 at 1:11 AM Sive Lindmark  wrote:
>
>> Hi William!
>>
>> Count on us, my firm can sponsor work as I stated before, and also
>> contribute setting up test cases and perhaps also do some coding if we have
>> the knowledge to do whats needed.
>> My coders are not used to be part of any open source project, so we can
>> not take any leading roll though.
>>
>> How could a sponsor model work?
>>
>> I have followed crypto world for some time now, and they sometimes set up
>> price for someone thats achieve a goal. Something we can do here?
>>
>> /Sive
>>
>>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *j...@lariat.co *
>
> *Customer Service:*
> 877.268.6667
> supp...@lariat.co
>

Re: HTTP and MPM support

[John Dunlap]

I will second what Sive is saying. My organization does not have in-house
experience writing C code(our internal skill sets are web application and
database development) but we are potentially interested in sponsoring some
development on mod_perl with the goal of adding support for mpm_worker and
or mpm_event because we are interested in taking advantage of mod_http2. In
addition to our sponsorship, we could also assist in testing changes and
provided segfaults and debugging/environmental information from out
development and testing environments. Is anyone who is able to do this kind
of development interested in having a conversation with Sive and myself
with respect to sponsoring some development?

On Mon, Jan 28, 2019 at 1:11 AM Sive Lindmark  wrote:

> Hi William!
>
> Count on us, my firm can sponsor work as I stated before, and also
> contribute setting up test cases and perhaps also do some coding if we have
> the knowledge to do whats needed.
> My coders are not used to be part of any open source project, so we can
> not take any leading roll though.
>
> How could a sponsor model work?
>
> I have followed crypto world for some time now, and they sometimes set up
> price for someone thats achieve a goal. Something we can do here?
>
> /Sive
>
>

-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*j...@lariat.co *

*Customer Service:*
877.268.6667
supp...@lariat.co

Re: HTTP and MPM support

[Sive Lindmark]

Hi William!

Count on us, my firm can sponsor work as I stated before, and also contribute 
setting up test cases and perhaps also do some coding if we have the knowledge 
to do whats needed.
My coders are not used to be part of any open source project, so we can not 
take any leading roll though.

How could a sponsor model work?  

I have followed crypto world for some time now, and they sometimes set up price 
for someone thats achieve a goal. Something we can do here?
 
/Sive  

Re: HTTP and MPM support

[tomcat]

Hello William.
Thank you for commenting on this.

On 27.01.2019 21:13, William A Rowe Jr wrote:

On Fri, Jan 25, 2019 at 11:35 AM John Dunlap mailto:j...@lariat.co>> wrote:

I'm in the process of optimizing our web application for performance and 
one thing
that I was really excited to try was mod_http2 because it allows the 
browser to send
multiple requests through the same TCP connection with compressed headers. 
However,
when I enabled it and restarted apache I was greeted with this:

[Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The mpm 
module
(prefork.c) is not supported by mod_http2. The mpm determines how things 
are processed
in your server. HTTP/2 has more demands in this regard and the currently 
selected mpm
will just not do. This is an advisory warning. Your server will continue to 
work, but
the HTTP/2 protocol will be inactive.


To this question, the answer should be blatantly obvious; http2 doesn't
simply support multiple requests (connection: keepalive solved that)
but supports parallel requests. This clearly isn't compatible with any
single-threaded/single-worker per connection strategy.

A hybrid mod_prefork could be coded to dispatch all worker requests
across to distinct worker processes for a single connection, but I
don't anticipate anyone interested in doing such development.

The last time I tried to use either mpm_worker or mpm_event my application 
was plagued
by seemingly random segfaults. Are there any plans to support other MPM's? 
If not, the
benefits of HTTP2 appear to be permanently out of reach for our mod_perl 
applications
and that, honestly, might force us into seriously reevaluating our 
technology stack. :(


Your compatibility with the worker MPM is likely much stronger than
with the event MPM; however... all request workers can behave in a
"free threaded" manner under mod_http2, eliminating the relative
simplicity of the worker MPM. Working out each and any of these
specific segfaults occurs is the only way to improve the situation.

For the general mod_perl activity to increase, the Apache Perl Project
needs active volunteers and contributions. Consider this entire thread
an open invitation to participate.



Invitation accepted, but
how can people who are not C programmers really contribute ?

I believe that there is a much wider user base for mod_perl, than may be evident from 
activity on the user list or on Bugzilla.


To quote Philippe Chiasson in 
http://www.apache.org/foundation/records/minutes/2018/board_minutes_2018_11_21.txt :


"It's not that the project is dead, in my opinion, more like dormant. It works,
it's being used by a large number of users, and is extremely stable."

Exactly. And therefore, there is very little noise about it.
mod_perl may be suffering from its general "it just works" aspect, and therefor be less 
attractive to developers (of mod_perl itself).


So let's imagine that there are currently worldwide a few hundreds/thousands users of 
mod_perl (by which I mean application developers who use mod_perl daily to 
develop/maintain important (to them) web-based applications), but of which only a tiny 
percentage is fluent in C (in which mod_perl is written). And among these people, there 
are quite a few which have a vested interest in the future of mod_perl (that's certainly 
my case, and my company's case), but who themselves don't feel qualified to be able to 
contribute to the code (also my case).
What could these mod_perl users do, to trigger renewed interest if the further development 
of mod_perl, by people qualified to do so ?


Say for example that, collectively, we would be very interested in someone picking up and 
resolving these problems that exist in running mod_perl with Apache MPM's other than prefork.
What would be the best way for us collectively to to try get the ball moving in that 
direction, and more than anything, avoid having mod_perl maybe being moved sooner or later 
to the Apache Attic, for lack of /perceived/ interest ?


Genuinely curious and interested

André Warnier (soliplaya at apache.org)
(don't let the Tomcat committer label fool you; I'm a perl and mod_perl guy)

Re: HTTP and MPM support

[William A Rowe Jr]

On Fri, Jan 25, 2019 at 11:35 AM John Dunlap  wrote:

> I'm in the process of optimizing our web application for performance and
> one thing that I was really excited to try was mod_http2 because it allows
> the browser to send multiple requests through the same TCP connection with
> compressed headers. However, when I enabled it and restarted apache I was
> greeted with this:
>
> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The
> mpm module (prefork.c) is not supported by mod_http2. The mpm determines
> how things are processed in your server. HTTP/2 has more demands in this
> regard and the currently selected mpm will just not do. This is an advisory
> warning. Your server will continue to work, but the HTTP/2 protocol will be
> inactive.
>

To this question, the answer should be blatantly obvious; http2 doesn't
simply support multiple requests (connection: keepalive solved that)
but supports parallel requests. This clearly isn't compatible with any
single-threaded/single-worker per connection strategy.

A hybrid mod_prefork could be coded to dispatch all worker requests
across to distinct worker processes for a single connection, but I
don't anticipate anyone interested in doing such development.


> The last time I tried to use either mpm_worker or mpm_event my application
> was plagued by seemingly random segfaults. Are there any plans to support
> other MPM's? If not, the benefits of HTTP2 appear to be permanently out of
> reach for our mod_perl applications and that, honestly, might force us into
> seriously reevaluating our technology stack. :(
>

Your compatibility with the worker MPM is likely much stronger than
with the event MPM; however... all request workers can behave in a
"free threaded" manner under mod_http2, eliminating the relative
simplicity of the worker MPM. Working out each and any of these
specific segfaults occurs is the only way to improve the situation.

For the general mod_perl activity to increase, the Apache Perl Project
needs active volunteers and contributions. Consider this entire thread
an open invitation to participate.

Re: HTTP and MPM support

[Dr James Smith]

I would prefer to see a mod_perl 2.6 or 3 against perl 5 rather than 
perl 6 - I think it wouldn't go to far against perl 6 as there isn't the 
uptake - we would be unlikely to migrate to a perl 6 backend - there is 
too much pressure already to move to an alternative language (python at 
the moment - until we point out most of it's pitfalls when it comes to 
web work!) that I don't think we would justify moving to a Perl 6 
environment where there is little or no code to rely on!


On 26/01/2019 22:02, Sive Lindmark wrote:

Hi!

Perhaps in the same boat? Our company can sponsor between $1000 - $1 to a 
project developing modPerl 3 (Perl 6 + stabil mpm-worker/event)

If some more in the boat can tribute also it would be awasame ...

/Sive




--
The Wellcome Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 

Re: HTTP and MPM support

[Sive Lindmark]

Hi! 

Perhaps in the same boat? Our company can sponsor between $1000 - $1 to a 
project developing modPerl 3 (Perl 6 + stabil mpm-worker/event)

If some more in the boat can tribute also it would be awasame ...

/Sive

Re: [OT](a bit) Re: HTTP and MPM support

[Christophe JAILLET]

Le 26/01/2019 à 00:00, André Warnier (tomcat) a écrit :

On 25.01.2019 21:15, Paul B. Henson wrote:

On 1/25/2019 11:00 AM, Michael A. Capone wrote:

I have to add my voice to the growing chorus here.


Me too. Frequently when the topic of mod_perl going stale comes up 
somebody jumps in with
"That's old stuff, you should be using PSGI/Plack". Those people 
simply don't understand
the overall utility of mod_perl beyond simply running a webapp 
. I have
authentication and authorization handlers written in mod_perl, and 
the ability to directly

access the Apache API allows things that PSGI simply cannot do.


I think that is a reasonable bet to say that by the mere fact of being 
subscribed to this list, we all express our interest in, and love of 
perl and mod_perl in particular.
(I cannot complain, as I was the first one to hijack John's question 
in that sense).


But really, the underlying concern here seems to find out a bit about 
the future support and evolution of mod_perl, in parallel to the 
evolution of Apache httpd and the HTTP protocol(s).


So if a mod_perl committer would happen to read this, it would be nice 
to get some information or pointers.

There is a list here, so I suppose there are some such people :
http://people.apache.org/phonebook.html?pmc=perl


Hi,

You can have a look at the following ASF monthly report to have some 
more ideas on the activity of the project:


http://www.apache.org/foundation/records/minutes/2018/board_minutes_2018_11_21.txt

There has already been a more or less simitar discussion this summer 
(http://mail-archives.apache.org/mod_mbox/perl-modperl/201806.mbox/thread 
(continued in July and August))


In short: some are still interested in the development and/or 
maintenance of mod_perl but there are some limitation:

   - lack of http2 support because http2 does not work with prefork
   - lack of mpm other than prefork support (according to the thread)

CJ


As this is an Apache Project, I would guess that starting from the 
main site apache.org, there must also be a way to find out about any 
activity in that project (it's named sometimes "perl", sometimes 
"mod_perl" there, but if you follow the project link, you end up on 
the same on-line documentation page that we all know and love, but 
which doesn't seem to lead to any further data on what's happening 
currently).
There is also a "perl-dev" mailing list, but browsing it backward from 
today doesn't seem to show much activity since January 2017 (Hi, 
Rainer and Steve :-)


The good side about this of course, is that mod_perl would appear to 
be a very stable and reliable module, since there is also not much 
evidence of bugs, patches etc.

The less good side is that it appears indeed *very* stable.

Unless we're all on the wrong track, and there is a hidden project 
somewhere for a mod_perl 3 based on perl 6..

[OT](a bit) Re: HTTP and MPM support

[tomcat]

On 25.01.2019 21:15, Paul B. Henson wrote:

On 1/25/2019 11:00 AM, Michael A. Capone wrote:

I have to add my voice to the growing chorus here.


Me too. Frequently when the topic of mod_perl going stale comes up somebody 
jumps in with
"That's old stuff, you should be using PSGI/Plack". Those people simply don't 
understand
the overall utility of mod_perl beyond simply running a webapp . I have
authentication and authorization handlers written in mod_perl, and the ability 
to directly
access the Apache API allows things that PSGI simply cannot do.


I think that is a reasonable bet to say that by the mere fact of being subscribed to this 
list, we all express our interest in, and love of perl and mod_perl in particular.

(I cannot complain, as I was the first one to hijack John's question in that 
sense).

But really, the underlying concern here seems to find out a bit about the future support 
and evolution of mod_perl, in parallel to the evolution of Apache httpd and the HTTP 
protocol(s).


So if a mod_perl committer would happen to read this, it would be nice to get some 
information or pointers.

There is a list here, so I suppose there are some such people :
http://people.apache.org/phonebook.html?pmc=perl

As this is an Apache Project, I would guess that starting from the main site apache.org, 
there must also be a way to find out about any activity in that project (it's named 
sometimes "perl", sometimes "mod_perl" there, but if you follow the project link, you end 
up on the same on-line documentation page that we all know and love, but which doesn't 
seem to lead to any further data on what's happening currently).
There is also a "perl-dev" mailing list, but browsing it backward from today doesn't seem 
to show much activity since January 2017 (Hi, Rainer and Steve :-)


The good side about this of course, is that mod_perl would appear to be a very stable and 
reliable module, since there is also not much evidence of bugs, patches etc.

The less good side is that it appears indeed *very* stable.

Unless we're all on the wrong track, and there is a hidden project somewhere for a 
mod_perl 3 based on perl 6..

Re: HTTP and MPM support

[Dr James Smith]

Agree with this we use AAA handlers - but more importantly output 
filters to allow content to be decorated per site (independent of what 
generates the content perl/java/php proxied content etc...} and add in a 
few useful extra logging features that rely on things like transHandlers 
and log & cleanup handlers you just can't quite get these working well 
with plack/PSGI.


There is a balance between HTTP/1.1 and HTTP/2.0 that you can strike by 
mixing a matching backends dependant on content - I use three apaches on 
my machines one using event handler which receives all requests, and 
servers some static content and proxies back to either a dev apache or 
live apache dependent on what the URL is...


This gives me the best of both worlds

On 25/01/2019 20:15, Paul B. Henson wrote:

On 1/25/2019 11:00 AM, Michael A. Capone wrote:

I have to add my voice to the growing chorus here.


Me too. Frequently when the topic of mod_perl going stale comes up 
somebody jumps in with "That's old stuff, you should be using 
PSGI/Plack". Those people simply don't understand the overall utility 
of mod_perl beyond simply running a webapp . I have 
authentication and authorization handlers written in mod_perl, and the 
ability to directly access the Apache API allows things that PSGI 
simply cannot do.



--
The Wellcome Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 

Re: HTTP and MPM support

[Paul B. Henson]

On 1/25/2019 11:00 AM, Michael A. Capone wrote:

I have to add my voice to the growing chorus here.


Me too. Frequently when the topic of mod_perl going stale comes up 
somebody jumps in with "That's old stuff, you should be using 
PSGI/Plack". Those people simply don't understand the overall utility of 
mod_perl beyond simply running a webapp . I have authentication 
and authorization handlers written in mod_perl, and the ability to 
directly access the Apache API allows things that PSGI simply cannot do.

Re: HTTP and MPM support

[Sive Lindmark]

> On 25 Jan 2019, at 20:00, Michael A. Capone  
> wrote:
> 
> 
> 
> On 1/25/19 10:54 AM, Randolf Richardson wrote:
>>> On 25.01.2019 1modperl@perl.apache.org8:35, John Dunlap wrote:
 I'm in the process of optimizing our web application for performance and 
 one thing that I
 was really excited to try was mod_http2 because it allows the browser to 
 send multiple
 requests through the same TCP connection with compressed headers.
> 
  Are there any plans to support other MPM's? If not, the
 benefits of HTTP2 appear to be permanently out of reach for our mod_perl 
 applications and
 that, honestly, might force us into seriously reevaluating our technology 
 stack. :(
 
>>> Am I allowed to jump into the same thread, and ask about what the general 
>>> status of
>>> mod_perl is, nowadays (if someone knows) ?
> 
>>> (Mind you, for us MPM prefork and HTTP 1.1 are still perfectly ok, but the 
>>> question is
>>> more about the longer-term future).
>>  I'm also curious about this as I anticipate HTTP/2 support becoming
>> a valuable and important feature in the future (the recent updates to
>> mod_perl2 have been good for us).
>> 
>> Randolf Richardson - rand...@inter-corporate.com
>> Inter-Corporate Computer & Network Services, Inc.
>> Beautiful British Columbia, Canada
>> http://www.inter-corporate.com/
>> 
>> 
> I have to add my voice to the growing chorus here.  As it stands, we are 
> forced to choose between mod_perl and HTTP/2.  At the moment, our shop has 
> chosen to keep mod_perl, but I share the above concerns, and I'd rather see 
> mod_perl be ready if there is ever a major cultural shift / push to HTTP/2 in 
> the broader market.

as a owner of a small but quite fast growing company that first used MPW worker 
which was a little bit unstable and then went for prefork and this is working 
very well for now ...but it would be fantastic to have a stable worker for 
http/2, so if someone? can fix it we can probably sponsor part of work for I am 
sure that changing technic cost a lot more …  /Sive

Re: HTTP and MPM support

[Michael A. Capone]

On 1/25/19 10:54 AM, Randolf Richardson wrote:

On 25.01.2019 18:35, John Dunlap wrote:

I'm in the process of optimizing our web application for performance and one 
thing that I
was really excited to try was mod_http2 because it allows the browser to send 
multiple
requests through the same TCP connection with compressed headers.



  Are there any plans to support other MPM's? If not, the
benefits of HTTP2 appear to be permanently out of reach for our mod_perl 
applications and
that, honestly, might force us into seriously reevaluating our technology 
stack. :(


Am I allowed to jump into the same thread, and ask about what the general 
status of
mod_perl is, nowadays (if someone knows) ?



(Mind you, for us MPM prefork and HTTP 1.1 are still perfectly ok, but the 
question is
more about the longer-term future).

I'm also curious about this as I anticipate HTTP/2 support becoming
a valuable and important feature in the future (the recent updates to
mod_perl2 have been good for us).

Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/


I have to add my voice to the growing chorus here.  As it stands, we are 
forced to choose between mod_perl and HTTP/2.  At the moment, our shop 
has chosen to keep mod_perl, but I share the above concerns, and I'd 
rather see mod_perl be ready if there is ever a major cultural shift / 
push to HTTP/2 in the broader market.

Re: HTTP and MPM support

[Randolf Richardson]

> On 25.01.2019 18:35, John Dunlap wrote:
> > I'm in the process of optimizing our web application for performance and 
> > one thing that I
> > was really excited to try was mod_http2 because it allows the browser to 
> > send multiple
> > requests through the same TCP connection with compressed headers. However, 
> > when I enabled
> > it and restarted apache I was greeted with this:
> >
> > [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The mpm 
> > module
> > (prefork.c) is not supported by mod_http2. The mpm determines how things 
> > are processed in
> > your server. HTTP/2 has more demands in this regard and the currently 
> > selected mpm will
> > just not do. This is an advisory warning. Your server will continue to 
> > work, but the
> > HTTP/2 protocol will be inactive.
> > [Fri Jan 25 12:30:57.828217 2019] [mpm_prefork:notice] [pid 10186] AH00163: 
> > Apache/2.4.29
> > (Ubuntu) OpenSSL/1.1.0g mod_apreq2-20090110/2.8.0 mod_perl/2.0.10 
> > Perl/v5.26.1 configured
> > -- resuming normal operations
> > [Fri Jan 25 12:30:57.828238 2019] [core:notice] [pid 10186] AH00094: 
> > Command line:
> > '/usr/sbin/apache2'
> >
> > The last time I tried to use either mpm_worker or mpm_event my application 
> > was plagued by
> > seemingly random segfaults. Are there any plans to support other MPM's? If 
> > not, the
> > benefits of HTTP2 appear to be permanently out of reach for our mod_perl 
> > applications and
> > that, honestly, might force us into seriously reevaluating our technology 
> > stack. :(
> >
> 
> Am I allowed to jump into the same thread, and ask about what the general 
> status of 
> mod_perl is, nowadays (if someone knows) ?
> I am very happy with mod_perl, which we have been using for many years and 
> still use 
> extensively in our applications.
> And it is true that mod_perl allows one to "do things" in/with Apache httpd, 
> that no other 
> Apache add-on module seems to even approach.
> But it seemed that it took quite a long time for mod_perl to become available 
> again when 
> Apache went from 2.2 to 2.4, and it seems indeed that not much is happening 
> lately in 
> terms of making it work reliably under MPM's other than prefork.
> So I am curious too, like John above.
> 
> (Mind you, for us MPM prefork and HTTP 1.1 are still perfectly ok, but the 
> question is 
> more about the longer-term future).

I'm also curious about this as I anticipate HTTP/2 support becoming 
a valuable and important feature in the future (the recent updates to 
mod_perl2 have been good for us).

We use mod_perl2 extensively in all the web site application 
programming that we do.  We just finished writing an online store 
application, and are now in the process of creating a social network 
platform, both of which are using mod_perl2 and PostgreSQL.

Being able to write Perl code to handle the authentication phases 
directly, and pass our DBI handle and other instantiated Perl objects 
to other Perl scripts in the same session using $r->pnotes has also 
provided wonderful performance benefits.

Perl has such a vast array of modules that make it easy to 
accomplish a lot productively without having to "re-invent the wheel" 
and so I regard mod_perl2 as one of Apache HTTPd's most valuable 
modules that has ever been created.

Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

Re: HTTP and MPM support

[tomcat]

On 25.01.2019 18:35, John Dunlap wrote:

I'm in the process of optimizing our web application for performance and one 
thing that I
was really excited to try was mod_http2 because it allows the browser to send 
multiple
requests through the same TCP connection with compressed headers. However, when 
I enabled
it and restarted apache I was greeted with this:

[Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The mpm 
module
(prefork.c) is not supported by mod_http2. The mpm determines how things are 
processed in
your server. HTTP/2 has more demands in this regard and the currently selected 
mpm will
just not do. This is an advisory warning. Your server will continue to work, 
but the
HTTP/2 protocol will be inactive.
[Fri Jan 25 12:30:57.828217 2019] [mpm_prefork:notice] [pid 10186] AH00163: 
Apache/2.4.29
(Ubuntu) OpenSSL/1.1.0g mod_apreq2-20090110/2.8.0 mod_perl/2.0.10 Perl/v5.26.1 
configured
-- resuming normal operations
[Fri Jan 25 12:30:57.828238 2019] [core:notice] [pid 10186] AH00094: Command 
line:
'/usr/sbin/apache2'

The last time I tried to use either mpm_worker or mpm_event my application was 
plagued by
seemingly random segfaults. Are there any plans to support other MPM's? If not, 
the
benefits of HTTP2 appear to be permanently out of reach for our mod_perl 
applications and
that, honestly, might force us into seriously reevaluating our technology 
stack. :(



Am I allowed to jump into the same thread, and ask about what the general status of 
mod_perl is, nowadays (if someone knows) ?
I am very happy with mod_perl, which we have been using for many years and still use 
extensively in our applications.
And it is true that mod_perl allows one to "do things" in/with Apache httpd, that no other 
Apache add-on module seems to even approach.
But it seemed that it took quite a long time for mod_perl to become available again when 
Apache went from 2.2 to 2.4, and it seems indeed that not much is happening lately in 
terms of making it work reliably under MPM's other than prefork.

So I am curious too, like John above.

(Mind you, for us MPM prefork and HTTP 1.1 are still perfectly ok, but the question is 
more about the longer-term future).


A. Warnier
(acting as) CTO
Mira Consulting GmbH