We use Apache/mod_perl 2 and occasionally get a child httpd process that spins
out of control, either consuming ever-increasing amounts of memory or max cpu.
Usually due to an infinite loop or other bug in a specific part of the site -
this sort of thing happens.
I would like to monitor for
We use Mason 1.x inside a custom web framework (which I've recently gotten
permission to release open-source), under mod_perl/Apache 2. Working on a
transition to Plack and Mason 2, but we've already integrated the superior
stack traces and debug console from Plack middleware.
On Jun 15, 2011,
Thanks André. I haven't touched the site in a while but it's due for an
overhaul (and conversion to Mason 2) so will hopefully fix things then.
On Feb 24, 2011, at 12:56 PM, André Warnier wrote:
This being said, I would like to report a small bug, I believe more of the
web server than Mason,
of you Mason users on the mod_perl list aren't on the Mason
list...
- Perrin
-- Forwarded message --
From: Jonathan Swartz swa...@pobox.com
Date: Mon, Feb 21, 2011 at 11:16 AM
Subject: [Mason] ANNOUNCE: Mason 2
To: Mason-Users List mason-us...@lists.sourceforge.net
I'm
is there any big player using Mason these days?
On Tue, Feb 22, 2011 at 2:24 AM, Perrin Harkins per...@elem.com wrote:
In case any of you Mason users on the mod_perl list aren't on the Mason
list...
- Perrin
-- Forwarded message --
From: Jonathan Swartz swa...@pobox.com
Date
On Feb 22, 2011, at 6:55 AM, Phil Carmody wrote:
--- On Tue, 2/22/11, Jonathan Swartz swa...@pobox.com wrote:
I'm pleased to
announce Mason 2, the first major version of Mason in ten
years:
http://search.cpan.org/perldoc?Mason
Mason is a templating framework for generating web pages
I'm pleased to announce Mason 2, the first major version of Mason in ten years:
http://search.cpan.org/perldoc?Mason
Mason is a templating framework for generating web pages and other dynamic
content. Mason 2 has been rearchitected and reimplemented from the ground up,
to take advantage of
On May 27, 2010, at 1:04 PM, Perrin Harkins wrote:
On Thu, May 27, 2010 at 11:11 AM, Michael Schout msch...@gkg.net
wrote:
My solution involved forking off a watcher process when the server
starts up.
Wouldn't it be simpler to start a separate daemon for this? You could
launch it from
On Jan 27, 2010, at 2:45 PM, Perrin Harkins wrote:
On Tue, Jan 26, 2010 at 7:42 PM, Jonathan Swartz swa...@pobox.com
wrote:
On our site we create a new CGI::Session object at the beginning of
the
request, so that it can be used anywhere in the web code.
However, sessions are rarely written
On our site we create a new CGI::Session object at the beginning of
the request, so that it can be used anywhere in the web code.
However, sessions are rarely written to, so at the end of the request
I'd like to avoid actually writing out a new session to backing store
unless a param
This never got a response. Which surprises me, since I think it is a
legitimate and nasty bug.
So is the silence because
1) people don't think it's really a bug
2) people glazed over while reading the description
3) ??
Thanks :)
Jon
On Jan 8, 2010, at 6:15 AM, Jonathan Swartz wrote
(A continuation of:
http://marc.info/?l=apache-modperlm=117507879929572w=2
http://marc.info/?l=apache-modperlm=119072925228529w=2
)
I've just spent many frustrating days debugging a situation that
turned out to be caused by mod_perl's closing of file descriptor 1
(STDOUT).
Here's the
Server::Control allows you to control servers ala apachectl, but with
better diagnostics and many more features. It includes both a drop-in
replacement for apachectl (”apachectlp”) and an OO interface.
Though it was designed with Apache in mind, there are also subclasses
for
On Sep 25, 2009, at 10:48 AM, Clinton Gormley wrote:
If I don't ever plan to use graceful restarts, and I believe that
smaller restart times are an unqualified Good, is there any reason
why
I shouldn't ALWAYS use a script like the above? And is there any way
to avoid PerlModule modules
On Oct 2, 2009, at 3:25 PM, Perrin Harkins wrote:
On Fri, Oct 2, 2009 at 5:54 PM, Jonathan Swartz swa...@pobox.com
wrote:
Ok, one more question. Disregarding graceful for the moment - is HUP
completely reliable with mod_perl at this point, or is there still
a reason
(as there once
I was looking into why our server's restarts take so long, and I
finally remembered that Apache runs its initialization step twice on
startup (http://tinyurl.com/krr25). This means that my startup.pl is
loaded twice, along with any modules that it loads.
So I moved startup.pl to
There's only one small gotcha that I've found, and that occurs in this
situation:
- apache isn't running
- you do : apachectl restart
- there is a compile time bug, and apache dies
The gotcha is that you don't get any STDERR or log output in this
situation. However, you're only ever likely to
Nope, I still get the error in the logs. It just takes a few seconds
to show up.
On Sep 25, 2009, at 11:20 AM, Clinton Gormley wrote:
Hm. No compile errors would be bad. But I put an error in one of my
modules (that only gets loaded the second time) and started apache,
and got error log
I'm thinking about an improved solution to recognizing module changes
in a running server, without restarting the server.
These are the solutions I know about:
1) Apache2::Reload / Module::Reload
These check whether modules have changed on each request, and if so,
clear their symbols and
-2.0.4,
Apache2::Reload is gone (so you can remove that from your list of
options).
--
Devin
On Fri, 2009-09-11 at 14:26 -0700, Jonathan Swartz wrote:
I'm thinking about an improved solution to recognizing module changes
in a running server, without restarting the server.
These are the solutions I
On Sep 11, 2009, at 2:52 PM, Perrin Harkins wrote:
On Fri, Sep 11, 2009 at 5:26 PM, Jonathan Swartz swa...@pobox.com
wrote:
This is the nicest solution I've seen so far. The only problem I
can see is
its performance - each potentially-changing module has to be loaded
on each
request
in as dependencies?
On Sep 11, 2009, at 2:52 PM, Perrin Harkins wrote:
On Fri, Sep 11, 2009 at 5:26 PM, Jonathan Swartz swa...@pobox.com
wrote:
This is the nicest solution I've seen so far. The only problem I
can see is
its performance - each potentially-changing module has to be loaded
On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz swa...@pobox.com
wrote:
It seems like it's available separately in Apache-Reload
distribution:
http://cpan.uwinnipeg.ca/dist/Apache-Reload
But it's already pretty much a straw-man option for me. :)
Problem: some modules fail to reload
On Sep 11, 2009, at 3:53 PM, Fred Moyer wrote:
On Fri, Sep 11, 2009 at 3:37 PM, Jonathan Swartz swa...@pobox.com
wrote:
On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz
swa...@pobox.com wrote:
It seems like it's available separately in Apache-Reload
distribution:
http
We've got a bunch of legacy code that uses $ENV{SCRIPT_URI},
$ENV{SERVER_PORT}, $r-server-port and the like to generate external
redirects.
This has worked fine til now, but now we are moving to a system where
our external port != our internal port - the load balancer is going to
forward
We've got a bunch of legacy code that uses $ENV{SCRIPT_URI},
$ENV{SERVER_PORT}, $r-server-port and the like to generate
external
redirects.
If these are really external redirects, they must happen through a
Location: response header, no ?
In that case, what about leaving your code alone
I'm running into the problem using Linux::Smaps on RHEL with an Apache
server on port 80. Namely, that the httpd child doesn't have
permissions to look at the smaps file.
Linux::Smaps: Cannot open /proc/20074/smaps: Permission denied
or
Linux::Smaps: Cannot open /proc/self/smaps:
Over the years I've developed (as I'm sure many have :)) a small home-
grown replacement for apachectl, to make start/stop/restart easier.
It's in library form, and among other things it
* detects whether the server is actually running, by contacting the port
* waits to make sure the server
, obviously
I'm guessing that my code, with subclassing, could work equally well
for apache, lighttpd, and HTTP::Server::Simple.
Jon
On Jun 5, 2009, at 2:21 PM, Jonathan Swartz wrote:
Over the years I've developed (as I'm sure many have :)) a small
home-grown replacement for apachectl, to make
I'm wondering if anyone uses Apache's graceful stop feature (http://
httpd.apache.org/docs/2.2/stopping.html#gracefulstop) with mod_perl
servers.
The mod_perl guide section on starting and stopping (http://
perl.apache.org/docs/general/control/
Perrin Harkins writes:
Sorry if I came off overly critical. Many people have had problems
trying to use Mason with Apache::Session because of that article. This
is why on the Mason website the link to that article describes it as
outdated and steers people to newer documentation. (It
The latest Apache::Session on CPAN is version 1.54, released in
October
2001.
Perhaps this answers my previous question. :)
Yes, it is far from actively maintained. I've been considering
recommending that people use CGI::Session instead, since it is better
documented and better
On Thu, 2003-11-13 at 15:18, Jonathan Swartz wrote:
Interesting! I'll take a look. Have you seen any comparisons of features
anywhere?
No, I don't think anyone has written up a comparison.
Well, at first glance it looks promising - lots of documentation and
examples, last release pretty
On Thu, 2003-11-13 at 16:47, Jonathan Swartz wrote:
So the default MySQL driver does locking just like Apache::Session, and
there's no built-in way to turn it locking. So it's possible that the
same
locking problems that plague Apache::Session would happen in
CGI::Session.
Argh!
So
34 matches
Mail list logo
