[
https://issues.jboss.org/browse/WFWIP-20?page=com.atlassian.jira.plugin.s...
]
Miroslav Novak commented on WFWIP-20:
-------------------------------------
[~jbertram] I've added code which cleans up client thread pools after the test and
reinitializes during prepare phase of test and it fixed the issue:
https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/messaging-testsuite/...
I didn't have time to check what has changed between Artemis 1.5.x and 2.x but it
seems that global client thread pool got reinitialized when once last client was closed
but now it keeps it's value as it's static variable in ActiveMQClient:
{code}
private static ExecutorService globalThreadPool;
{code}
[Artemis 2.x upgrade] Setting globalThreadPool size on client using
system properties is ignored
------------------------------------------------------------------------------------------------
Key: WFWIP-20
URL:
https://issues.jboss.org/browse/WFWIP-20
Project: WildFly WIP
Issue Type: Bug
Components: Artemis
Reporter: Miroslav Novak
Assignee: Martyn Taylor
Priority: Blocker
Labels: activemq, feature-branch-blocker
Setting client globalThreadPoolSize for configuring max number of
ActiveMQ-client-global-threads using system property or in connection factory which is
looked up by standalone JMS client is ignored. There is alway 8 * number CPU cores.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)