river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: SourceAliveRemoteEvent Part II
Date Mon, 04 Jun 2007 03:28:22 GMT
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

View raw message