Hi Bongjae, Alexey,
> Hi,
>
> I modified the proposed patch and attached it.
>
> As Alexey's words, I think that it is impossible that we support round robin SelectionKey distribution for UDP server-side.
>
> So I support UDP client-side connections distribution in the attached patch instead of server-side.
>
> In UDPConnectorHandler#connect(), I select a relativeSelectorHandler from aux controller. Then, client-side's OP_READ will be controlled in aux controller.
>
> When I used many UDPConnectorHandlers concurrently on 4 CPUs(local Windows machine), I found that the perf was improved. (About 30%~40%??, but it is not accurate)
>
> Could you please review this?
It seems to me that RoundRobinSelectorHandler does not distribute the load
in a round robin manner. That is because roundRobinCounter is a primitive
integer, so it seems that nextController method returns same
ReadController to different threads.
I am not sure about this, but should we change roundRobinCounter to
volatile int, or AtomicInteger? This is not a big issue, though.
Minoru
> And if you find some points which I have missed, please let me know.
>
> Thanks!
>
> --
> Bongjae Chang
>
>
> ----- Original Message -----
> From: Bongjae Chang
> To: dev_at_grizzly.dev.java.net
> Sent: Monday, June 29, 2009 9:26 PM
> Subject: Re: Supporing OP_READ round robin on UDP
>
>
> Hi Alexey,
>
> I see. You are right!
>
> I was perhaps misunderstanding the issue. :(
>
> I will investigate it again.
>
> Thank you for your advice.
>
> --
> Bongjae Chang
>
>
> ----- Original Message -----
> From: Oleksiy Stashok
> To: dev_at_grizzly.dev.java.net
> Sent: Monday, June 29, 2009 8:23 PM
> Subject: Re: Supporing OP_READ round robin on UDP
>
>
> 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
>
>