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.
using connector-name attribute got the following exception, -
'AMQ214019: Invalid configuration: org.xml.sax.SAXParseException; cvc-type.3.1.1: Element 'connector-ref' is a simple type,
so it cannot have attributes, excepting those whose namespace name is identical to
'http://www.w3.org/2001/XMLSchema-instance' and whose [local name] is one of 'type',
'nil', 'schemaLocation' or 'noNamespaceSchemaLocation'. However, the attribute, 'connector-name' was found.'
This feature required a bit of refactoring to the plugin interface itself as
well as a restriction on the configuration so that either only one plugin could
be specified or an ulimited number of security-setting matches. This was done
to prevent messy situations where a plugin could update settings from the XML
or even another plugin if there were overlapping matches.
Its now possible to also add the broker name to jmx tree avoiding clashes when multiple brokers are in a single vm. This is now the default but the old way can be used with some configuration
https://issues.apache.org/jira/browse/ARTEMIS-311
The failback process needs to be deterministic rather than relying on various
incarnations of Thread.sleep() at crucial points. Important aspects of this
change include:
1) Make the initial replication synchronization process block at the very
last step and wait for a response from the replica to ensure the replica has
as the necessary data. This is a critical piece of knowledge during the
failback process because it allows the soon-to-become-backup server to know
for sure when it can shut itself down and allow the soon-to-become-live
server to take over. Also, introduce a new configuration element called
"initial-replication-sync-timeout" to conrol how long this blocking will occur.
2) Set the state of the server as 'LIVE' only after the server is fully
started. This is necessary because once the soon-to-be-backup server shuts
down it needs to know that the soon-to-be-live server has started fully before
it restarts itself as the new backup. If the soon-to-be-backup server restarts
before the soon-to-be-live is fully started then it won't actually become a
backup server but instead will become a live server which will break the
failback process.
3) Wait to receive the announcement of a backup server before failing-back.
https://issues.apache.org/jira/browse/ACTIVEMQ6-89
I have done a lot of refactoring on this. So we can a different version of the interceptor for each protocol based on a base class now.
Just an abstract class over Stomp would be a bit hacky... this is a better approach.
I also did some review of the huge table we have,
removed a few columns such as the datatype and
embedded the default on the description. Just trying to make easier to render and read
Also a few fixes on the doc context such as adding links and improving configuration-index
I - Removing note about deprecated properties. Our configs are using it
II - useNIO property is irrelevant since we always use NIO now with the new netty
I have changed the OpenOffice files. Exported the pictures
As I exported the pictures I selected the group on the slide,
File->Export, JPG file, and selected selection only.
The size was the default size and that worked alright.
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.
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-3
We are renaming packages from activemq6 to activemq as that's more generic and version independent
The previous commit renamed the directories. On this commit now I'm changing the code.
If we changed the code and the directories on the same commit git would remove and add a lot of files
without recognizing the renames.
jbertram
Lionel Cons
Clebert Suconic
Pat Fox
Martyn Taylor
Dejan Bosanac
Andy Taylor
Martin Styk
Javier Lopez
Ville Skyttä
Alexey Pakseykin
Claus Ibsen
Glaucio Melo
Erich Duda
Andy Taylor
Jeff Genender
Hiram Chirino
nberdikov
jbertram
Howard Gao