RE: ASP config + clustering
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 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 "name" > > attribute? > > > > > > after following a previous post, i can get the application.xml > > > > > 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 >> > > > >
Re: ASP config + clustering
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 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 "name" > attribute? > > > > after following a previous post, i can get the application.xml > > > 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 >> >
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 "name" attribute? > > after following a previous post, i can get the application.xml > 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 >>
ASP config + clustering
dear all, is there a way to get the server.xml defined "name" attribute? after following a previous post, i can get the application.xml 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.
