Hello,
> My definition of application server clustering does not allow a
> situation as
> you just described Jeremy. The beans (actually the application) would be
> deployed to the "cluster" and not to any particular node (or nodes) in a
> cluster. On an implemenatation level, I would still expect all
> nodes to host
> all applications once deployed. This removes the possibility of any
> application being unavailable even though a cluster is atill active. This
> could happen if either node 1 or node 2 failed in your example.
You are right, we need to set some terminology. IMO, we should be able to
define a cluster has a set of Jboss instances (eg. A B C and D), we do not
care if they are located on the same machine or not i.e. we may have a
cluster of two instances running on the same machine. When we deploy an
application, we can decide on which node of the cluster it should be running
(A B only for example). In Borland tool, it is even possible to say, for
example, that Application A1 should be working on at least 2 nodes, starting
with nodes A and B but never on node D. Consequently, from the outside
world, the cluster is seen as a single entity, but from the inside, we can
decide what should run where.
> Also I believe we need to think about the jBoss clustering effort in the
> wider context of clustering complete J2EE applications. Perhaps I
> am missing
> something here but shouldn't think about how a cluster-capable
> jBoss affects
> jBoss-Tomcat and/or jBoss-Jetty and other such (aggregated) J2EE stacks?.
Yes, it is a good idea, we could then share the administration tool for the
presentation tier, but in fact, IMHO, this is not direclty related (but
could gain in performance if again integrated).
Cheers,
Sacha
