Hi Bongjae,
> 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?
Looks fine for me.
>
> And if you find some points which I have missed, please let me know.
IMHO it could be good to support the same thing for TCP and SSL
ConnectorHandlers (AFAIK we don't have this implemented yet).
Thank you!
WBR,
Alexey.
>
> 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
>
> <
> 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