Just as an info: (that most of you probably know anyway.... & I posted it in
users)
The whole J2EE Architecture is moving towards CORBA. This would give us some
nice synergy effects, using such CORBA as the clustering framework.
Stefan
-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im Auftrag von Sacha Labourey
Gesendet: Mittwoch, 7. März 2001 12:35
An: JBoss-Dev
Betreff: RE: [jBoss-Dev] CL: Clustering, let's get started
Hello,
just some ideas to start a discussion...
As said in a precedent post, administration tools will be very important in
the clustering and they may also help, during the design phase, to see (as a
kind of "use cases") what features the clustering should provide.
I do not know much about WL, but have you checked Borland Appcenter tool?
http://www.borland.com/appcenter/ It gives some nice ideas.
Some general issues I have thought of:
- should be clustering stuff be available to Java-RMI only
clients or to all clients? If we want it to be available
to all clients, we cannot rely on specific smart code (i.e. algo)
in the dynamic stubs but instead need to have the logic
on "the server side" (or approaching) and use some more
standard principles such as IIOP multiple profiles IOR on
the client side. We may also have a mix of solutions.
- I suggest to have a (as someone mentioned earlier) a fault
tolerant CORBA Naming Service able to store more than one
reference for a particular binding. These extended binding features
would be provided as extension of the basic IDL CORBA NS, thus
allowing
standard NS clients to get an appropriate IOR (selected by a
pluggable
algorithm)
see next point for an implementation helper
- it may be very interesting to keep an eye on JavaGroups
(http://sourceforge.net/projects/javagroups), an open source project
which
may
be of interest to provide the basic layer for group communication
(sychrnonous view, group multicast, ...)
It could be for example used to have the NS implementation (see
point
above) completely
redundant and not using some kind of master-slave design where only
one
server
can, at a time, receive write invocations
The general idea would be to have load-balancing at the session level: the
client connect to the NS and get a reference to its target (bean). As many
containers may be bound to the same NS name, a pluggable algorithm in the NS
would decide which particular container it wants the client to use (=>
load-balancing). Furthermore, in the case of IIOP, it may add some other
profiles to other containers in the IOR to provide fail-over feature. In the
case of RMI-Java client, the provided stub may contain the failover logic
itself.
If the client invocation fails because its server becomes corrupted, the
client mechanism will automagically retry a new invocation. Thanks to the
multi-profile IOR for IIOP and to the smart stub for Java-RMI.
If a server is too busy to serve a request, it may send back a
LOCATION_FORWARD IIOP message to the client (thus really helping the server
to lower its load but creating a new consumming client-server network
round-trip) or itself forward the request to another server in the cluster
and act as a proxy.
It is evident that all these ideas are just very general idea to "activate
the pump" and concerns such as bean kind (entity, SFSB, SLSB), transactions
consistency during failover, solving dependant object aliasing issue for EJB
2.0 entity beans, ... are not taken in consideration.
Cheers,
Sacha
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de marc fleury
> Envoyé : mercredi, 7 mars 2001 01:27
> À : jBoss Developer
> Objet : [jBoss-Dev] CL: Clustering, let's get started
>
>
> Ok, it's been promised, it's been discussed, it has already
> started, it is
> really wanted.
>
> Also it will put JBoss on the map for ever...
>
> The clustering.
>
> I would like to "officially" call the season for clustering "open".
>
> There have been some discussions already some public some private and I
> believe we should really take this take by step. So we won't
> shoot for the
> stars in the very beginning, just something simple.
>
> I will assume the interim leadership for the implementation since there is
> no clear lead yet and the team is yet to form. I invite all of you that
> have touched the subject to publicly post and explain your view.
>
> STEP ONE:
> -Start 2 servers do "round robin" on STATELESS SESSION.
>
> Simple right? That will be some work
>
> go!
>
> marc
>
> _________________
> Marc Fleury, Ph.D
> [EMAIL PROTECTED]
> _________________
>
>
>
