Async channels

[Alan Bateman]

Rémi Forax wrote:
> As a server developer; I prefer the semantics of 
> getSocketRemoteAddress() (as specified now)
> to the one specified for getRemoteAddress().
> At least half of the usages (and perhaps more) of getRemoteAddress() 
> will be for logging purpose,
> having the remote address persistent even if the channel is closed 
> seems important to me,
> for example, if you want to log that the channel is closed :)
Just so we're clear, this relates to the channel state (not the 
connection state). If the connection terminates or is closed by the peer 
then getRemoteAddress will continue to return the peer address until you 
close the channel. All I/O operations on channels throw 
ClosedChannelException is invoked on a closed channel. On a technical 
note, there are some operating systems where getpeername/equivalent 
fails once the connection has closed; ports to those platforms will have 
no choice but to attempt to retrieve (and cache) the peer information 
when the connection is established (or accepted). 

As to the logging case - if you asynchronously close a channel with 
outstanding I/O operations and the completion handler attempts to log 
information (that includes the peer address that is no longer valid) 
then handler will need code to deal with this case.


> Argh,
> I was hoping that SecurityException like any runtime exceptions is 
> thrown synchronously.
> I don't see why they have to be delayed.
> As a  developer,  runtime exception means  you don't correctly 
> understand the spec
> so they have to be thrown sooner  than later  (if possible).
The permission checks required to accept a connection or receive a 
datagram cannot be done at the time that the I/O operations are initiated.


> :
> I think I don't like the fact that runtime exceptions can be:
>  1) thrown by read/write/accept/connect or
>  2) catch by the completion handler
> without be able to understand/predict why.
The only runtime exception that the completion handler has to deal with 
is a SecurityManager and only then if there is a security manager and 
only for specific I/O operations.

> :
> Perhaps a test case is missing ?
Yes, the current tests don't check that you can continue to write after 
cancelling a read (and vis versa). I'll add these tests. Thanks again 
for finding this one.


> Taking an Executor an not a AsyncChannelGroup doesn't prevent sharing.
> Currently, you can write:
>
>    ExecutorService executor=Executors.newCachedThreadPool();
>    AsynchronousChannelGroup channelGroup = 
> AsynchronousChannelGroup.withThreadPool(executor);
>    AsynchronousServerSocketChannel serverSocketChannel = 
> AsynchronousServerSocketChannel.open(channelGroup);
>    AsynchronousFileChannel fileChannel = 
> AsynchronousFileChannel.open(path, openOptions, executor);
You could but this goes against the warning in the spec that the thread 
pool is intended to be used exclusively by the resulting group.

>
>
> Another questions, currently the linux code for asynchronous I/O is 
> based on poll
> like the selectors.
Linux is the one case where we use the same I/O facility as we do in the 
Selector. Selector uses is in simple level-triggered mode like poll. 
Asynchronous I/O uses it in one-shot mode. The useful thing about the 
new API is that is it mappable to broad range of I/O facilities.

> - On linux, is it more inetrresting to use async calls or selectors 
> beside the fact that
>   code with async calls seem simplier to write (at least to me) ?
Yes, the new API is easier but there are many things to size up (Reactor 
vs. Proactor design for example). Jean-Francois might want to jump in 
here as he has seeing better performance with his Grizzly port to the 
new API.

> - Is there a plan to use really async I/O on linux ?
If Linux were get such a facility then we would use it. In the interim 
we might port to Kevents if that goes into the kernel.

-Alan.