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.
Fixes: ARTEMIS-397
From mqtt specs:
“If the Keep Alive value is non-zero and the Server does not receive a
Control Packet from the Client within one and a half times the Keep
Alive time period, it MUST disconnect the Network Connection to the
Client as if the network had failed [MQTT-3.1.2-24]. “
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)
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
https://issues.apache.org/jira/browse/ARTEMIS-463
This will have some extra refactoring on the protocol head, transferring responsibility to the broker classes in a lot of cases
and removing some duplicated code
This was a team effort from Clebert Suconic and Howard Gao
The problem here is that the management notification listener was mistakenly
removing the topic itself instead of just the non-durable subscription. In
general I can't see why StompProtocolManager even needs to keep track of the
destinations when the broker already does that. As far as I can tell it is
redundant and it's clearly error-prone. Therefore I'm removing the destination
tracking from StompProtocolManager altogether.
