Coconut AIO [was AbstractSelectableChannel]
Kasper Nielsen <[email protected]> Wed, 24 Nov 2004 17:27:14 +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/