PLEASE NO PRIVATE STUFF ON THE ACTUAL DESIGN
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha
|Labourey
|Sent: Saturday, April 21, 2001 11:33 AM
|To: Jboss-Dev
|Subject: [JBoss-dev] TR: jBoss HA
|
|
|Hello,
|
|Here is a private thread that began between James Cook and myself
|about the design of the currently implemented HA features for
|SLSB. As we both think this thread may be of interest, I forward
|it to the JBoss-Dev ML. You'll find in attachment previous e-mails.
|
|Don't hesitate to share your ideas!
|
|Cheers,
|
|
|
| Sacha
|
|
|-----Message d'origine-----
|De : James Cook [mailto:[EMAIL PROTECTED]]
|Envoy� : samedi, 21 avril 2001 17:01
|� : Sacha Labourey
|Objet : RE: jBoss HA
|
|
|> 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.
|
|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.
|
|> As for the replicated naming service, I agree that it is not
|> mandatory but I do not think we can propose an HA implementation
|> with such a miss. Furthermore, it would improve efficiency: all
|> JBoss server would resolve through local lookups (and thus
|> "eliminate" network latency). And as the NS is the EJB entry
|> point, if you loose it, all your HA features go to trash unless
|> you restart it (or repair the computer, or...) Because client
|> nodes would only know the name of ONE naming server, it means
|> that moving this name server is not really trivial (it could yes,
|> but it means other complication I think)
|
|I agree that if a HA NS is created the stubs that are retrieved must be
|smart enough to know how to contact the next NS if the first one dies. I
|would like to hear some details about how this is accomplished.
|
|> > I'm not against a HA name service...I just think a load-balancing name
|> > service would be a higher priority.
|>
|> 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.
|
|> 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.
|
|> 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).
|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! ;-)
|
|
|> Please understand that this was also my first idea but that now,
|> I can't figure what would be the real advantage of this solution!
|> Also understand that I am not trying to blindly argue just to
|> save my design. I would be very happy to go in a better
|> direction, and this current discussion is very helpful but what
|> would help is a kind of list of pros/cons between both solutions
|> because I am not sure that the smart NS way is smarter/easier/...
|
|I think the summary should provide us with an opportunity to weigh these
|pros and cons. More discussion!
|
|> This is true for every imaginable solution: when everthing is
|> dead, we need to restart them automagically.
|
|I agree, but to emphasize a previous point, isn't Remote Object Activation
|be a single point of failure? :-)
|
|> > Actually, no commercial EJB implementation (AFAIK) supports serialized
|> > access to entity beans across VMs. They all enforce
|serialization at the
|> > database.
|>
|> But is this always possible? what about BMP? what about LDAP
|> based persistance for example?
|
|They do it. IMHO (and the opinion of these other vendors,
|weblogic, inprise,
|oracle), there is no widespread technique for synchronizing across VMs that
|outweighs the performance penalty of implementing it. Gemstone comes the
|closest with their PCA, but they still don't synchronize in the EJB
|container. They have just written a special database that locks across VMs.
|
|> 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 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.
|
|> BTW, what is your timezone? mine is CET (i.e. GMT+1 in winter and
|> GMT+2 in summer). If I know this, I can decide when it is a good
|> idea to answer quickly i.e. when you are probably on-line and not
|> deeply sleepling!
|
|I am GMT-5. I guess that puts me 7 hours behind you?
|
|> Don't you think that this discussion could be moved (now or
|> later) to the JBoss-dev ML?
|
|I think that this is a valuable thread. Sure.
|
|jim
|
|
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
