[
https://issues.apache.org/jira/browse/QPIDJMS-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15465152#comment-15465152
]
ASF subversion and git services commented on QPIDJMS-205:
---------------------------------------------------------
Commit 87dbd80dc61928b5ce228342ccf26f7a3a4de006 in qpid-jms's branch
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=87dbd80 ]
QPIDJMS-205: update group shutdown to use 0ms grace period and await completion
> make shutdown of Netty executor group wait for completion
> ---------------------------------------------------------
>
> Key: QPIDJMS-205
> URL: https://issues.apache.org/jira/browse/QPIDJMS-205
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 0.10.0
> Reporter: Robbie Gemmell
> Assignee: Robbie Gemmell
> Fix For: 0.11.0
>
>
> The client (and some test server/transports) doesn't currently wait for
> completion when it instructs the Netty executor group for the connection to
> shut down during transport closure, it should.
> Some manifestations of issues this leads to:
> - The thread may still be running when e.g a container checks for Thread and
> ThreadLocal leakage during shutdown of an app using the client.
> - When lots of connections are created and closed in a small period of time,
> this can lead to a lot of Thread and Selector's remaining 'in use' during the
> shutdown period. This has been seen to occasionally present itself in CI, e.g
> hitting open file descriptor limits or running out of memory for thread stack
> etc.
> Making use of Netty's 'shutdownGracefully' method (with 'shutdownNow' being
> deprecated) and waiting for the completion, an observed 1 second delay is
> present, which is undesirable as it makes the tests (and real world use) take
> [a lot] longer. However as of the 4.0.41.Final release (/
> https://github.com/netty/netty/issues/4241) which we now use thanks to
> QPIDJMS-203, using a 0ms 'grace Period' no longer sees this delay. Given that
> we dont use the group for other tasks and don't try to shut it down until
> after the lone Channel on it has been closed, supplying a 0ms grace period
> seems suitable in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
