HI Alexey,
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.
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