AsynchronousByteCharChannel and Timeouts

[Alan Bateman]

Gili wrote:
> :
> Here is a simple counter-example that comes to mind:
>
> write() to request a computation on the remote end
> read() with a timeout waiting for the result
> if a timeout occurs, write() telling the queue to abort the computation
>
> In the above case you could disconnect on timeout, reconnect and request an
> abort. Forcing a disconnect on a timeout is not the end of the world, but it
> seems like an unnecessary limitation. Instead of invalidating the channel,
> couldn't you have specified that in case of a timeout the API will return
> the number of bytes that were written by the underlying implementation
> (ideally zero) and leave it up to the user to decide if he wishes to
> disconnect or do something else?
>   
AsynchronousSocketChannel doesn't close the channel on timeout. Rather 
it just invokes the completion handler's failed method with the 
InterruptedByTimeoutException. In many cases the application will close 
the channel at this point because the peer is not responding and there 
is nothing it can do. The wording in the spec related to continued use 
of the channel is to deal with possible implementations where it is 
completely unfeasible to cancel an I/O operation and leave the 
connection and channel is a consistent state. For example, suppose an 
implementation is using blocking I/O then there may be thread blocked in 
read or write and no way to unblock it cleanly. Another example may be 
where it is possible to cancel an I/O but have no way to guarantee that 
bytes haven't been transferred in/out of the socket buffer. That would 
completely break stream communication and clearly this an area where 
serial port I/O will differ (because you are at lower level and I assume 
there is some protocol to over errors, right?. In other words, the 
protocol will recover from data loss and other protocol errors).

-Alan.