Apiviz is not maintained any longer, so I don't want to include it on apache activemq6 any longer.
We may replace it for something else later, but apiviz should be removed now
Also removing the word Netty from the starting acceptor and its version
I don't think it's necessary to mention Netty at the console or its version.
That's internal implementation detail at this point
https://issues.apache.org/jira/browse/ACTIVEMQ6-7
Connection Factory is now externalizable and is now serialized as a string that represents a URI. There are schemas for every possible type for connection factory and server locator.
The client JNDI representation of factories has also been changed to be consistent with this.
https://issues.apache.org/jira/browse/ACTIVEMQ6-78 performance work
There are two aspects of this work. First avoid asynchronous packets and avoid
context switch over the executors. Packet had a method to make certain packets such
as commit to use a different executor. Since it's NIO everything is done at the Netty thread now.
The second aspect was to make sure we use the proper buffering
To support HornetQ clients we must pass back HornetQ connector factory
names. Currently the connector factory name returned as part of node up
broadcast group (after initial client connection and client sends suscribe
topology packet) is what ever the server is configured to use in its
cluster discovery. Since the server has now been repackaged to
org.apache.activemq, the older HornetQ clients can not find the
connector factory class on it's class path. To get around this problem
the server now checks the version of the client and if the client is
HornetQ the server renames the to org.hornetq and returns before sending
to the client.
Implements a feature whereby the broker will not shutdown while there are
clients connected. A timeout can be specified so that even if there are
clients connected the broker will still shutdown after a certain time.
Implements a new feature for the broker whereby it may automatically
create and delete JMS queues which are not explicitly defined through
the management API or file-based configuration. A JMS queue is created
in response to a sent message or connected consumer. The queue may
subsequently be deleted when it no longer has any messages and
consumers. Auto-creation and auto-deletion can both be turned on/off
via address-setting.
https://issues.apache.org/jira/browse/ACTIVEMQ6-68
The logic on transferring method is a bit complex, where
I found a better way to calculate the targetIDs.
This will also fix a few ScaleDownTests
I also added some extra tests using ScaleDownDirect
- added missing license headers found by maven rat plugin.
most of them added automatically via apache-rat
a few manually added
- added apache-rat maven plugin to the build cycle
https://issues.apache.org/jira/browse/ACTIVEMQ6-44
The DiscoveryGroup should be resilient to failures on the communication.
We shouldn't kill the Loop if an exception happened during the read of the UDP messages.
jbertram
Martyn Taylor
Clebert Suconic
Andy Taylor
Howard Gao