Musings on an Erlang GUI System.

Scott Lystig Fritchie fritchie@REDACTED
Wed Feb 19 06:05:51 CET 2003


>>>>> "lg" == Luke Gorrie <luke@REDACTED> writes:

lg> BTW, is there anything like process links and monitor_node in
lg> CORBA these days?

Not that I'm aware of.(*)  I'm neck-deep in IONA's C++ ORB
implementation.  It doesn't have stuff like that, because you (the
client) are not really supposed to know what's going on behind the
scenes: CORBA will take care of those mussy details for you.

The implementation gives us control over per-session-establishment
timeouts and per-call timeouts, but it's up to you to decide what to
do when CORBA throws an exception.  Typically it's re-resolve the
handle and then try again ... for some number of attempts.

The naming service is only as good as what feeds the naming service.
In the re-attempt loop I mentioned above, it's a good idea to
re-resolve the name, just in case the server moved.(**)

If the server dies & goes completely silent, you're at the mercy of
TCP to figure out that the server has died.  Unless your per-call
timeout fires first.

You could write your own transport help avoid many of these problems,
but rolling your own protocol is difficult to do, SCTP implementations
are still scarce, and using something like UNIX domain sockets doesn't
distribute your apps very far.

The fault-tolerant CORBA environments I've seen have components whose
sole job is to call CORBA-style ping methods (and occasionally
lower-level liveness tests) periodically to try to determine if things
are still up.  If they're dead, it's environment-specific how the
error is dealt with, a new service started, and the name service
updated before all the clients give up retrying.

-Scott

(*) I've done a lot of mucking with CORBA, both tweaking client-side
stubs (communication and marshalling) and server-side.  Fortunately
or not for me, I'm not as familiar with spiffy-new developments in
CORBA Land.  If I'm living in the CORBA stone age, I'd appreciate
a whack by the Cudgel of Enlightenment.  :-)

(**) It's my understanding that it's possible to use the same IOR
thingie to talk to a server that's moved to a different place, but
haven't a clue if that's really true.  All the IORs that I've seen
have hostnames (and perhaps even port numbers) hidden inside them.



More information about the erlang-questions mailing list