Something bizarre happened with commit
8f52a622d0d883ca5e9f60ba7754ed51de38cc5c in April 2015. It reverted the
changes from both c1111cc156684b15938ab3f8e34df9f4b64f57c4 and
ada112a6a37dce8ddf48e2238904421b2ca8e0dc. This commit fixes that.
Implements a new feature for the broker whereby it may automatically create and
delete JMS topics which are not explicitly defined through the management API
or file-based configuration. A JMS topic is created in response to a sent
message or connected subscriber. The topic may subsequently be deleted when it
no longer has any subscribers. Auto-creation and auto-deletion can both be
turned on/off via address-setting.
This reverts commit a3efafd97593af22d5b0140e16bf6c320a13bb3f.
This reverts commit cf3396a3a605081dfb30b222a745bd803858fb70.
This reverts commit 17ea05bce666e27b9a2808f4a186307ef92c1b2b.
This reverts commit af4aa9fcb67431dc04ac6d13584391925f691ae4.
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.
- Added a thread pool executor, that combines cached and fixed size thread pooling.
It behaves like a cached thread pool in that it reuses exising threads and removes
idle threads after a timeout, limits the maximum number of threads in the pool, but
queue additional request instead of rejecting them.
- changed existing code to use the new thread pool instead of a fixed-size thread pool in
all places that are configured with a client thread pool size.
