On Wed, 2009-11-18 at 17:23 -0500, Alan Conway wrote: > ... > Good ideas here. To bring it together, how about this: > > There are 2 kinds of broker process: > - Service brokers serve clients, they never give updates. > - Update brokers give updates, they never serve clients. > > We create them automatically in pairs: a service broker forks an update > broker > and restarts it if it dies. The update broker never accepts connections and > is > not advertised to clients for failover. > > So the 3 cases are now > - new member joining/getting update: rejected (with exception) until ready. > - established member giving update, new client: never happens. > - established member giving update, connected client: never happens. > > We could further constrain things and say a service broker can *only* get an > update from its own update broker (once the update broker is up to date). The > advantage is they'll be on the same host so less network traffic, the > disadvantage is they can't update in parallel if there are multiple update > brokers available. > > Does that address all the issues? There is some extra complexity in having 2 > processes per broker, but for the moment I can't see any insurmountable > hurdles. > The nice thing is that we can do this with 0 new configuration so it will > Just > Work when its installed.
The main problem I can see here is that of introducing new points of failure, but I guess it's a little unavoidable. The other small issue is the process restarting logic - in many ways this is duplicative of the functionality of init etc. and is also fiddly and hard to get right the first time you do it. Perhaps we can use the existing system capability to do this. Andrew --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
