[
https://issues.apache.org/jira/browse/QPIDJMS-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502459#comment-17502459
]
ASF GitHub Bot commented on QPIDJMS-553:
----------------------------------------
gemmellr commented on a change in pull request #45:
URL: https://github.com/apache/qpid-jms/pull/45#discussion_r820939473
##########
File path:
qpid-jms-client/src/main/java/org/apache/qpid/jms/transports/netty/NettyTcpTransport.java
##########
@@ -233,15 +228,13 @@ public void close() throws IOException {
if (closed.compareAndSet(false, true)) {
connected.set(false);
try {
- if (channel != null) {
+ if (channel != null && groupRef != null) {
Review comment:
It didnt see like this should be changing behaviour in a noticable way,
as the group [ref] isnt being created or closed at a different point than
before, so it just seems odd this check of groupRef would be needed here when
this bit doesnt actually close/release the groupRef.
But actually, thinking on it more, I guess it really _does_ change the group
behaviour; the shared executor will _continue_ running after the provider
thinks it closed it down, if other connections are still using it. Thus with
these changes it could continue executing things for the provider/connection
even after we currently expect it cant. That may need further changes to
address.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> Shared Netty event loop group
> -----------------------------
>
> Key: QPIDJMS-553
> URL: https://issues.apache.org/jira/browse/QPIDJMS-553
> Project: Qpid JMS
> Issue Type: New Feature
> Reporter: Francesco Nigro
> Priority: Major
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
