Hi,
I am investigating Grizzly issue #600(
https://grizzly.dev.java.net/issues/show_bug.cgi?id=600, "OP_READ round robin in selector" ).
And I attached the proposed patch.
I tested all unit tests locally on 4 CPUs.
But I couldn't do a performance test completely, so I think that more performance tests should be done.
When I was going on the issue, I had a question.
UDP is different from TCP because OP_READ is available without OP_ACCEPT in server side.
When TCP receives OP_ACCEPT in main selector thread, TCP delivers OP_READ to auxiliary ReadController.
It's OK.
In my patch about UDP,
I ignored a first OP_READ which was received in main selector thread for dispatching it, and registered it in auxiliary ReadController again like TCP.
In other words, whenever UDP receives OP_READ directly in main selector thread, thread's context switch will occur for supporting round robin.
But, if round robin on UDP is not supported, first OP_READ is handled in main selector thread without thread's context switch directly because of leader flollower strategy.
So it is questionable whether UDP's round robin will improve the performance or not. But I believe that it will be able to improve the performance in some circumstances.
If you have better idea for supporing round robin on UDP, please advice me.
And please review the attached patch again.
Thanks!
--
Bongjae Chang