Dan Creswell wrote:
I agree ping can be misleading but I don't see how SARE really helps - the absence of a SARE arriving leaves you wondering what exactly happened. Did you get overloaded, did you lose an event, did the server fail? It seems to me SARE is a hint just as the results of a ping are a hint just as the timeout due to lack of arriving events that drives the need to ping is a hint.
One the things about TCP that I've learned to deal with in different ways, is the fact that if you don't have keep alive in place, you really have to have both ends sending stuff to make the retry timers eventually report a disconnect. Otherwise, the receiving end will just block on a read forever. So, if you can turn on keep alive on the endpoint, thats useful. If the endpoint is not TCP based, but is just a serial cable or some other interface, without TCP and keep alive available, then your invocation layer, or application layer has to do the reachability test.
I've basically learned that if I want something like this to be part of the application, then it needs to be near the application layer, away from the pluggable parts such as JERI provides.
I have an NIO based client and server class that we use for reachability (not liveness of a particular application, invocation point) of hosts when we have larger fanouts and interdependencies.
There are lots of ways to do this type of thing. I believe that we really should look to see if there isn't a common behavior that we can include a pattern/some code to support. Certainly having the invocation layer discuss reachability between the two ends is helpful, but at what point do you "complain" about it, and how do you complain, if this is going on asynchronously for a listener kind of notification mechanism.
Gregg Wonderly
