Hi Bongjae,
can you pls. describe the usecase, how we can support round robin
SelectionKey distribution for UDP server-side? We usually open just
one UDP server-side listener on specific port, which is represented by
single DatagramChannel. So *all* the UDP client-side requests come
just to *single* server-side DatagramChannel, so I'm not sure how
we're able to distribute something here...
On other side, it could be good idea to support UDP client-side
connections distribution, when we use UDPConnectorHandlers.
Thanks.
WBR,
Alexey.
On Jun 27, 2009, at 7:39 , Bongjae Chang wrote:
> 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<patch.txt>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net