Sorry if this is a newbie question, but I have been reading a lot on Java's nio classes and different buffering APIs the last couple days and was curious about something.
I noticed in many articles (such as this one:http://java.sys-con.com/node/46658) it claims that java NIO is slowed by the selector() blocking and also due to not being driven by under the hood OS libraries for multiple core IO or buffering. I think the direct buffering of the new NIO libraries removes the second performance hurdle, but for the first, I have only found Java SCR documents and other webpages that still seem to claim that the selector() mode blocking in NIO's libraries (and I guess all parent projects using it's classes) are still subject to performance hits and allowing less connections than optimal. Specifically, in the article linked above it has a table showing that IBM's AIO4J library (taking C and C++'s ideas of IOCP) is much better at handling thousands of connections than NIO. Now, the article is 4 years old, soI am wondering if the issues mentioned in it have been overcome, or if there are still these drawbacks in any NIO based library such as MINA. Also, if anybody could also comment on ASynchWeb I would be grateful. I saw that AsynchWeb is being folded into MINA, but haven't seen if it is finalized. Again, I am just a new developer in this area, but I think ASynchWeb is focused on the HTTP request handling, correct, not on allowing faster request handling with allowing multiple selects at once? Any help or information is appreciated. Thank you, -Jason Bryant This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
