Hi All,
I'm Vipul Pandey, got interested in async-j a little while back in my
quest for picking up JavaNIO.
I'm new to nio, but not so new with Java and i have written servers
using the same.
I'm hoping that i would be able to contribute a little bit(my level
best) to your efforts and learn a lot from you people.
I have already exchanged a few mails with Thanos, and i thank him for
allowing me to comment on and appreciate your work.
To begin with, i would want to make a few comments/queries on the
existing codebase :
(i could be entirely wrong so please correct me wherever i am, do
keep in mind that i'm new to NIO :)
Also, I completely understand that async-j is still in its infancy
and most of the concerns i have might have already been identified by
you people. )
version : 1.4-02
i) The first FOR loop in Async.run() method didn't impress me much.
I have a feeling that, in the event where there are many channels
registered with the selector, this loop would delay event capturing
from the Selector.
Also there is a chance that there are no changes in the Interest set
of any channel for some time, in which case the loop would run for no
reasons at all.
Ideally, we should call the key.InterestOps method only when it is
required, i.e as and when the interest set changes for a channel.
(i might be missing on a serious design consideration though, if any ?)
ii) Clubbing the accept events with other read/write/connect events
might not be the best idea.
Ideally, No read/write event should delay accepting of the new
connections.
I would recommend having a dedicated selector(and hence a dedicated
thread) for the ServerSocketChannel to avoid this problem.
iii) For other channels (read/write), it might not be the best idea
to call the 'process' method of the corresponding handler in the same
thread that also polls the selector for further events.
This would reduce the fairness of the system towards the clients.
(even if the process method just reads a few bytes from the stream)
The thread that polls the selector should only 'poll the selector'.
As soon as an event is obtained from selector.select() call, the
channel/handler/key should be handed over to a different stage (via a
queue or sth) with its own thread-pool (i'm bragging about SEDA
here:) ) to service the request.
iv) The new "abstract read()" method in BufferedHandler could be done
away with, in my opinion. (unless i'm missing on something)
// --------------------- Interface ReadHandler
---------------------
public abstract byte[] read(byte[] bytes) ;
Say you have a subclass of BuffferedHandler (MyHandler) that
implements the read(bytes) method, it is still the BufferedHandler
that is "pushing"
the data to the actual Handler (MyHandler) by calling the read
(bytes) method
instead of MyHandler "pulling" the data from BufferedHandler by
calling it's
public byte[] read(Async router, SelectionKey key)
method.
Since it is only MyHandler that knows about the protocol and hence
knows how much of data is to be read, it should be MyHandler that
calls read(router,key) method of BufferedHandler
instead of BufferedHandler calling the read(bytes) method of MyHandler.
In my implementation, i would have MyHandler implement
public byte[] read(Async router, SelectionKey key) throws
IOException
method and keep calling the same method of the BufferedHandler to get
as much data as it wants (or is available).
"process" method in BufferedHandler would then directly call the read
(router,key) method of MyHandler which would then call read
(router,key) method of BufferedHandler as many times as it wants.
(not sure whether i was able to clearly put my point or not)
I guess i have only this much for today.
Correct me wherever i have gone wrong.
I have also started writing a generic protocol handling code for
async-j, i started implementing that only to get a feel for this
project.
I would post it to the group soon, such that you fellers could
provide your expert comments on that and add it to async-j if deem fit.
Thanks,
Vipul Pandey
vip...@us...
|
