Hi Jason
> > This leads me back to my proposal of generating a collective of servers
> > (yeah, your right, the BORG collective, because each server should know
> > the whole configuration allowing the collective to work even when a
> > member dies or is temporary unavailable IN CONTRAST to the
> > community of specialized servers like Master/Slave model) where JINI
> > build up the collective and JMX is the communication channel.
>
> I still think that it is a bad idea to have every node in a cluster to
have
> the complete configuration information for every other node. This simply
> will not scale.
You bring up also later but first let's talk about how much data each node
has
to manage and how often we expect that changes happend.
1) The actual size of the "default" configuration in the latest JBoss RH
release
is around: 141 KB
2) The number of changes except on startup are less than one per hour one a
very active system. Normally a J2EE server should serve and not change
all day long (sorry when I sound cynical).
Now, what do we have to send ? Whenever a changes is made to a server
(deploy a service, change a service, stop/destroy a service, deploy and
undeploy
an application) we only have to send what to do which is pretty simple.
Therefore
I don't expect to send much over the wire and also not much to be stored on
each server. Don't forget that any classes you have to send over the wire
has
to send anyway.
> If you have 10 nodes, change one bit of config on node0, then node2-9 will
> have to sync up there configuration. There will probably have to be some
> distributed tx going on here too so that we are sure that no new nodes
> startup and use a stale config.
You are saying that the problem of making the updates will not scale because
then the number of servers grows the whole thing would grow exponential
and not linear (as the number of servers does).
BUT I said the every should know every other server on the cluster but only
one send the update commands to the others. The actions a server has to be
able to perform:
- after a changes notify all other servers of this
- register itself as new server to the list
- unregister itself from the list
- check if its configuration is up to date against one other server
> Obviously you would want to segement large collections of nodes into
groups
> or clusters, but you may need to have a large group, which leaves you to
> artificially segment or look to an alternate solution.
Right now I only discuss this on a cluster level. The other scenario is to
have
a farm of servers running different applications but the same server
configurations.
I am not quite sure if this can be automated because some clients want
Oracle,
other PostgreSQL DB etc. You don't want to supply them with all the
available
service all other server has, don't you ?
> Another example would be DNS. There is no way that every DNS server could
> sync up with each other DNS server, unless there numbers were small and on
a
> fast network.
Yeah, but normally you have two doing the same, the configuration is a
nightmare
and most DNS server caches resolved mappings. You can run into serious
troubles
if the two of the top DNS server goes down or fails to serve or when someone
temper the DNS cache.
> I think that Jini could really help take JBoss to the next level if
applied
> thoughtfully. Perhaps simply for the lookup serivce (discovery & join),
> event model and leasing system. We would still use JMX for all local
> control, but add some Jini services, which link JMX agents together, allow
> them to notify each other when they go up, down, need config, have new
> configs. Leasing could be used to detect system locks and other fancy
> stuff.
Isn't this what I proposed initially ?
Andy
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
