> Apache2-Dispatch-0.13.tar.gz
This looks like a useful module, Fred.
Is anyone here using this as an initial dispatcher to pass things on to
CGI::Application::Dispatch?
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrincipal Develo
I revisited the issue of 404 handling in CGI and Apache::Registry today and
here's
what I found. For illustration, here's a minimal CGI script which can
illustrate the issue:
#!/usr/bin/perl
print "Status: 404\r\nContent-Type: text/html\r\n\r\nHello";
You can review the status codes being ret
pache/mod_perl compiled against 5.8 if I need to.
Am I missing anything major here? I realize there are some details about port
allocation that I'll need to address.
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrincipal Developer
Hello,
I'm doing some maintenance on CGI.pm now and could use help tracking down a
bug only reported when running under mod_perl.
Here's the bug report:
"mod_perl resets $XHTML to 1 after first request"
http://rt.cpan.org/Public/Bug/Display.html?id=30774
Comments and patches are welcome. The
> Take some elements from the form and search for an add in the past
> . We did one recently where we took the email address,
> recipient and amount from the form and then made sure that the same
> data hadn't already been submitted in the last 24 hours - working on
> the principle that a
On Wed, 15 Oct 2008 13:51:21 -0400
Michael Peters <[EMAIL PROTECTED]> wrote:
> Mark Stosberg wrote:
>
> > At one point in the past I did a variation of this where we put the next ID
> > of
> > a related database sequence in the form, and this would become the
On Wed, 15 Oct 2008 12:41:55 -0400
"Perrin Harkins" <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 12:31 PM, Mark Stosberg <[EMAIL PROTECTED]> wrote:
> > We had a "double submit" bug that allowed a form to be submitted twice when
> > we
&g
On Tue, 30 Sep 2008 10:06:26 -0400
Mark Stosberg <[EMAIL PROTECTED]> wrote:
> On Mon, 29 Sep 2008 17:04:29 -0400
> "Perrin Harkins" <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Sep 29, 2008 at 3:00 PM, Mark Stosberg <[EMAIL PROTECTED]> wrote:
> > &
On Mon, 29 Sep 2008 17:04:29 -0400
"Perrin Harkins" <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 3:00 PM, Mark Stosberg <[EMAIL PROTECTED]> wrote:
> > We have a large, busy, database application that relates to millions of
> > photos, which we also nee
currently not accessible from the
master PostgreSQL server.
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrincipal Developer
[EMAIL PROTECTED] Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
You points were all interesting and steer me back in the direction of trying to
better
understand and eliminate how inconsistency is creeping into our system.
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrincipal Developer
[EMAIL PROTE
anyone has had experience successfully storing photos
(or othe files) directly in database? That would solve the consistency
issue, but may create a performance issue. Perhaps the right kind of
caching layer could solve that.
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
> +my $dir = dirname(__FILE__);
> +use lib $dir.'/../config';
> +use lib $dir.'/../perllib';
Actually, for some reason that syntax didn't work either, but this did work on
my modperl-startup.pl:
use lib dirname(__FILE__).'/../config';
use lib dirname(__FILE__).'/../perllib';
On Fri, 25 Apr 2008 16:38:36 +0200
André Warnier <[EMAIL PROTECTED]> wrote:
> Mark Stosberg wrote:
> >> Sorry Mark, I misread your mail. I thought you were using
> >> PerlSetVar. What are you doing exactly? PerlSetEnv PERL5LIB?
> >
> > Exactly.
> >
> Sorry Mark, I misread your mail. I thought you were using PerlSetVar.
> What are you doing exactly? PerlSetEnv PERL5LIB?
Exactly.
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrincipal Developer
[EMAIL PROTECTED] Summersaul
> On Tue, Apr 22, 2008 at 2:27 PM, Mark Stosberg <[EMAIL PROTECTED]>
> wrote:
> > A. If I just set "status => 404" with CGI.pm / Apache::Registry
> > and return nothing, it works the first time, and then after that I
> >get a lot of these errors:
&g
;good enough", however I'm
interested to know why the environment variable would be missing when
the 404 page is called, especially when it works on the first load.
Thanks!
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrincipal Devel
It seems that using CGI, it is too late return a true 404 once the
script is processing the request. It's possible to still send output
that returns "page not found" text, but the HTTP status code will be 200.
More recently, I learned that with mod_perl, I learned that I can get
the system to
Hello,
Recently I ran into a bug with File::MMagic where it returns
inconsistent results under mod_perl.
I'm interested in getting this bug fixed, or using an alternative module
that works.
What's interesting is that the same version of File::MMagic works
correctly on a different machine. I susp
Hello,
I'm researching how to best integrate caching with a mod_perl website.
For some important cases I want to do some customized stat tracking for
particular queries, although they otherwise return the same content,
which would otherwise be directly cacheable.
The approach that seems to fit t
Andy Armstrong wrote:
> On 10 Jan 2007, at 17:05, Randal L. Schwartz wrote:
>> Why would anyone use this instead of CGI.pm?
>
> If you expect me to justify it you've got the wrong guy Randal :)
>
> Ovid reckons people use it so I pitched in to try and fix it. The code
> is quite nasty in places -
I found a related mention of this issue here:
http://fudforum.org/forum/index.php?t=msg&th=4598&start=0&;
There the fix involved putting using DEALLOCATE when persistent
first, the patch with DEALLOCATE makes prepared statements entirely
useless, as it means you're caching a prepared statement
Perrin Harkins wrote:
On Sat, 2006-08-05 at 09:02 -0500, Mark Stosberg wrote:
However, when deploying it on mod_perl on a busy website, I quickly saw
a lot of this kind of error:
prepared statement "dbdpg_7" already exists
Do you use prepare_cached? You might want to try that, wi
Hello,
I'm wondering if some other people here have some wisdom about this case
a few people have run into, apparently with no resolution.
Newer versions of DBD::Pg and PostgreSQL support a feature called
"server side prepares", which is supposed to give a significant
performance boost in so
ib");
use MyPackage;
my $app = MyPackage->new(
PARAMS => {
config_files => ["$Bin/../../config/Config.pl"],
}
);
###
Now the log warnings are gone.
Mark
--
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrinci
Hello,
I'm debugging why I'm getting 'server closed the connection
unexpectedly' intermittently in a modperl application.
Unfortunately it has only been seen on the production server and not on
our development server making it harder to debug.
On the database side, nothing looks unusual in the l
t; On Wed, 2005-07-06 at 18:11 +0000, Mark Stosberg wrote:
>> On the front end web server machine, the CPU spiked up well beyond
>> average and stayed there. On the backend PostgreSQL 7.4 server, we saw
>> a number or errors that that the number of max connections had been
>
Hello,
Yesterday we noticed two things happening about the same time with a
mod-perl driven website we managed, and I'm trying to figure out and if
how they were related.
On the front end web server machine, the CPU spiked up well beyond
average and stayed there. On the backend PostgreSQL 7.4 ser
Hello,
I'm trying to get Graphics::Magick to work with mod_perl on FreeBSD
4.10.
On our FreeBSD 5.1 development server, everything works fine.
It appears that as soon as the module is attempted to be used,
an infinite loop is entered resulting an out of memory error.
I used 'truss' to see what
On 2005-02-24, Slava Bizyayev <[EMAIL PROTECTED]> wrote:
> Hi Mark,
>
> Regarding the implementation of Apache::Clean, the question is --
> whether or not you can benefit one way or another from the fact that
> your uncompressed responses are 5-20% less? I can really talk about the
> Light-Compress
noticeably performance penalty.
It would same the bandwidth is more of an issue than the processor time, so my
assumption is that a little extra processor time would be a reasonable
trade-off.
Thanks!
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark Stosberg
On 2004-10-06, Mark Stosberg <[EMAIL PROTECTED]> wrote:
>
>>> Could setting MaxRequestsPerChild be a meaningful solution here? It
>>> would seem that this would cause the Apache child processes to
>>> periodically get re-created, killing related zombies in the
On 2004-10-06, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Wed, 2004-10-06 at 16:56, Mark Stosberg wrote:
>> At your recommended, I installed strace and ran it on the hung process.
>> It doesn't work.
>
> Hmm, maybe it's time to add some logging to your fork
rocesses to
periodically get re-created, killing related zombies in the process.
Thanks again. You're helping http://www.1-800-save-a-pet.com/ which
recently re-launched with Apache/mod_perl after using AOLserver with
TCL in its last incarnation.
Mark
--
. . . . . . . . . . . .
Hello,
I've been enjoying the performance benefits of mod_perl, and appreciate
the help of the contributors here.
Now I'm investigating why our production code is producing zombies. I'll
post the key parts of my code below. First, some observations:
1. Zombies appear to be created only in a m
Stas --
On 2004-02-26, Stas Bekman <[EMAIL PROTECTED]> wrote:
> Mark Stosberg wrote:
>> Hello,
>>
>> I'm a new modperl user, and I'm trying to figure out the joy that is
>> Apache::Reload.
>>
>> I keep having an issue where it can't fi
On 2004-03-12, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-03-12 at 16:11, Mark Stosberg wrote:
>> I'm out of any ideas. Any wild guesses appreciated. :)
>
> Your CGI::Session object is not going out of scope, so it doesn't get
> destroyed until you
27;m using CGI::Session with the CGI::Session::PureSQL driver.
Thanks!
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrincipal Developer
[EMAIL PROTECTED] Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . .
On 2004-02-29, Cees Hek <[EMAIL PROTECTED]> wrote:
> Hi Mark,
>
> What version of CGI.pm are you testing with? There are some known
> problems with using CGI.pm and mod_perl in older versions of CGI.pm.
> Upgrade to the latest version of CGI.pm and my guess is your problem
> will go away.
Cees
On 2004-02-28, sagi <[EMAIL PROTECTED]> wrote:
> Have you tried using Apache::Request instead of CGI?. It also has a
> similar API to CGI, and if youre running mod_perl, you should be using
> Apache::Request :)
>
> Check out:
> http://search.cpan.org/~joesuf/libapreq-1.3/Request/Request.pm
I'm awa
Hello,
I maintain the popular Data::FormValidator module, and am just starting
to use modperl myself. A couple of my users spotted a modperl-related
bug in the module. I've read the "CGI porting" document about basic
modperl traps, but I can't figure this out.
I have a test script for the issue
elative 'use lib' paths in the code?
Since I'm new at this, It's possible I missed some documentation on this
topic, and would happily accept a pointer to that if so.
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrincipa
42 matches
Mail list logo
