Loading ...
Sorry, an error occurred while loading the content.
 

Re: Quick Question-- prolly for Josh-

Expand Messages
  • Brat Wizard
    Hmm- looks like the answer is this-- perl maintains one @INC array per perl interpreter invocation, which normally is sufficient because each program run will
    Message 1 of 3 , Sep 5, 2002
      Hmm- looks like the answer is this-- perl maintains one @INC array per perl
      interpreter invocation, which normally is sufficient because each program run
      will load its own copy of the interpreter. However, under Apache/Mod_Perl,
      only one copy of the interpreter is running, and so each local path pushed
      onto the @INC array is shared between all the running scripts. What order is
      dependant on how apache loaded the virtual hosts, etc. So normally this would
      not be a problem but in the case of mod_perl it is.

      Now I know why its happening but I'm not sure what to do about it. Has this
      bitten anyone else?

      John



      On Thursday 05 September 2002 07:32 am, Brat Wizard spewed into the ether:
      > Hi there Josh (and everybody)
      >
      > I've got a strange problem--
      snip]
      > So the bottom line cause of my weirdness is that I'm loading up modules
      > (I'm guessing at random, or perhaps by @INC order, I'm not sure) from the
      > wrong code tree (library directory). And in my DEV version, which should be
      > using the NEW module under test, its ACTUALLY using the OLD version in
      > production. There is NO OTHER WAY to get the production module, and
      > printing out the @INC array confirms that both paths are in there.


      ---------------------------------------------------------------------
      To unsubscribe, e-mail: asp-unsubscribe@...
      For additional commands, e-mail: asp-help@...
    • Josh Chamas
      ... In order to support dev & production environment on the same hardware, I would run web servers on different ports. This way, no odd in memory data
      Message 2 of 3 , Sep 5, 2002
        Brat Wizard wrote:
        > Hmm- looks like the answer is this-- perl maintains one @INC array per perl
        > interpreter invocation, which normally is sufficient because each program run
        > will load its own copy of the interpreter. However, under Apache/Mod_Perl,
        > only one copy of the interpreter is running, and so each local path pushed
        > onto the @INC array is shared between all the running scripts. What order is
        > dependant on how apache loaded the virtual hosts, etc. So normally this would
        > not be a problem but in the case of mod_perl it is.
        >

        In order to support dev & production environment on the same hardware,
        I would run web servers on different ports. This way, no odd in memory
        data corruption ( like dev & prod perl library overlaps ) can occur.
        Because of mod_perl's persistent nature, anything bad in dev has a chance
        to escape to production, take as another example a global hash $Config
        that you define in a module namespace.

        So then I would run production web server on port 80, and a dev web server
        on some arbitrary high port like 8000. You could also use multiple IP
        aliases for a NIC & have apache bind to only one IP address on the card
        at a time per server, and do per IP web server instead of per port.

        If you really want to continue on your current path, you might look at
        Apache::PerlVINC, which was designed to overcome the direct problem you
        are talking about. The recommendation of the author of this module
        is to only use it in development, not production, at least because of
        performance issues.

        Regards,

        Josh
        ________________________________________________________________
        Josh Chamas, Founder phone:925-552-0128
        Chamas Enterprises Inc. http://www.chamas.com
        NodeWorks Link Checking http://www.nodeworks.com


        ---------------------------------------------------------------------
        To unsubscribe, e-mail: asp-unsubscribe@...
        For additional commands, e-mail: asp-help@...
      Your message has been successfully submitted and would be delivered to recipients shortly.