Robbie Gemmell created QPIDJMS-205:
--------------------------------------
Summary: 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' ('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]
