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
