[
https://issues.apache.org/jira/browse/QPIDJMS-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPIDJMS-205:
-----------------------------------
Description:
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.
was:
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.
> 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]
