[ 
https://issues.apache.org/jira/browse/QPIDJMS-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell reassigned QPIDJMS-553:
--------------------------------------

      Component/s: qpid-jms-client
    Fix Version/s: 1.6.0
         Assignee: Robbie Gemmell
      Description: 
Having the chance to handle many client connections with few Netty threads can 
be beneficial, eg in terms of the thread staying warm, batching batching 
syscalls across connections when using the coming io_uring support, plus it can 
already aid in constrained environments with many connections by helping reduce 
the native and heap memory usage through consolidating various data structure 
uses etc.

Add a _"transport.sharedEventLoopThreads"_ URI option that can be used to 
specify a number of threads to use in an EventLoopGroup shared amongst 
connections using the same value. Default to -1 giving the existing behaviour 
of each connection using its own.

  was:
One of the most interesting feature of Netty while using KQueue/NIO/Epoll in 
non-blocking mode is to be able to handle many connections with few threads; 
this is going to be critical and even more important with the upcoming IO_URING 
support, where the time spent on the Netty event loop to handle network 
syscalls will be further reduced, allowing syscall batching across different 
connections.

Having the chance to handle many client connections with few Netty threads is 
already beneficial in constrained environments (containers with few cores) in 
order to reduce the native and heap memory usage.


> Shared Netty event loop group
> -----------------------------
>
>                 Key: QPIDJMS-553
>                 URL: https://issues.apache.org/jira/browse/QPIDJMS-553
>             Project: Qpid JMS
>          Issue Type: New Feature
>          Components: qpid-jms-client
>            Reporter: Francesco Nigro
>            Assignee: Robbie Gemmell
>            Priority: Major
>             Fix For: 1.6.0
>
>
> Having the chance to handle many client connections with few Netty threads 
> can be beneficial, eg in terms of the thread staying warm, batching batching 
> syscalls across connections when using the coming io_uring support, plus it 
> can already aid in constrained environments with many connections by helping 
> reduce the native and heap memory usage through consolidating various data 
> structure uses etc.
> Add a _"transport.sharedEventLoopThreads"_ URI option that can be used to 
> specify a number of threads to use in an EventLoopGroup shared amongst 
> connections using the same value. Default to -1 giving the existing behaviour 
> of each connection using its own.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to