Coconut AIO [was AbstractSelectableChannel]

Kasper Nielsen <[email protected]> Wed, 24 Nov 2004 17:16:48 +0100
Newsgroups gmane.comp.java.seda.user
Message-ID <[email protected]>
Hi there,

im the author of Coconut AIO (as well as much of the stuff in seda2)

1.
Im a long time user of sandstorm and the functionality of Coconut AIO is 
really a superset of the functionality provided by the sandstorm 
io-libraries. The library can also be used in a blocking style or even 
in a callback style on a per-operation basis. Furthermore there is JMX 
support and a lot of small tools for debugging your applications. There 
are also some performance enhancements (compared to the sandstorm 
io-libraries) and much better exception handling. Finally it got lots of 
test cases > 200 test cases.

2.
Currently its 1.5 only, but it should be possible to make a 1.4 version 
without too much trouble. Compared to the alternatives of developing 
something from scratch, which is a long process (trust me) or fixing the 
sandstorm io libraries. I would probably go with fixing coconut AIO. 
However don't expect to be able to make a pre-nio (1.3 and ealier) 
version. NBIO is dead anyway.

3.
Regarding IBM's AIO, first of all there is the license which is probably 
  a no go. The other problem with this library is that it is based on 
futures and doesn't really go well in hand with the Sink/sandstorm 
approach. So just drop that approach.

4.
Regarding changing blocking state for streaming/datagram sockets by 
using AbstractSelectableChannel.configureBlocking(boolean block) is a 
bad idea for a number of reasons. The primary reason is that there is no 
such thing as a blocking-write nonblocking-read configuration. So if the 
socket is configured as blocking we need a seperate thread for each 
blocking socket for reading. This is just a bookkeeping nightmare.
However, im using the approach for an asynchronous serversocket where 
I've got a (blocking) accept() and a asynchronous accept(Sink someSink).

I think it could be possible without to many problems to implement this 
blocking functionality. Try, for example, opening 
http://tinyurl.com/6zpmf and searching for "checkBufferLimit(long 
bytes)" I figure we would just replace the throw rejectedException with 
some code that blocks.

5.
Im not to sure about the backpressure mechanism Quartz is talking about. 
 But non-blocking sockets does not backpressure in anyway.

6.
Finally, I agree with quartz that the sandstorm aiofile library is 
useless is some sense. The reason I did include a AsyncFile anyway is 
that I want to be able to write files directly from a disk channel to a 
socket (which, btw, is not possible in the sandstorm afile lib). The 
feature is currently only halfway implemented though.

- Kasper

Jean Rodrigues wrote:
> Hum, perhaps we should try a async emulation layer
> instead of using nio. 
> There is a true async implementation from IBM that
> could solve the known problem of scalability (C10K
> problem).
> But I dont think we can use on this project (maybe
> because of licensing issues, but need to check it
> anyway).
> 
> And, we can try Coconut AIO emulation layer. It seems
> to be pretty interesting implementation that could
> enhance seda performance.
> 
> See: http://coconut.codehaus.org/Coconut+AIO
> There is only a concern: It must be run on JDK 5.
> 
> []`s
> 
>  --- Quartz <[email protected]> escreveu: 
> 
>>>If what you are saying is true, how would you
>>
>>handle
>>
>>>3000 connections like this:
>>>
>>>3000 connections --> stage 1 --> stage 2
>>>
>>>Stage 1: accepts connections and delegate its
>>>processing to stage 2
>>>Stage 2: this stage can`t swallow the produced
>>>channels so will you make a bloquing enqueue here?
>>
>>I
>>
>>>did it ... my result was a BrokenPipeException
>>
>>because
>>
>>>network queue got full.
>>
>>
>>I'm not familiar with selectable stuff.
>>Like I said, I would 'trust' the kernel to back
>>pressure.
>>I might be a fool thinking that. Hope not.
>>
>>But if I have to do something about it, I would
>>start with 
>>AbstractSelectableChannel.configureBlocking(boolean
>>block)
>>It seams it can be changed on the fly.
>>
>>Otherwise,
>>
> 
> http://java.sun.com/developer/JDCTechTips/2004/tt0914.html#1
> 
>>or
>>http://java.sun.com/j2se/1.4.2/docs/guide/nio/




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/