> > |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
