The master/slave bits that I went over are simply to move the problem of
starting up native processes up into the control of JBoss, rather than
relying on os dependent stuff.
Could you explain the architecture where masters > slaves?
--jason
On Thu, 6 Sep 2001, Julian Gosnell wrote:
> 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
