forax at univ-mlv.fr
Tue Apr 21 14:04:49 PDT 2009
Alan Bateman a écrit :
> 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).
That why I prefer the semantics of getSocketRemoteAddress(), because you
this is just a getter without native calls behind.
Anyway, you're the boss.
> 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
>> 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.
Ok, so the doc for completion handler can be enhanced to says that the
Throwable (why not use Exception instead, btw)
is the common super type of IOException and SecurityException.
>> 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
I have crawle the doc of epoll: one-shot mode is a special case of
edge-trigger mode, so it's not the
same mechanism that the one use to implement selector but it use epoll too.
>> - 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).
The devil is in the details...
> Jean-Francois might want to jump in here as he has seeing better
> performance with his Grizzly port to the new API.
I think I can wait the PDF of the JavaOne presentation :)
>> - 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.
Crawling the web, I have found that Kevents dev was closed,
without a replacement of the mechanism to get AIO notification :)
More information about the nio-dev