Here is my 2 cents on the clustering issue...

While I am no expert in the area, I have been really impressed with how
Gemstone does clustering, and their use of multiple VMs in each cluster. It
seems, to put it simply, that most servers just allow you to run many
instances on either one machine or many machines and tie them all together
to form a cluster, much like webservers and such cluster. One thing Gemstone
did was allow on instance of Gemstone to run many VMs, and allow different
settings per VM; heap size, life time, # of clients per VM, classpath, etc
etc. It will spawn new VMs as needed and kill VMs as needed as well.

Maybe this is overkill, as it seems that most places run one big app in one
server, but where I worked, we wanted to run many apps in one server, and
having them partitioned with their own pool of VMs was a really nice
feature. They had some nice tools written in Tcl that showed the differences
in response times, memory, etc when using different configurations on the
how the VMs were setup. An admin dream (I would think...)

If JBoss had something half as cool as that, it would help (I think)
seperate it from the rest of the pack, instead of the "me too" when it comes
to having clustering like BEA or WebSphere, etc.

Any thoughts on this pertaining to JBoss?

Robert
[EMAIL PROTECTED]


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Filip Hanik
Sent: Friday, January 12, 2001 1:27 PM
To: jBoss Developer
Subject: [jBoss-Dev] Clustering


Marc,
I read the bugzilla note on clustering.
the "herd", "shepard", "sheep" and "food" paradigms.
in my humble opinion the herd,shepard etc words makes the document extremely
hard to read.
because I kept forgetting what they all meant. "Animals hunting for land" is
not an intuitive language, :) (no harm intended)

This document is based on a component called the cluster manager (CM).
and it says in the docs that "if the CM dies, the cluster vanishes".
doesn't this create the same "single-point-of failure" that Gemstone had in
their server a couple of years ago?

It would be nicer if any server in the cluster could act as the cluster
manager, and if one server dies, another server can assume the same
responsibilities and carry the cluster from that point. When the original CM
comes up again, it should become secondary CM and be ready to take over the
CM responsibilities at any point.

Am I making any sense or is it all jibberish?

Filip


Filip Hanik
Technical Architect
Pakana Corporation
[EMAIL PROTECTED]
415-371 9200 ext 3529

"Windows is a 32 bit patch to a 16 bit GUI based on a 8 bit operating system
written for a 4 bit processor by a 2 bit company which can not stand 1 bit
of competition."




Reply via email to