coolnigh, can we continue the discussion on the grizzly users list?
[hidden email] wrote:
> I am reading code of grizzly 1.6, and I have several questions.
> 1) if I use grizzly, I have to deal with nio detail?
> If this is true, it sounds bad!
Yes and no depending on what you want to do. The bytes read are always
available inside a ByteBuffer. So if you need to parse the bytes, yes
you have to interact with NIO objects. Grizzly take cares of the low
level handling, but your ProtocolFilter always have to interact with
> 2) I am wondering how to write a high performance Echo server with grizzly.
> I read the code of EchoFilter, I found that it supposed that I use thread pool !
> In EchoFilter, it calls OutputWriter.flushChannel to write data to client. But OutputWriter.flushChannel will block at select method.
> if there are some slow clients,each slow client will block one thread, it's easy to make
> all threads blocked!
Right the EchoFilter is an example. You aren't forced to use the
"blocking" OutputWriter, but you will have to write your own NIO code.
Release 1.6.2 will have an asynchronous write mechanism for application
that don't want to use the OutputWriter.
This feature is very often asked. If you join the Grizzly dev list, you
will see that we have started discussing how we want to efficiently
support async write.
> 3) For checking key timeout, after select method called and ready keys dealed with, Controller
> will check whether there are any keys of the selector timeouted.
> But if there are thousands of clients, this check will take some time, how can the server be of high performance?
I don't think the operation reduce significantly performance (at least
for the http case, we never found it was a bottleneck). But we have made
the strategy pluggable, so you can always inject your own (or disabled it).