async-j-development — mailing list for developers using async-j

[Vipul P. <vip...@gm...>]

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...