pas-dev

[Pas-dev] Run Mulitple Apps in the same Apache instance...

[Kyle R . B. <mo...@vo...>]

We're about to roll out another application built off of Pas where
I work.  Since the existing web-server isn't even close to running at
capacity, we'd like to install the new app on the same box.

The new applicaiton introduces a few new derived page objects and psp
pages to go with them.  Both applicaitons run from the same codebase.  
The remainder of the differences are just some configuration chagnes to 
the pas.conf file.

The only way I can see to do this right now is to set up a second instance
of apache driven off of slightly different configuation files that point
to the new codebase and configuration file.  Then this second instance
becomes the new app and the first instance continues to be the first app.
The problems with this are probably obvious - it's more work-load for the
box in question (double the number of apache instances) and it increaces
maintenence issues.  Plus, we'll probably have to set up three Apache
instances, where the first proxies to the other two based on the virtual
host settings.  This may be an unnecessarily complex setup.



What I'm interested in discussing at this point are the issues surrounding
attempting a multiple installation like this.  I think that given the 
current implemenation of some of the modules, and the convention of
using singeltons (either package my's, package our's, or variables
that are lexically captured closure style at compile-time) for some
code constructs (like the singelton configuration object) prevents
multiple applications from being hosted in the same process space.

Are there changes we can make to Pas to allow for this type of configuration?
Are they worh doing?  I'm not sure I know of any other application servers
that allow for multiple instances of the same codebase (multiple applications)
to be hosted in a single process space.

The issues I can identify are the following:

- Org::Bgw::Config uses a singelton pattern.  The singelton is at the 
  package level.  This means that you can't have multiple configurations
  loaded.  A requirement for multiple applicaitons.  An approach
  for solving this (and not incuring the performance hit of loading
  the configuration on every request) is not clear to me at this time.
- Org::Bgw::Environment pulls the location of the configuration from
  an environment variable.  This was originally done because it was
  portable beteween the mod_perl and standard CGI worlds.  If we gave
  in and just decided to support mod_perl, we could use a PerlVar 
  directive instead of SerEnv/PerlSetEnv.  PerlVar has the advantage
  that it can be localized to either an Apache Location configuration
  directive, or a Directory directive.  This would allow mutliple
  configurations, localized to an alias (in the case of a Location 
  directive), to be supported.
- Any singelton pattern must be reworked to include a parameter to
  identify the singelton to be retreived.  In the case of the configuraiton
  it might just be the full path and file name of the configuration file.
  Or we could introduce a new PerlVar that acts as this kind of switch.
  Perhaps we could just use the virtual-host's name?  That might be a good
  approach for solving alot of these issues.
- Developers would have to know the implications of using globals, static
  variables - singeltons by any other name.



Are there any other issues that anyone can think of?  Can we solve these
and host multiple apps in the same process space?

Beyond that, can we solve the ISP's delima?  So that mod_perl/Pas could
be used in a web-hosting type of environment where tens or hundreds of
seperate web-sites all run in the same suped-up Apache process?  Is
Apache2/mod_perl2 working on this problem?  To summarize, the problem
here is that the mod_perl namespace is shared - so if I set a variable
in my codebase $Foo::Bar, anyone else running in the same Apache instance
can access it (and worse, change it).


Kyle

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Pas-dev] Run Mulitple Apps in the same Apache instance...

[Mental P. <me...@ne...>]

On Thu, 2003-04-03 at 10:00, Kyle R . Burton wrote:
> - Org::Bgw::Config uses a singelton pattern.  The singelton is at the=20
>   package level.  This means that you can't have multiple configurations
>   loaded.  A requirement for multiple applicaitons.  An approach
>   for solving this (and not incuring the performance hit of loading
>   the configuration on every request) is not clear to me at this time.
> - Org::Bgw::Environment pulls the location of the configuration from
>   an environment variable.  This was originally done because it was
>   portable beteween the mod_perl and standard CGI worlds.  If we gave
>   in and just decided to support mod_perl, we could use a PerlVar=20
>   directive instead of SerEnv/PerlSetEnv.  PerlVar has the advantage
>   that it can be localized to either an Apache Location configuration
>   directive, or a Directory directive.  This would allow mutliple
>   configurations, localized to an alias (in the case of a Location=20
>   directive), to be supported.

I think we should stop trying to support CGI. Any sizable app that tries
to run in CGI mode is going to be very slow and non-scalable. This would
also open the door to us setting varabiles with perlsetvar as you
pointed out.

What if we subclassed the requesthandler on a per-application basis?
Register a uri /cust1 /cust2. Each one has a slightly different request
handler that is specific to their app. Can the request handler take a
parameter and deal with getting config pointed to the right place? Then
again, perlsetvar in a location block would do too.=20

=20
> - Any singelton pattern must be reworked to include a parameter to
>   identify the singelton to be retreived.  In the case of the configurait=
on
>   it might just be the full path and file name of the configuration file.
>   Or we could introduce a new PerlVar that acts as this kind of switch.
>   Perhaps we could just use the virtual-host's name?  That might be a goo=
d
>   approach for solving alot of these issues.

We could also look at using the uri. dev.domain.com/cookbook would be
different from dev.domain.com/icecastcontrol that way.=20

> - Developers would have to know the implications of using globals, static
>   variables - singeltons by any other name.
>=20

They sort of have to now, but yes. That would be an issue. Then again,
developers would be sharing pas/src, and still have their own pageobject
directory where singleton/static whatever wouldnt matter. This sort of
cames back to an idea I was kicking around about making the default page
psp's derive from easily configured/subclassed....=20



>=20
> Beyond that, can we solve the ISP's delima?  So that mod_perl/Pas could
> be used in a web-hosting type of environment where tens or hundreds of
> seperate web-sites all run in the same suped-up Apache process?  Is
> Apache2/mod_perl2 working on this problem?  To summarize, the problem
> here is that the mod_perl namespace is shared - so if I set a variable
> in my codebase $Foo::Bar, anyone else running in the same Apache instance
> can access it (and worse, change it).

Cant really speak to this. The solution is of course... colocation.
Beyond that, I cant think of a serious answer to this. I havent read
much on modperl for apache2 yet.=20


--=20
Mental (Me...@Ne...)

"Shouting at people who, for one reason or another, cannot hear you=20
is mentally-ill behavior -- or evidence of idiots in command."

--George Smith, a virus researcher and columnist for SecurityFocus.=20

CARPE NOCTEM, QUAM MINIMUM CREDULA POSTERO.

GPG public key: http://www.neverlight.com/pas/Mental.asc