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

Quick Question-- prolly for Josh-

Expand Messages
  • Brat Wizard
    Hi there Josh (and everybody) I ve got a strange problem-- I ve just tracked down what s causing it (and given enough time, I ll figure out the solution) but I
    Message 1 of 3 , Sep 5, 2002
    • 0 Attachment
      Hi there Josh (and everybody)

      I've got a strange problem-- I've just tracked down what's causing it (and
      given enough time, I'll figure out the solution) but I was hoping that
      perhaps someone else had run into it before and might have a quick answer...

      I have some commercial software I've written for a client (storefront
      software) and it is in early production now so I'm having to do dev work in a
      copy of the software tree..

      To explain my setup a little better, I have one _whole_ domain dedicated to
      the production side and another whole domain dedicated to the dev side.

      Production gets domain #1 and its own apache virtual config. In the config I
      set all the variables (I think I'm okay there) and preload all the code and
      modules. No problem there either. The code and modules are located in their
      _own_ directory completely separate from the dev version.

      Dev side gets domain #2 and its own virtual config. Again, all config vars
      seem to be okay and preload code and modules. So far so good. The code and
      modules are likewise located in their own directory tree which mirrors the
      production tree except for the base dir and of course any changes in the code
      that are newer than the production code.

      Okay, everything was working swimmingly and seemingly like it should when I
      noticed a tiny glitch. As things often go, in tracking down the glitch I
      discovered a weak area of my code that needed some significant revisions. No
      problem there, the revisions work, I'm cool with that part-- but when I go to
      test them out live in the dev server, I get really weird squirrely results.
      The exercisers run the modules flawlessly so I know its not the modules
      themselves..

      Some sleuthing reveals a problem with @INC... BOTH the production AND
      development libraries are somehow winding up in the @INC array-- I'm puzzled
      at how this is happening as both of the virtual configs only set their own
      respective library directories and there is NO crossover between the code
      other than the common Apache web server.

      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.

      I remember Josh saying something about this awhile back but I can't find the
      message...

      Any suggestions?

      fwiw, here is the @INC array. The two paths in question are
      "/web/asp/impact/lib" and "/web/asp/stores/lib".

      .
      /usr/lib/perl5/5.6.1
      /usr/lib/perl5/5.6.1/i686-linux
      /usr/lib/perl5/site_perl
      /usr/lib/perl5/site_perl/5.6.0
      /usr/lib/perl5/site_perl/5.6.1
      /usr/lib/perl5/site_perl/5.6.1/
      /usr/lib/perl5/site_perl/5.6.1//i686-linux
      /usr/lib/perl5/site_perl/5.6.1/i686-linux
      /usr/local/apache/
      /usr/local/apache/lib/perl
      /web/asp/impact/lib
      /web/asp/stores/lib

      ---------------------------------------------------------------------
      To unsubscribe, e-mail: asp-unsubscribe@...
      For additional commands, e-mail: asp-help@...
    • 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 2 of 3 , Sep 5, 2002
      • 0 Attachment
        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 3 of 3 , Sep 5, 2002
        • 0 Attachment
          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.