Async channels

[Rémi Forax]

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 
know that
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.
>
>
>> 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.
Ok. 
>
>
>> :
>> 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 
> facilities.
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 :)

>
> -Alan.
Rémi