Re: best practices for intermittent connectivity

Good questions John,

Once an OutputPipe is resolved, it is composed of a message queue (of 
50)  and an endpoint messenger, when a message is sent, it is inserted 
into the queue,  where a service thread then dequeues and send the 
message.  A false return value means that the output pipe failed to 
enqueue a message onto the queue within 250ms, a condition which occurs 
when sending messages in rapid succession, or messenger failure 
(explained, later).  The application should simply back off in such 
condition.

An OutputPipe may suffer from the following failures, and in most cases 
can recover without drastically affecting the application:

1- Physical endpoint failures. Due to physical endpoint changes (mobile 
devices,
    or virtual address change, etc.)
    This failure is addressed by the EndpointRouter resolution protocol, 
and
    the migration is transparent to the OutputPipe, and typically has no 
ill effect,
    unless the queue gets congested. In which case the application can 
detect this
    through the return value and back off.  This is referred to 
sometimes as
    "Peer Endpoint Migration"

2- Once the messenger has been determined defunct (i.e.. the 
EndpointRouter failed
    to repair the route), the PipeResolver is employed to resolve the 
pipe endpoint on another
    peer, if the resolver succeeds in resolving the pipe with the 
original timeout, dequeue of
    messages proceeds.  If the resolution fails, then the queue is 
closed an IOException is thrown
    when attempting to send messages. This is referred to as "Pipe 
Endpoint Migration"

So to answer your question, the application should check the send 
result, and back off when it should, and also trap the IOException and 
figure out how to recover.  Pipe endpoint migration assumes that more 
than one node is listening on the pipe. Also, keep in mind that pipe 
endpoint migration can not possibly occur if the output pipe was 
constructed with a specific peer, and the peer has failed, or ceased to 
exist.

Mohamed

-- 
http://blogs.sun.com/roller/page/hamada
http://weblogs.java.net/blog/hamada



John D. Blair wrote:

> In the JXTA application I am developing I have many peers which are 
> sending data to a smaller number of remote peers.  For any number of 
> reasons it is always possible that a remote peer will become 
> unreachable.  When a remote peer is unreachable the local peer should 
> find another peer that is reachable providing the same service, and 
> continue operation.
>
> My question is:
>
> Can somebody provide me with an example of how to discover that the 
> remote endpoint on a unicast pipe has become unreachable, and recover 
> from this?  I see from the documentation that OutputPipe.send() 
> returns a boolean that, if false, usually indicates there is 
> congestion and the peer should try again later.  How long should I 
> wait?  Should I implement an exponential backoff algorithm?  How many 
> times should I retry before giving up?  Is this actually a rare event 
> that I don't need to expend much effort on?  I can experiment, but I 
> am hoping to find some suggestions.
>
> Also, I see that OutputPipe.send() can throw IOException.  When this 
> is thrown does it always mean the remote peer has become unreachable, 
> or can it indicate other problems?  If I catch this exception, should 
> I close the pipe and try to open it again, and find another peer only 
> if that fails?  Or can I assume this means peer is gone?  Or should I 
> use some other means to probe if the peer is there?
>
> Or, better yet, am I missing some functionality in JXTA that will take 
> care of this for me?
>
> thanks much!
>  -john.
>
-- 
http://blogs.sun.com/roller/page/hamada
http://weblogs.java.net/blog/hamada