. (would it be
possible, on the client side, to have some kind of static information such
that if a router fails, all stub codes will automatically use the new one
without each trying the old one i.e. sharing "the good news" between all
stubs for a same target cluster i.e. target domain)
definitely. the client stub is created on the server through the home
interface.
it is very possible to send down the logic and information about the cluster
with that stub.
Filip
~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net
----- Original Message -----
From: "Sacha Labourey" <[EMAIL PROTECTED]>
To: "JBoss-Dev" <[EMAIL PROTECTED]>
Sent: Thursday, February 22, 2001 10:30 AM
Subject: RE: [jBoss-Dev] Article on clustering
> Hello,
>
> This is an interesting article.
>
> I share my idea/opinion, hoping not to be to far from reality...
>
> I think that most of the decisions about which target (i.e. server) an
> invocation should be done against, should be made as near as possible from
> the cluster (for performance, network throughput, ... reaons) by using, as
> said in the article, a kind of router (a "invocation-dispatcher") which
> would take the appropriate decisions.
>
> Nevertheless, without using some tricky OS-dependant software or quite
> expensive hardware, the router becomes a SPOF (single point of failure).
And
> we will not be able, in pure Java, to have some kind of IP-shared servers
> solution...
>
> Consquently, IMHO, the invocation-dispatcher (i.e. router) should make any
> load-balancing/failover decision as long as it is available and when it
> dies, the switch to another backup-router should be made by the client.
i.e.
> The client stub code has the list of all backup routers embedded in its
code
> and when it receives an invocation failure, it silently tries the other
> routers by re-launching the current method invocation. (would it be
> possible, on the client side, to have some kind of static information such
> that if a router fails, all stub codes will automatically use the new one
> without each trying the old one i.e. sharing "the good news" between all
> stubs for a same target cluster i.e. target domain)
>
> I think that the invocation-dispatcher solution has the advantage of
> allowing to develop quite sophisticated load-balancing/failover algorithms
> and to have a single point of decision. Nevertheless, it adds some delay
to
> the calls. Furthermore, a distributed election algorithm is most probably
> necessary in order to insure that only one invocation-router is the
master.
> This, for example, to be able to determine on which server is a particular
> entity bean.
>
> just my 0.002$
>
> Cheers,
>
>
> Sacha
>
>
>
> > -----Message d'origine-----
> > De : [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]De la part de Rickard Öberg
> > Envoyé : jeudi, 22 février 2001 13:44
> > À : jBoss Developer
> > Objet : [jBoss-Dev] Article on clustering
> >
> >
> > Hey
> >
> > You may want to read this:
> > http://www.onjava.com/pub/a/onjava/2000/12/15/ejb_clustering.html
> >
> > regards,
> > Rickard
> >
> > --
> > Rickard Öberg
> >
> > Email: [EMAIL PROTECTED]
> >
>
>
>
