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