Hi,
> Alexey wrote:
> >IMHO it could be good to support the same thing for TCP and SSL
> ConnectorHandlers (AFAIK we don't have this implemented yet).
>
> Right. I also think so.
>
> For TCP, maybe some logic should also be considered more in
> SelectorHandlerRunner as well as ConnectorHandler because OP_CONNECT
> could be controlled by selector thread.
>
> I will try to do it again.
That's correct, we can process OP_CONNECT similar way as OP_ACCEPT and
update ConnectorHandler with new SelectorHandler.
Thank you!
WBR,
Alexey.
>
> Thanks.
>
> --
> Bongjae Chang
>
>
> ----- Original Message -----
> From: Oleksiy Stashok
> To: dev_at_grizzly.dev.java.net
> Sent: Tuesday, June 30, 2009 6:10 PM
> Subject: Re: Supporing OP_READ round robin on UDP
>
> 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
>
>