ActiveMQConnection implements FailoverEventListener which executes client's
FailoverEventListeners in separated threads in background. The old implementation
does not guarantee ordering of their executions. The commit improves the
implementation to guarantee it.
https://issues.apache.org/jira/browse/ARTEMIS-524
I am keeping all the debug ad tracing I added during the debug of this issue,
for that reason this commit may look longer than expected
The fix will be highlited by the tests added on org.apache.activemq.artemis.tests.integration.client.PagingTest
OptimizedAckTest: Using core api to replace old activemq
broker API to checking message count.
JmsQueueTransactionTest#testCloseConsumer: a bug in
delivery when prefetchSize is 0.
(InitalReconnectDelayTest)close connection after test.
Temp Queue not deleted when connection is closed.
Enable Stomp in openwire test because some test uses it.
Remove unused code in opwnwire
Wrong XA error code returned when xid is missing
(ActiveMQXAConnectionFactory.testRollbackXaErrorCode)
regression in ActiveMQSslConnectionFactoryTest (SSL related)
1. Changed public fields in ActiveMQClient to private and added getters.
Exposing fields for thread pool sized allow to modify them in undesired ways.
I made these fields private and added corresponding getter methods.
In addition, I renamed the field 'globalThreadMaxPoolSize'
to 'globalThreadPoolSize' to be more consistent with the
'globalScheduledThreadPoolSize' field name.
I also adapted some tests to always call clearThreadPools after
the thread pool size configuration has been changed.
2. Protect against injecting null as thread pools
ActiveMQClient.injectPools allowed null as injected thread pools.
The effect was that internal threads pools were created,
but not shutdown correctly.
Some of the SSL tests in openwire requires to pass in more options like
enabledCipherSuites. It needs to refactor the test util to allow passing
of those options to broker.
And some of the cipher suite is obsolete in recent jre. Meaning they
are disabled by default for security reasons
(e.g. SSL_RSA_WITH_RC4_128_SHA). This will cause SSL handshake failure.
It can be fixed by using a more secure (not disabled) one, like
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TheJMSVendor protocol convertor class was not creating the destinations so any destination calls, setTo and setJMSReplyTo, were ignored. Ive added a server side destination class to bypass the naming checks we have on the client and this now sets everything correctly
https://issues.apache.org/jira/browse/ARTEMIS-453
