Alan.Bateman at Sun.COM
Mon Apr 20 05:06:07 PDT 2009
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.
> 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 =
> AsynchronousServerSocketChannel serverSocketChannel =
> 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
> - 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.
More information about the nio-dev