Greg
Maybe I do not understand fully what you want to do.
When you store all application specific stuff and that file service dies
your systems dies. Would that be a problem for you?
Anyway if you store all settings in one place you can make those files
available in many places by using NFS or SMB. A sort of
write-once-read-many.
The advantage of using http://www.host.com/client as an entry is that the user
specifies where he wants to go.
FE
On Thursday, March 22, 2001 11:54 PM, Greg Matthews [SMTP:[EMAIL PROTECTED]] wrote:
that's fine except if you need to run 2 or more boxes to
handle the load.
i want a single copy of the application specific config files
shared by each clustered orion box.
i also want to be able to programmatically determine where
the config files are.
if each orion box in the cluster knows that the root config
directory is \\configmachine\configs\ then i can append
say, the application name, to this to get a config directory.
e.g. \\configmachine\configs\client1\config.xml for client 1
\\configmachine\configs\client2\config.xml for client 2
i can then change the application specific config details in a
single place for client 1, and all of client 1's clustered application
copies running across various boxes get the new information.
the question is, where do i get "client1" or "client2" when building
the path?
the best i've been able to do is follow a previous post and get
the application.xml defined display-name value, which doesn't
really solve the problem because that's included in the .ear file.
i was hoping to be able to programmatically determine the
server.xml defined application name and use that to build
the path.
greg.
- Original Message -
From: "Frank Eggink" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Thursday, March 22, 2001 7:03 PM
Subject: RE: ASP config + clustering
Greg,
Why run an instance of orion per client you are serving? I'm looking to
host an applications for a number of clients too, but I'm looking into
another route.
We plan to 'copy' the applications and run them from one server-instance.
Guess for resource usage we are better off, just copying the applications
and have your clients served by one orion instance. Clients would connect
like //www.host.com/clientname/ or something like that.
Additionally you can (on UNIX/LINUX) soft-link the original
application.ear
instead of copying it.
As long as you write the apps for the server, things should be secure in
this setup.
FE
On Thursday, March 22, 2001 1:45 AM, Greg Matthews
[SMTP:[EMAIL PROTECTED]] wrote:
dear all,
is there a way to get the server.xml defined application "name"
attribute?
after following a previous post, i can get the application.xml
display-name
value but this is not quite what i need.
the plan is to be able to deploy multiple copies of the same application
for different clients, and have an initServlet read in the application
name
to determine where the config files live.
e.g. client1 = read in \\someMachine\config\client1\config.xml
client2 = read in \\someMachine\config\client2\config.xml
this way, if i have to cluster client1, then there's only ever a single
copy of their config information on the network and i don't have to
duplicate it per orion installation.
i'm also thinking of putting the web-site.xml files for each client
in their own config directory to further reduce duplication of
config details that would appear if you do clustering.
i'd also like to avoid having to alter servlet initialisation parameters
or anything in application.xml when deploying the app for a new
client, but would consider these as a last resort.
thanks,
greg.
File: ATT5.html
