i.e. Abstract out the Master/Slave components and put one of each on each node,
instead.
If you did this cleverly you would be able to deploy either architecture or
combinations with e.g. 3 masters and n-slaves, or you could even copy your
architecture from a place at which I worked, where the Masters outnumber the
Slaves !
Jules
Andreas Schaefer wrote:
> I am not quite sure if this is the way to go.
>
> You are starting with the master and then the slave hook up
> to this master (more ore less you create an administration
> server).
>
> When the master is going down the slaves run on their own
> and become zombies because all the configurations are on
> the master.
>
> My idea is that every server contains the configurations and
> the changes are propagated on all the other servers in the
> group. This would allow an administrator to pick up any
> server and able to manage the whole group. When any server
> goes down all the other server knows each others and can
> still propagate the changes and when a new server joins the
> group it can take the configuration from any other server
> and deploy the services and applications.
>
> Andy
>
> ----- Original Message -----
> From: "Jason Dillon" <[EMAIL PROTECTED]>
> To: "Andreas Schaefer" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 05, 2001 2:12 PM
> Subject: Re: [JBoss-dev] RH: EAR/WAR/EJB-JAR distribution...? - rambling !
>
> > > > |I'm assuming that in a JBoss cluster Enterprise
> > > > |Applications are distributed from one node (possibly a
> > > > |Master) to all other nodes (possibly Slaves).
> > >
> > > I think to have a master which propagates the actions to
> > > the slaves is difficult when it comes to fail-over. It would
> > > be nice if the client doesn't know anything about a master
> > > but the logical server or view on top of the group of
> > > physical servers.
> >
> > I don't know if this master/slave stuff spawned from something I said, if
> so
> > I want to clearify what I was talking about. If not, well then, here it
> is
> > anyways =)
> >
> > When I was talking about master/slave, the master would trully be a dumb
> > server, which had the sole responsiblity for starting up slave nodes,
> > cycling them when they wedged, responing them when the jvm crashed and so
> > on.
> >
> > The slave node in this view would be configured to run your application
> > services. In a simple case, there would only be one slave for a master.
> > The master would simply startup, then spawn the slave, watch for it to
> exit
> > (as well as listen for lifecycle JMX events) and not really do more than
> > that.
> >
> > By adding this small piece of architecture to the system, we can write
> > applications that can replicate there environment automatically for fail
> > over, provide a sandbox environment for applications that might run native
> > libraries or be prone to sucking up memory with out endangering other
> > critical services that must be runnining on the same machine.
> >
> > I think this will be important when it comes to really distributed uses of
> > jboss in a mission critial application. Now that the configuration of the
> > server can be loaded from a URL, the task of startup up new nodes is
> simply,
> > looking up the URL to use. On boot, the task is simply looking up the
> list
> > of URLs to load, then starting a JBoss slave node for each.
> >
> > To make somthing like this work, you need a configuration server, which is
> > simply a JBoss node which is booted off of a file:// url, runs a web
> server
> > and has some .jsp's which server up configurations to other nodes.
> >
> > A master node running on each machine, probably started up vi /etc/init.d/
> > or the equivilent on other operating systems. It is also a simple JBoss
> > node, which pulls its config from http://configserver/master/ (perhaps
> with
> > hostname, os and other params attached so the .jsp under master can dish
> out
> > the correct config.
> >
> > The slaves looks mostly the same, the master looks up the url, which is
> > probably http://configserver/slave/ (with the same os, arch, other fluff).
> >
> > If jini was used, then the act of finding the configserver could be more
> > dynamic too.
> >
> > Doing something like this should be fairly simply too, the only hard bit
> is
> > forking the master node and watching slave children. Java has some
> > primitives to do this, but it could be abstracted out to an interface to
> > allow native impls, which are more effective to be used in its place where
> > available.
> >
> > --jason
> >
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
