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 PerlRunOnce Off). The idea is that
> > everything runs under *.cgi in the beginning (which is the first step of
> > the migration), and then we slowly clean up files and put them into *.pr
> > files. The main problem is that because there's lots of references to
> > *.cgi everywhere, every file we cleaned up and renamed to *.pr would have
> > to have all of its referrers changed to do that (that's a lot of work).
>
> You could use the Trans stage and write a handler that would check
> that if it's a reference to *.cgi and that *.cgi doesn't exists but
> there is a *.pr file instead, the *.pr will be run with PerlRunOnce.
> Then you don't need to change anything in your links. I have it setup
> in similar thing and work just fine.
>
That makes sense, and we were thinking that we would probably have to
write a Apache module in order to have a solution. The issue is that the
entire situation is kind of hacky which is why we'd like to go with the
second migration strategy.
If it turns out the second strategy is unfeasible, I'd like to keep in
touch so that I might be able to look at some of your code. This project
would be my first Apache module.
> > 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 compromise between killing the child
> > everytime and keeping all the packages around.
>
> This is very good point. IMO what we might need is a module that would
> be run just at the end of the startup (or at child init), inspect what
> all modules are loaded, and store that information somewhere. Then
> within the PerlHandler (or perhaps even a bit sooner), everything
> instead of the packages (or generaly objects) that were noted to
> exist just whan the child started, would be cleaned, set to undef,
> deleted, whatever.
>
That sounds like a pretty concrete solution. It seemed weird that there
wasn't an in-between solution to the issue.
Does anyone have comments about this? It sounds good but how hard would
something like this be? If it's not too difficult it might be something we
could do in-house. Has anyone done something like this or are there
current solutions for this problem?
Thanks,
Andrew
