Hi Gregg,
Gregg Wonderly wrote:
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.
Given you introduction of the invocation versus application layer and
you mentioning "Certainly having the invocation layer discuss
reachability between the two ends is helpful" I have a bit of a problem
with positioning (sorry, don't know of a less loaded word) your
viewpoint in whether SARE is useful or not, whether ping
is sufficient or not, or that you have something different in mind.
Due to the lack of being able to do the brain-melt I'm going to repeat
something you probably already are aware of. So just to be sure SARE, is
at the application level and not at the invocation layer level. It is
only that some frameworks might provide support for it so that a service
code doesn't need to take care of all the details and as such could be
seen as shielded from it, but nowhere did I intend to assume that it had
its place in the Jini ERI stack.
Can you also explain why you really have the need for an additional NIO
bases server client to test for reachability that can't be arranged for
by performing plain RMI calls with proper timeout constraints set. What
concerns me is that you have an additional network path which consumes
extra port, might need to be secured and the usual stuff as extra
configuration, routability, being able to proxy the traffic and firewall
traversal.
--
Mark
