Hi Chris, That's an interesting approach and one that avoids the single point of failure that the similar approach I've encountered introduces....
1. When a Service starts is checks to see if there is a Primary service of the same type running 2. If so, it makes itself as Secondary and keep pinging the primary waiting for it to die 3. On a Primary's death (or when there are no primaries), all the secondaries of that type hold a vote and one of them gets promoted. The rest revert back to Secondary. Clients still search for and use the Primary service only. In the specific example I was involved with, there was a known good Java Space where voting happened. The Good: 1. In addition to Chris' 2. No need for intercommunication other than pinging the primary The Bad: 1. In addition to Chris' 2. The one good known Java Space for voting in is a single point of failure* * The assumption that was made in our scenario was that Jini (or River) "core" implementations were far less likely to unexpectedly disappear than 'normal' business services. We could therefore assume that once one was started on the subnet it would "always" be available. In reality, this single point of failure never actually manifested itself as an issue. Yes, on a complete system restart we might forget to start this Java Space before the Primary/Secondary services, but with appropriate logging the situation is easy to diagnose. Day-to-day this Java Space (Outrigger) behaved itself very well and didn't go away when we didn't want it to. Also, this specific Java Space was never used by the rest of the system for anything other than voting. What is the purpose of "IRedundantService". Surely "IFooService" could just join the groups of all the other "IFooService" services? Interesting none the less though. Thanks for sharing. Tom On Tue, Feb 16, 2010 at 4:26 PM, Christopher Dolan < [email protected]> wrote: > Tom's technique below is nice for automatic failover. Just for a point > of reference, I'll describe the hot-standby approach we've taken at > Avid. > > * Declare that your IFooService is an IRedundantService > * The IFooService instances in the group discover each other and hold > an election > * The winner calls joinMgr.modifyAttributes() to mark itself as primary > * The IFooService instances ping each other and if any one stops > responding, another election is triggered > * Clients search for the IFooService that is marked primary=true and > talk only to it > > Limitations of this approach: > * need for IFooService instances to inter-communicate > * moments during election when there is no primary > * rare partial-disconnect conditions where you get two primaries > > Wins of this approach: > * election protocol is entirely up to the IFooServices, no client logic > except to trust the Entry that says primary=true > * only one primary at a time > * the IFooService instances are already in contact, so adding state > synchronization requires little extra infrastructure > > Good-and-bad aspects: > * clients can decide how to handle the no-primary case themselves. > More code, but more control too. > > > I'd love to hear comments/criticisms of our approach, and if anyone has > implemented something similar. > > Chris > > -----Original Message----- > From: Tom Hobbs [mailto:[email protected]] > Sent: Tuesday, February 09, 2010 4:21 AM > To: [email protected] > Subject: Service Wrapper Example > > Hi, > > I mentioned in another thread that I had come across code which provides > service fail over and auto-rediscovery. I've posted details of the kind > of > code that was used to (note this has been reinvented in my head just now > and > only loosely tested); > > http://wiki.apache.org/river/AutomaticServiceReplacement > > I hope that someone finds it useful and/or interesting. > > It's important to note that in the interests of simplicity the > ServiceWrapper class in the article is explicitly linked to the dummy > service described. Obviously using more reflection magic it's possible > to > remove this linkage so that ServiceWrapper can wrap any service you like > and > it's invoke method would invoke the method supplied to it, rather than > the > only method available in the dummy article. > > Thanks to Jukka for his Wiki account suggestion. > > Enjoy, > > Tom >
