On Thu, 20 Jul 2000, Andrew Chen wrote:
> Another mod_perl success :)
Congratulations! If you have a chance, you might want to write a brief
desccription for the Success Stories page at
http://perl.apache.org/stories/.
- Perrin
Perrin, Ken, Honza, and all others that helped:
The problem was actually that I wasn't clearing %INC properly after
flushing out all the dirty modules. After doing that everything started
working properly.
So anyway, I wrote an Perl script and installed it as an
PerlCleanupHandler. I stole code
[EMAIL PROTECTED] (Perrin Harkins) wrote:
>On Mon, 17 Jul 2000, Andrew Chen wrote:
>
>> On Mon, 17 Jul 2000, Perrin Harkins wrote:
>>
>> > > I think it's trying to call a method for an object that doesn't
>> > > exist anymore. My guess is that I am keeping a certain variable
>> > > that keeps a
On Mon, 17 Jul 2000, Andrew Chen wrote:
> On Mon, 17 Jul 2000, Perrin Harkins wrote:
>
> > > I think it's trying to call a method for an object that doesn't exist
> > > anymore. My guess is that I am keeping a certain variable that keeps a
> > > list of the object in memory or something similar
On Mon, 17 Jul 2000, Perrin Harkins wrote:
> > I think it's trying to call a method for an object that doesn't exist
> > anymore. My guess is that I am keeping a certain variable that keeps a
> > list of the object in memory or something similar that I should really be
> > flushing. Because I'm p
On Mon, 17 Jul 2000, Andrew Chen wrote:
> In the to-keep list, there's the obvious stuff (database and other base
> libraries) but also I ran a blank script and kept all the variables
> brought up in that blank list (Apache::*, &c.). This way I'm not clearing
> stuff that I'm supposed to.
I'd sug
Thanks for the idea. I went ahead and implemented this, and am very close.
I currently have a script looks at all the variables and undefines all of
them with a few exceptions (code copied from PerlRun.pm of mod_perl
source). The way that the exceptions are managed is that I keep a list of
the var
On Fri, 14 Jul 2000, Andrew Chen wrote:
> > You can actually do this from one place, iterating through a list of
> > namespaces to flush. Look at the code in
> > Apache::PerlRun::flush_namepsace. It's pretty easy.
>
> We would still have to add code to every module, correct? Even though
> there
On Thu, 13 Jul 2000, Honza Pazdziora wrote:
> On Thu, Jul 13, 2000 at 01:54:28PM -0700, Andrew Chen wrote:
> >
> > That sounds like a pretty concrete solution. It seemed weird that there
> > wasn't an in-between solution to the issue.
>
> The reason probably is, that you really want to clean yo
On Thu, 13 Jul 2000, Perrin Harkins wrote:
> On Thu, 13 Jul 2000, Andrew Chen wrote:
> > PerlRun already flushes everything, but from my understanding of it,
> > with PerlRunOnce Off mod_perl won't flush the packages that were loaded by
> > the CGIs.
>
> What makes you think they need to be flus
On 13 Jul 2000, David Hodgkinson wrote:
> > Doesn't FastCGI have exactly the same issues with dirty code? It's an
> > honest question; I'm not just being difficult.
>
> Almost. It runs in the main package as usual so at least you won't see
> screams about "...won't stay shared..." and such.
I
On Thu, 13 Jul 2000, Andrew Chen wrote:
> PerlRun already flushes everything, but from my understanding of it,
> with PerlRunOnce Off mod_perl won't flush the packages that were loaded by
> the CGIs.
What makes you think they need to be flushed? Are they things you wrote
in-house that didn't fol
On Thu, Jul 13, 2000 at 01:54:28PM -0700, Andrew Chen wrote:
>
> That sounds like a pretty concrete solution. It seemed weird that there
> wasn't an in-between solution to the issue.
The reason probably is, that you really want to clean your code at
the end. So all the big guys are either writin
On Thu, 13 Jul 2000, Honza Pazdziora wrote:
> On Thu, Jul 13, 2000 at 11:51:14AM -0700, Andrew Chen wrote:
> >
> > The first one is that we have two types of files that are handled
> > differently, *.cgi (handled under PerlRun with PerlRunOnce On) and then
> > *.pr (handled under PerlRun with Pe
We basically want to run our scripts under PerlRun with PerlRunOnce Off.
The issue is that because we are a little short handed, and we have many
many many CGIs, any process of cleaning stuff up (maybe 1% has use strict)
would be a long and lengthy one.
PerlRun already flushes everything, but fro
On Thu, Jul 13, 2000 at 08:12:54PM +0100, David Hodgkinson wrote:
>
> How dirty is dirty?
>
> If it's a case of assembling the globals into a big "use vars qw//"
> then that's OK. Boring but do-able.
There are problems like
$action = 'save' if $q->param('action') eq 'save';
We have a
On Thu, Jul 13, 2000 at 11:51:14AM -0700, Andrew Chen wrote:
>
> The first one is that we have two types of files that are handled
> differently, *.cgi (handled under PerlRun with PerlRunOnce On) and then
> *.pr (handled under PerlRun with PerlRunOnce Off). The idea is that
> everything runs unde
Perrin Harkins <[EMAIL PROTECTED]> writes:
> Doesn't FastCGI have exactly the same issues with dirty code? It's an
> honest question; I'm not just being difficult.
Almost. It runs in the main package as usual so at least you won't see
screams about "...won't stay shared..." and such. You also
On 13 Jul 2000, David Hodgkinson wrote:
> Andrew Chen <[EMAIL PROTECTED]> writes:
>
> > Hi, I'm researching the nicest way to migrate our CGIs to running under
> > mod_perl, and although they are too dirty to run under Apache::Registry,
> > Apache::PerlRun works just fine.
>
> *snip*
>
> How d
On Thu, 13 Jul 2000, Andrew Chen wrote:
> The second strategy is to get mod_perl to compromise between the effects
> of PerlRunOnce On and PerlRunOnce Off. Is there an easy for for PerlRun to
> flush everything (including packages) that wasn't preloaded in the
> startup.pl file? That would be a c
Andrew Chen <[EMAIL PROTECTED]> writes:
> Hi, I'm researching the nicest way to migrate our CGIs to running under
> mod_perl, and although they are too dirty to run under Apache::Registry,
> Apache::PerlRun works just fine.
*snip*
How dirty is dirty?
If it's a case of assembling the globals i
21 matches
Mail list logo
