Hello James,
> > There's one thing I do not understand:
> > 1) either people use "our" NS implementation
> > 2) or people use "their own" NS implementation (sexy LDAP
> > implementation)
>
> To achieve the LB features, jBoss will have to bind to our NS. Our NS can
> have the option of being persisted to any number of backends,
> preferably via
> the JNDI interface. This would include LDAP.
? Yes but the "JBoss-NS" would include some specific logic that wouldn't be part of
the backend LDAP and thus this last would be of no use for EJB clients directly using
it.
> This backend persistence is also what buys you the failover without
> resorting to the network synchronization tactics. The same way that no one
> synchronizes EJBs across VMs...they rely on the database. It always come
> down to a single point of failure/synchronization.
...
> > Yes, but the HA name service will provide LB. First because each
> > client can connect to a different NS and second because when the
> > client downloads the remote+home proxy, the load-balancing
> > features is already in.
> >
> > Am I missing something?
>
> I don't think you are missing anything :-) I was referring to LB among the
> jBoss servers and not the NS, that's all. The NS simply doles out
> a proxy to
> the client. After that, the client will have no need to contact this NS
> unless the proxy loses connection with the jBoss server.
In the current state, if the proxy loses connection with the jBoss server, the proxy
automatically tries a new one and (can) even try to refresh its nodes list from any
running server (to take in account newly started nodes for example). LB is also in.
These features are, BTW, independant of any NS implementation scheme (because it is
part of the proxy).
> > Yes, but you could imagine the client to connect to this name
> > service and asks for a list of other available NS. We could also
> > imagine to have a list of hosts instead of a single host in the
> > property. This would change from the "standard" but could be
> > easily done. In any cases, there is some kind of specific action
> > to take to bind a JNDI provider to a client (such as setting the
> > good class provider for example.)
>
> Actually I don't think this approach will work. The client must be able to
> discover the available NS on demand to achieve the level of HA that you
> want. A list of NS at the time the proxy is generated is not sufficient. I
> don't know how this can be done without some UDP broadcast, but we talked
> earlier about its limitations.
That's right. This was just a way to "accelerate" the discovery (i.e. a first method
attempt). Second possibilities could be broadcasts, multicast, usage of specific DNS
entries, ...
> > To be frank, I do not see (appart from location consideration)
> > the real difference/gain between having a smart NS allowing
> > multiple objects per name and a simple NS where you bind smart
> > stubs. In both cases, you will need to have smart stubs => your
> > container, when creating the stubs, will need to obtain the
> > knowledge about other nodes and fill this smart stub with
> > appropriate data.
>
> I'll summarize how I would like to see HA be implemented. First of all, a
> service is added to the container to replace the current Local NS (LNS).
OK, so you have a LNS and a GNS.
> This service has knowledge where the Global NS (GNS) is located. When the
> LNS is started/stopped it notifies the GNS. As objects are bound/unbound
> from the LNS, the GNS is notified and mirrors the actions.
>
> When the jBoss server requires an object from the LNS, it always
> checks its
> own list first. If the object is found it returns it, and if not, it
> delegates to the GNS.
>
> The GNS is backed by some permanent JNDI service. This can be any of the
> SPIs supported by JNSI such as file store (the default), or database or
> LDAP, etc. This way, if the GNS goes down and is restarted, all of the
> information is current. At least after some sort of synchronization takes
> place. The GNS will have to contact the LNS for a bulk update perhaps. Not
> actually transmitting new proxies, but just checking to see if they are
> alive.
>
> When the GNS receives a request to bind an object, it stores it. More than
> one object may be bound under the same name. (Note that the LNS does not
> need this feature and the existing jBoss NS could be used with some small
> mods.) When a request for an object is received, the GNS consults its LB
> algorithm to decide which stub goes. This algorithm will default to a
> round-robin, however more sophisticated techniques are possible. The LNS
> could be equipped with their own pluggable module that reports
> system usage
> or number of beans used, or other metrics. The GNS could expose these
> methods and facilitate the call to the LNS on behalf of the LB plugin.
>
> The client would have knowledge of the GNS. At this point, I only
> see how a
> single GNS is possible, although there is nothing in the above design that
> prevents a HA implementation. It would simply consist of
> additional GNS and
> a smarter client proxy.
>
> I just debate the benefit versus the complexity. There are many single
> points of failure in any system. I believe the simplicity of a single GNS,
> and one that can be auto-started will be an immediate win. I
> sincerely look
> forward to seeing a HA implementation as well, but I would like
> to see it as
> an enhancement to this base design. That is....if the base design makes
> sense! ;-)
Yes but I still think that :
- the LB algorithm is only moved from the proxy to the NS
- a list of targets is always necessary in the proxy to provide failover
- to create this list of target in the proxy means that the creator of the
proxy (the container in our case) needs to know the cluster participant anyway (yes we
could also imagine that the proxy would answer to a particular interface and that the
NS feed it directly)
- having one NS node (forming a HA NS) on each JBoss computer is not less
secure than having a super strong JNDI server because when all NS HA nodes die would
also means that all JBoss instances are dead (yes... I am cheating a bit here... ;) )
> > Please, provide me with "use-cases" where you would have a real
> > benefit. The smart NS will need to deal with exactly the same
> > issues that the HAConfigService solves today with JavaGroups but
> > instead of having this logic in the NS directly, it is a distinct
> > service launched with JBoss.
>
> I understand that both implementations are similar conceptually,
> and you are
> right to question the differences. I am not that familiar with the
> HAConfigService so I can't speak to exact differences in the
> approaches. You
> have basically created a cluster of LNS, whereas I am advocating a central
> GNS. Sounds like the traditional master server versus
> peer-to-peer. I guess
> I will lose from a marketing standpoint. P2P is too hot! :-)
I am maybe a marketing victim then ;) Any other opinion around here ;)
> I suppose that I advocate the GNS approach because of the simplicity it
> affords the clients. I would also guess that it has a performance edge,
> although I don't know enough about your implementation.
Yes but this simplicity has a cost: single-point-of-failure. ;)
I will try to draw some diagrams to see the true differences ;)
Cheers,
Sacha
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
