Tom Hobbs wrote:
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 is certainly interesting. It would only work when one has only one
remote reference in memory, would it? I mean, if you lookup the main
service object and via a remote call it returns some other remote
reference, and you lose contact, how would it recover? Or is the
intention only to iterate over multiple instances of one service during
setup?
It is certainly something what starts to be a recurring theme (for me),
a soon as you start to offer a more complex service, how do you handle
errors? It looks to me, that the client is totally responsible for
recovery, and that all of jini is built with this premise. All the
recovery you get at the moment is the TCP retry mechanism. But if a
laptop resumes from a suspend and gets a new IP address via DHCP an
error is thrown back to the client (user).
Currently i have some recovery built into our 'rpc/ip through http
tunnel', but this covers only transport errors. No recovery to fix
disappearing individual service instances in a redundant cluster.
I wonder if it was the intention by 'the elders' that we go back to the
lookup service, and try to find a service again. I'm not sure if we can
hide this recovery in a serviceproxy. Any ideas?
Gr. Sim
