franz1981 commented on a change in pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#discussion_r737494700
##########
File path: qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsConnection.java
##########
@@ -183,6 +189,44 @@ JmsConnection connect() throws JMSException {
return this;
}
+ ExecutorService getCompletionExecutor() {
+ ThreadPoolExecutor exec = completionExecutor;
+ if (exec == null) {
+ synchronized (this) {
+ exec = completionExecutor;
+ if (exec == null) {
+ // it can grow "unbounded" to serve multiple concurrent
session completions:
+ // in reality it is bounded by the amount of concurrent
completion requests
+ exec = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 5,
TimeUnit.SECONDS, new LinkedTransferQueue<>(),
+ new
QpidJMSThreadFactory("JmsConnection ["+ connectionInfo.getId() + "] completion
dispatcher", connectionInfo.isUseDaemonThread()));
Review comment:
> Previously they were named based on their individual session. It might
be good to at least reinstate that name while operating for a given session?
You're right, indeed it was nice to have a good name to find them both on
stack trace and while profiling, let me think how to improve this
If the user doesn't use anymore JMS 2 features in same connection and close
any existing session that use completions, I expect the pool to release any
existing completion thread (at some point), but as you rightly said, it's a
pretty weird an unhappy use case
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
