Hi, By reading the Java library, I noticed that each connection (transport) gets its own thread (in the thread-pool version), so a given thread will process requests of a single connection. In the single thread version, you can only have a single connection concurrently. Why not accepting connection as they arrive, initiate a read on all of them, put them is something like an epoll (Linux world), and the pool of k threads would take care of the next request of the next k connection which responded. When a thread has done with a request, it can put it back in the epoll, and pick up another one. That's based on event-based servers such as Nginx or Cherokee.
Could you tell me why the current design has been selected? I think that the best way to use the current server is by creating a connection, making a call or two, then disconnect. But socket creation takes time, that's why it would be nicer to keep some connections open, and reuse them when needed (think about connection pool of database, but instead of a database, you get thrift). I have noticed your non blocking server based on http://java.sun.com/javase/6/docs/api/java/nio/channels/spi/SelectorProvider.html, but you use the framed protocol to read the whole packet completely before calling the implementation. But this is not needed, as I said in the first paragraph, we could just read the first chunk of bytes (i.e. 4096) of each connection. This would required one read buffer per connection, but it is not a problem since the objective would be to reuse the connections. Thanks, Laurent Debacker.
