|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder
|Sent: Tuesday, October 10, 2000 5:52 AM
|To: jBoss Developer
|Subject: Re: [jBoss-Dev] Multiple jBoss Instances
|
|
| I'm not a big fan of broadcasts for lookups. I once worked in an
|OS/2 and LAN Server environment, where the network was crippled for
|minutes at a time by broadcast storms. I guess we don't want to design
|our product around poor network implementations, but... Just please make
|sure to cache this information wherever possible to minimize the
|broadcasts.
| Also, this really can't be the only way - one of the apps I worked
|on was a big fat applet that talked directly to an EJB back end, and the
|client was most certainly on a different subnet. You can make
|broadcasting the *preferred* way, but not the *only* way.
one of the nice things with our current state of idea on the clustering is
that JINI buys us a lot of infrastructure (we can cache the stuff and the
networking is done by them). About the only thing that bothers me is the
"callbacks" in jini and in case of web clients directly talking it can be
heavy. However the feeling is right, also I expect to see more
"tomcat+jboss" in the embedded vision of our world (where RMI goes away
completely) than standalone "corba" like replacements, since the speed is
major enhancement and the threading is done by the webserver. In that
configuration the callbacks are low and inVM to the same stack... that could
work and scale nicely.
marc
|
|Thanks,
| Aaron
|
|On Tue, 10 Oct 2000, Rickard [iso-8859-1] �berg wrote:
|> I am planning to update jBoss for clustering shortly. The first part to
|> be reimplemented is the JNDI naming system. It will use Jini, and thus
|> will have no problem with running several instances for the same
|> namespace. This will be one of the central parts of the new clustering
|> system.
|>
|> Basically all JNDI service providers will be registered in a Jini Lookup
|> Service, and associated with a cluster name. The client will set the
|> PROVIDER_URL to the cluster name (not host/port!) and the client
|> implementation of the JNDI provider will then look in Jini for all
|> available provides for that cluster. Because of this there is no need
|> for the JNDI server to run on a particular port, so there will be no
|> clashes between multiple instances on the same machine. It also means
|> that clients will not have to know any host names of the cluster nodes,
|> just the !cluster name!, which allows for a "zero admin solution"(tm).
|> You can add nodes at runtime which simply registers in Jini and become
|> available to the client.
|>
|> The drawback of this solution is that the client and server has to be on
|> the same subnet (because Jini uses multicast for lookup). This will not
|> be a big problem in most cases since the most common case is to use a
|> webserver as client, which almost always is on the same subnet. If
|> anyone objects to this assessment, please let me know and I will take
|> into account clients on different subnets (Jini can work in this case
|> too, but not as dynamic).
|>
|> /Rickard
|>
|>
|
|
|
