server - pros and cons of using serialization with java nio versus old socket programming model -

i want choose between using old socket programming model (one thread per socket) , new socket programming model uses java.nio. when read article non blocking socket architecture, noticed architecture based on serialization of requests coming clients.

according article, client applications simultaneously perform requests server. selector collects them, creates keys, , sends them server. article confused me, since serialization cannot support scalabity of servers.

if have 10000 of clients connected server, there should delay process sub-requests of clients. on other side, read way scale server 1000 of clients using java.nio.

here article: http://archive.oreilly.com/pub/a/onjava/2002/09/04/nio.html?page=2

so article confused me, since serialization cannot support scalabity of servers. if have 10000 of clients connected server, there should delay process sub-requests of clients.

when there i/o process nio thread run @ full speed, processing data fast physically able. key keeping nio thread performant not perform time-consuming or blocking operations on thread. want handle each piece of incoming data fast possible.

doing means nio thread scale speed of processor, these days considerable.

yes, @ point nio thread consume 100% cpu , won't able handle more i/o. point much, higher in traditional blocking i/o architecture though. not mention won't have 10,000+ threads context switching , chewing huge amounts of resources (stack space, os task entries, etc.).

if find hitting limit of 1 nio thread can handle--which rare--it's easy enough add additional nio threads.