----- Original Message -----
From: "Rickard �berg" <[EMAIL PROTECTED]>
To: "jBoss Developer" <[EMAIL PROTECTED]>
Sent: Monday, October 09, 2000 10:34 PM
Subject: Re: [jBoss-Dev] Multiple jBoss Instances
> Hey
>
> Andy \"Mad\" Schaefer wrote:
> > As far as I remember multiple jBoss instances cannot use the
> > same JNDI instance and therefore you cannot run multiple
> > jBoss instances on the same computer.
> >
> > Is this planned for the near future to implement and how will
> > this influence the JNDI names for the JMX components?
>
> 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.
GREAT!
> 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).
The problem for JMX Connector is that you do not know from where the
administrator is located and therefore this can lead to a problem because
the JMX administrator should be able to lookup the different jBoss
instances.
Do you have an idea if this is a problem for the JMX Connector (client
side)?
Thanx - Mad Andy
>
> /Rickard
>
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
>