Allow for pluggable algorithm to choose next EventLoop #1230
Comments
buchgr
added a commit
to buchgr/netty
that referenced
this issue
May 25, 2014
Motivation: Currently when a new event loop is needed to register a channel our EventLoopGroup implementations just use a round-robin like algorithm to choose the next event loop. Unfortunately this is not always good enough as different event loops may become more busy than others over time. This is especially true when an application handles different kinds of connections (long-living and short-living). This change allows developers to plug in their own algorithms to choose the next event loop and to collect metrics about the busyness of the event loops. See netty#1230 Modifications: - TODO Result: - Developers can plug in their own algorithms into MultithreadEventLoopGroup constructors. - Developers can gather metrics/feedback from the event loops and use the data in their custom algorithms.
buchgr
added a commit
to buchgr/netty
that referenced
this issue
Aug 5, 2014
Motivation: Currently when a new event loop is needed to register a channel our EventLoopGroup implementations just use a round-robin like algorithm to choose the next event loop. Unfortunately this is not always good enough as different event loops may become more busy than others over time. This is especially true when an application handles different kinds of connections (long-living and short-living). This change allows developers to plug in their own algorithms to choose the next event loop and to collect metrics about the busyness of the event loops. See netty#1230 Modifications: - TODO Result: - Developers can plug in their own algorithms into MultithreadEventLoopGroup constructors. - Developers can gather metrics/feedback from the event loops and use the data in their custom algorithms.
buchgr
added a commit
to buchgr/netty
that referenced
this issue
Aug 6, 2014
Motivation: Currently when a new event loop is needed to register a channel our EventLoopGroup implementations just use a round-robin like algorithm to choose the next event loop. Unfortunately this is not always good enough as different event loops may become more busy than others over time. This is especially true when an application handles different kinds of connections (long-living and short-living). This change allows developers to plug in their own algorithms to choose the next event loop and to collect metrics about the busyness of the event loops. See netty#1230 Modifications: - TODO Result: - Developers can plug in their own algorithms into MultithreadEventLoopGroup constructors. - Developers can gather metrics/feedback from the event loops and use the data in their custom algorithms. bla
buchgr
added a commit
to buchgr/netty
that referenced
this issue
Aug 10, 2014
Motivation: Currently when a new event loop is needed to register a channel our EventLoopGroup implementations just use a round-robin like algorithm to choose the next event loop. Unfortunately this is not always good enough as different event loops may become more busy than others over time. This is especially true when an application handles different kinds of connections (long-living and short-living). This change allows developers to plug in their own algorithms to choose the next event loop and to collect metrics about the busyness of the event loops. See netty#1230 Modifications: - TODO Result: - Developers can plug in their own algorithms into MultithreadEventLoopGroup constructors. - Developers can gather metrics/feedback from the event loops and use the data in their custom algorithms.
|
@jakobbuchgraber @normanmaurer - It seems like this was resolved by #2470? I am cleaning up 5.0.0.Alpha2 assignment and let me know if this is in error. |
|
@Scottmitch no it wasn't. it will be resolved by #2788 ... waiting for review :) |
|
@jakobbuchgraber - Thanks for the clarification. I am also going to move this issue to 5.0.0.Alpha3 with PR #2788 (see my last comment in that PR). |
|
@jakobbuchgraber - The re-assignment is in support of #2933. |
|
Hello, I'm trying to find the status of this work but last I see it seems that @buchgr is no longer legally allowed to continue work on this effort. Is this something that's still planned for release? |
|
Fixed by #5279 |
liuzhengyang
pushed a commit
to liuzhengyang/netty
that referenced
this issue
Sep 10, 2017
…tty#1230] Motivation: Sometimes it may be benefitially for an user to specify a custom algorithm when choose the next EventExecutor/EventLoop. Modifications: Allow to specify a custom EventExecutorChooseFactory that allows to customize algorithm. Result: More flexible api.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment we just choose the next EventLoop based on some modulo operation. This may be not optimal for some reasons as there may be one EventLoop which is more busy as the other. Optimal we would allow to plugin the agorithm.
The text was updated successfully, but these errors were encountered: