Discussion:
Future MPM Support?
David Hodgkinson
2018-06-07 17:44:37 UTC
Permalink
We’re all about the Plack these days.
Are there any plans for mod_perl to support mpm_event, mpm_worker? Every time I try to use something other than mpm_prefork I am plagued by segfaults.
--
John Dunlap
CTO | Lariat
877.268.6667
<100x60.png>
John Dunlap
2018-06-07 17:52:52 UTC
Permalink
Is Plack backwards compatible with mod_perl?
Post by David Hodgkinson
We’re all about the Plack these days.
Are there any plans for mod_perl to support mpm_event, mpm_worker? Every
time I try to use something other than mpm_prefork I am plagued by
segfaults.
--
John Dunlap
*CTO | Lariat *
*Direct:*
*Customer Service:*
877.268.6667
<100x60.png>
--
John Dunlap
*CTO | Lariat *

*Direct:*
****@lariat.co <***@lariat.co>*

*Customer Service:*
877.268.6667
***@lariat.co
John Dunlap
2018-06-08 01:08:02 UTC
Permalink
Does using mod_perl properly allow you to use mpm_event or mpm_worker?
Unfortunately Plack (and Catalyst especially) are a fairly poor comparison
to using mod_perl properly {unfortunately very few people do so} I've
looked at Dancer and Catalyst - both are OK at what they do - but they
don't really handle things in the really clean easy way that mod_perl does
{if you attach code to the right handlers/filters} meaning chopping in and
changing code can be quite difficult in them.
Both are good for simplish applications {yes and I've seen complex apps
written in them as well - but they usually need a lot more hardware support
than the equivalent mod_perl app to cope with demand}
Unfortunately writing good mod_perl apps is hard - and so few mod_perl
apps really make use of the underlying framework properly - effectively
using it for code caching and not much else
Moving your method handlers to the framework.
I like catalyst. Stand on the shoulders of giants. Mojolicious makes me
itch.
What is involved in porting an application from mod_perl to starman?
Throwing away logic and logical structure and replacing it with a much
less flexible approach...
No. Different concept.
Is Plack backwards compatible with mod_perl?
Post by David Hodgkinson
We’re all about the Plack these days.
This.
We have moved entirely to
nginx (doing the ssl where appropriate) -> starman (which uses plack) and
Dancer2
Life is a LOT better
—
Clive
--
John Dunlap
*CTO | Lariat *
*Direct:*
* Customer Service:*
877.268.6667
-- 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
<https://maps.google.com/?q=215+Euston+Road,+London,+NW1+2BE&entry=gmail&source=g>.
--
John Dunlap
*CTO | Lariat *

*Direct:*
****@lariat.co <***@lariat.co>*

*Customer Service:*
877.268.6667
***@lariat.co
Dr James Smith
2018-06-09 11:03:12 UTC
Permalink
No - because of the way it works it handles the request inside apache -
the worker/event systems work by handing the request back to another
process or processes in the background which handles the request and
then returns - which is where the problem lies in the fact that you are
effectively adding a proxy layer between the web-request and the actual
perl process...

It limits what you can do with Plack when it comes to handling aspects
of the request which are better handled outside the main response phase
{e.g. re-write, logging, cleanup etc} which limits functionality - most
people who just use response handlers do not see this issue. But we hook
into about 10 phases of the apache process ...
Post by John Dunlap
Does using mod_perl properly allow you to use mpm_event or mpm_worker?
Unfortunately Plack (and Catalyst especially) are a fairly poor
comparison to using mod_perl properly {unfortunately very few
people do so} I've looked at Dancer and Catalyst - both are OK at
what they do - but they don't really handle things in the really
clean easy way that mod_perl does {if you attach code to the right
handlers/filters} meaning chopping in and changing code can be
quite difficult in them.
Both are good for simplish applications {yes and I've seen complex
apps written in them as well - but they usually need a lot more
hardware support than the equivalent mod_perl app to cope with demand}
Unfortunately writing good mod_perl apps is hard - and so few
mod_perl apps really make use of the underlying framework properly
- effectively using it for code caching and not much else
Moving your method handlers to the framework.
I like catalyst. Stand on the shoulders of giants. Mojolicious
makes me itch.
What is involved in porting an application from mod_perl to starman?
Throwing away logic and logical structure and replacing it with a
much less flexible approach...
On Thu, Jun 7, 2018 at 6:18 PM, Clive Eisen
On 7 Jun 2018, at 19:13, David Hodgkinson
No. Different concept.
Post by John Dunlap
Is Plack backwards compatible with mod_perl?
On Thu, Jun 7, 2018 at 5:44 PM, David Hodgkinson
We’re all about the Plack these days.
This.
We have moved entirely to
nginx (doing the ssl where appropriate) -> starman (which
uses plack) and Dancer2
Life is a LOT better
—
Clive
--
John Dunlap
/CTO | Lariat/
/
/
/*Direct:*/
/
*Customer Service:*/
877.268.6667
-- 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
<https://maps.google.com/?q=215+Euston+Road,+London,+NW1+2BE&entry=gmail&source=g>.
--
John Dunlap
/CTO | Lariat/
/
/
/*Direct:*/
/
*Customer Service:*/
877.268.6667
--
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.
Paul Silevitch
2018-07-29 20:18:54 UTC
Permalink
Like Dr. James Smith, I'm hooking into multiple handlers and using filters.
I'm currently using prefork but thought people were using worker in
production (assuming the application is thread safe). Is that not the case?

Paul
Post by Dr James Smith
No - because of the way it works it handles the request inside apache -
the worker/event systems work by handing the request back to another
process or processes in the background which handles the request and then
returns - which is where the problem lies in the fact that you are
effectively adding a proxy layer between the web-request and the actual
perl process...
It limits what you can do with Plack when it comes to handling aspects of
the request which are better handled outside the main response phase {e.g.
re-write, logging, cleanup etc} which limits functionality - most people
who just use response handlers do not see this issue. But we hook into
about 10 phases of the apache process ...
Does using mod_perl properly allow you to use mpm_event or mpm_worker?
Unfortunately Plack (and Catalyst especially) are a fairly poor
comparison to using mod_perl properly {unfortunately very few people do so}
I've looked at Dancer and Catalyst - both are OK at what they do - but they
don't really handle things in the really clean easy way that mod_perl does
{if you attach code to the right handlers/filters} meaning chopping in and
changing code can be quite difficult in them.
Both are good for simplish applications {yes and I've seen complex apps
written in them as well - but they usually need a lot more hardware support
than the equivalent mod_perl app to cope with demand}
Unfortunately writing good mod_perl apps is hard - and so few mod_perl
apps really make use of the underlying framework properly - effectively
using it for code caching and not much else
Moving your method handlers to the framework.
I like catalyst. Stand on the shoulders of giants. Mojolicious makes me
itch.
What is involved in porting an application from mod_perl to starman?
Throwing away logic and logical structure and replacing it with a much
less flexible approach...
No. Different concept.
Is Plack backwards compatible with mod_perl?
Post by David Hodgkinson
We’re all about the Plack these days.
This.
We have moved entirely to
nginx (doing the ssl where appropriate) -> starman (which uses plack)
and Dancer2
Life is a LOT better
—
Clive
--
John Dunlap
*CTO | Lariat *
*Direct:*
* Customer Service:*
877.268.6667
-- 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
<https://maps.google.com/?q=215+Euston+Road,+London,+NW1+2BE&entry=gmail&source=g>.
--
John Dunlap
*CTO | Lariat *
*Direct:*
* Customer Service:*
877.268.6667
-- 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
<https://maps.google.com/?q=215+Euston+Road,+London,+NW1+2BE&entry=gmail&source=g>.
John Dunlap
2018-07-29 20:21:39 UTC
Permalink
prefork is, currently, is still the only MPM which works reliably for us.
The others segfault at seemingly random intervals.
Post by Paul Silevitch
Like Dr. James Smith, I'm hooking into multiple handlers and using
filters. I'm currently using prefork but thought people were using worker
in production (assuming the application is thread safe). Is that not the
case?
Paul
Post by Dr James Smith
No - because of the way it works it handles the request inside apache -
the worker/event systems work by handing the request back to another
process or processes in the background which handles the request and then
returns - which is where the problem lies in the fact that you are
effectively adding a proxy layer between the web-request and the actual
perl process...
It limits what you can do with Plack when it comes to handling aspects of
the request which are better handled outside the main response phase {e.g.
re-write, logging, cleanup etc} which limits functionality - most people
who just use response handlers do not see this issue. But we hook into
about 10 phases of the apache process ...
Does using mod_perl properly allow you to use mpm_event or mpm_worker?
Unfortunately Plack (and Catalyst especially) are a fairly poor
comparison to using mod_perl properly {unfortunately very few people do so}
I've looked at Dancer and Catalyst - both are OK at what they do - but they
don't really handle things in the really clean easy way that mod_perl does
{if you attach code to the right handlers/filters} meaning chopping in and
changing code can be quite difficult in them.
Both are good for simplish applications {yes and I've seen complex apps
written in them as well - but they usually need a lot more hardware support
than the equivalent mod_perl app to cope with demand}
Unfortunately writing good mod_perl apps is hard - and so few mod_perl
apps really make use of the underlying framework properly - effectively
using it for code caching and not much else
Moving your method handlers to the framework.
I like catalyst. Stand on the shoulders of giants. Mojolicious makes me
itch.
What is involved in porting an application from mod_perl to starman?
Throwing away logic and logical structure and replacing it with a much
less flexible approach...
No. Different concept.
Is Plack backwards compatible with mod_perl?
Post by David Hodgkinson
We’re all about the Plack these days.
This.
We have moved entirely to
nginx (doing the ssl where appropriate) -> starman (which uses plack)
and Dancer2
Life is a LOT better
—
Clive
--
John Dunlap
*CTO | Lariat *
*Direct:*
* Customer Service:*
877.268.6667
-- 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
<https://maps.google.com/?q=215+Euston+Road,+London,+NW1+2BE&entry=gmail&source=g>.
--
John Dunlap
*CTO | Lariat *
*Direct:*
* Customer Service:*
877.268.6667
-- 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
<https://maps.google.com/?q=215+Euston+Road,+London,+NW1+2BE&entry=gmail&source=g>.
--
John Dunlap
*CTO | Lariat *

*Direct:*
****@lariat.co <***@lariat.co>*

*Customer Service:*
877.268.6667
***@lariat.co
Paul B. Henson
2018-07-30 01:51:46 UTC
Permalink
Post by Paul Silevitch
Like Dr. James Smith, I'm hooking into multiple handlers and using filters.
Yep, me too; Plack is really not a feature equivilent replacement for
mod_perl :(.
André Warnier (tomcat)
2018-07-30 08:44:30 UTC
Permalink
Post by Paul B. Henson
Post by Paul Silevitch
Like Dr. James Smith, I'm hooking into multiple handlers and using filters.
Yep, me too; Plack is really not a feature equivilent replacement for
mod_perl :(.
+1.
Plack and other frameworks (TT2, Moose, Catalyst, etc.) cover the web application side, at
different levels and in different ways.
But there is (to my knowledge) no equivalent for mod_perl's ability to interact deeply
with the Apache internal Request processing logic.
In that respect, comparing mod_perl to Plack etc is like comparing apples to pears : not
very relevant.
Considering that, for better or worse, Perl as a programming language does not seem to be
really attractive to the current generation of software developers anymore, I would not
really mind if some tool equivalent to mod_perl was developed using whichever other
scripting language is currently more in fashion (javascript ? python ? ..), but it really
seems a pity to "slowly abandon" mod_perl without providing some tool of equivalent power
in terms of deep interaction with Apache httpd.
Robert Smith
2018-08-01 11:30:39 UTC
Permalink
Who in the world would want to abandon mod_perl?

What is this world coming to?

-Robert
Post by Paul B. Henson
Post by Paul Silevitch
Like Dr. James Smith, I'm hooking into multiple handlers and using filters.
Yep, me too; Plack is really not a feature equivilent replacement for
mod_perl :(.
+1.
Plack and other frameworks (TT2, Moose, Catalyst, etc.) cover the web application side, at different levels and in different ways.
But there is (to my knowledge) no equivalent for mod_perl's ability to interact deeply with the Apache internal Request processing logic.
In that respect, comparing mod_perl to Plack etc is like comparing apples to pears : not very relevant.
Considering that, for better or worse, Perl as a programming language does not seem to be really attractive to the current generation of software developers anymore, I would not really mind if some tool equivalent to mod_perl was developed using whichever other scripting language is currently more in fashion (javascript ? python ? ..), but it really seems a pity to "slowly abandon" mod_perl without providing some tool of equivalent power in terms of deep interaction with Apache httpd.
John Dunlap
2018-08-01 16:44:03 UTC
Permalink
The biggest deficiency of mod_perl, at the moment, is that it cannot
provide web sockets. In today's world, that's a huge problem.
Post by Robert Smith
Who in the world would want to abandon mod_perl?
What is this world coming to?
-Robert
Post by André Warnier (tomcat)
Post by Paul B. Henson
Post by Paul Silevitch
Like Dr. James Smith, I'm hooking into multiple handlers and using
filters.
Post by André Warnier (tomcat)
Post by Paul B. Henson
Yep, me too; Plack is really not a feature equivilent replacement for
mod_perl :(.
+1.
Plack and other frameworks (TT2, Moose, Catalyst, etc.) cover the web
application side, at different levels and in different ways.
Post by André Warnier (tomcat)
But there is (to my knowledge) no equivalent for mod_perl's ability to
interact deeply with the Apache internal Request processing logic.
Post by André Warnier (tomcat)
In that respect, comparing mod_perl to Plack etc is like comparing
apples to pears : not very relevant.
Post by André Warnier (tomcat)
Considering that, for better or worse, Perl as a programming language
does not seem to be really attractive to the current generation of software
developers anymore, I would not really mind if some tool equivalent to
mod_perl was developed using whichever other scripting language is
currently more in fashion (javascript ? python ? ..), but it really seems a
pity to "slowly abandon" mod_perl without providing some tool of equivalent
power in terms of deep interaction with Apache httpd.
--
John Dunlap
*CTO | Lariat *

*Direct:*
****@lariat.co <***@lariat.co>*

*Customer Service:*
877.268.6667
***@lariat.co
Paul Silevitch
2018-08-04 12:47:04 UTC
Permalink
Also issues with http/2 since it is not supported by prefork mpm anymore.
Post by John Dunlap
The biggest deficiency of mod_perl, at the moment, is that it cannot
provide web sockets. In today's world, that's a huge problem.
Post by Robert Smith
Who in the world would want to abandon mod_perl?
What is this world coming to?
-Robert
Post by André Warnier (tomcat)
Post by Paul B. Henson
Post by Paul Silevitch
Like Dr. James Smith, I'm hooking into multiple handlers and using
filters.
Post by André Warnier (tomcat)
Post by Paul B. Henson
Yep, me too; Plack is really not a feature equivilent replacement for
mod_perl :(.
+1.
Plack and other frameworks (TT2, Moose, Catalyst, etc.) cover the web
application side, at different levels and in different ways.
Post by André Warnier (tomcat)
But there is (to my knowledge) no equivalent for mod_perl's ability to
interact deeply with the Apache internal Request processing logic.
Post by André Warnier (tomcat)
In that respect, comparing mod_perl to Plack etc is like comparing
apples to pears : not very relevant.
Post by André Warnier (tomcat)
Considering that, for better or worse, Perl as a programming language
does not seem to be really attractive to the current generation of software
developers anymore, I would not really mind if some tool equivalent to
mod_perl was developed using whichever other scripting language is
currently more in fashion (javascript ? python ? ..), but it really seems a
pity to "slowly abandon" mod_perl without providing some tool of equivalent
power in terms of deep interaction with Apache httpd.
--
John Dunlap
*CTO | Lariat *
*Direct:*
*Customer Service:*
877.268.6667
Loading...