diff --git a/activemq-server/src/main/java/org/apache/activemq/core/config/Configuration.java b/activemq-server/src/main/java/org/apache/activemq/core/config/Configuration.java index 8ab206f5ac..e0eb4e5456 100644 --- a/activemq-server/src/main/java/org/apache/activemq/core/config/Configuration.java +++ b/activemq-server/src/main/java/org/apache/activemq/core/config/Configuration.java @@ -998,7 +998,7 @@ public interface Configuration extends Serializable /* * @see #setResolveProtocols() * @return whether HornetQ should resolve and use any Protocols available on the classpath - * Default value is {@value org.apache.activemq.api.config.HornetQDefaultConfiguration#DEFAULT_RESOLVE_PROTOCOLS}. + * Default value is {@value org.apache.activemq.api.config.ActiveMQDefaultConfiguration#DEFAULT_RESOLVE_PROTOCOLS}. * */ boolean isResolveProtocols(); diff --git a/activemq-server/src/main/resources/schema/activemq-configuration.xsd b/activemq-server/src/main/resources/schema/activemq-configuration.xsd index dd0863c0da..68e05edb8f 100644 --- a/activemq-server/src/main/resources/schema/activemq-configuration.xsd +++ b/activemq-server/src/main/resources/schema/activemq-configuration.xsd @@ -20,7 +20,7 @@ minOccurs="0"> - If true then the HornetQ Server will make use of any Protocol Managers that are in available on the + If true then the ActiveMQ Server will make use of any Protocol Managers that are in available on the classpath. If false then only the core protocol will be available, unless in Embedded mode where users can inject their own Protocol Managers. @@ -31,7 +31,7 @@ minOccurs="0"> - DEPRECATED. This option is deprecated and its value will be ignored (HQ221038). A HornetQ server will + DEPRECATED. This option is deprecated and its value will be ignored (HQ221038). A ActiveMQ server will be "clustered" when its configuration contain a cluster-configuration. @@ -112,7 +112,7 @@ - @@ -123,7 +123,7 @@ - @@ -133,7 +133,7 @@ - @@ -221,7 +221,7 @@ - the JMX domain used to registered HornetQ MBeans in the MBeanServer + the JMX domain used to registered ActiveMQ MBeans in the MBeanServer diff --git a/distribution/activemq/pom.xml b/distribution/activemq/pom.xml index 4d0c947b11..17a5de641e 100644 --- a/distribution/activemq/pom.xml +++ b/distribution/activemq/pom.xml @@ -73,11 +73,6 @@ activemq-ra ${project.version} - - org.apache.activemq - activemq-service-sar - ${project.version} - org.apache.activemq activemq-spring-integration diff --git a/docs/user-manual/en/HornetQ_User_Manual.ent b/docs/user-manual/en/ActiveMQ_User_Manual.ent similarity index 90% rename from docs/user-manual/en/HornetQ_User_Manual.ent rename to docs/user-manual/en/ActiveMQ_User_Manual.ent index dd225e3e9e..5fd88a24a3 100644 --- a/docs/user-manual/en/HornetQ_User_Manual.ent +++ b/docs/user-manual/en/ActiveMQ_User_Manual.ent @@ -1,5 +1,5 @@ - - + + + %BOOK_ENTITIES; ]> @@ -63,7 +63,7 @@ - + diff --git a/docs/user-manual/en/Author_Group.xml b/docs/user-manual/en/Author_Group.xml index 42b4ffc37f..e73613458e 100644 --- a/docs/user-manual/en/Author_Group.xml +++ b/docs/user-manual/en/Author_Group.xml @@ -13,7 +13,7 @@ --> + %BOOK_ENTITIES; ]> diff --git a/docs/user-manual/en/Book_Info.xml b/docs/user-manual/en/Book_Info.xml index f646ef63b1..3f87ef5a73 100644 --- a/docs/user-manual/en/Book_Info.xml +++ b/docs/user-manual/en/Book_Info.xml @@ -13,29 +13,29 @@ --> + %BOOK_ENTITIES; ]> - - HornetQ User Manual + + ActiveMQ User Manual Putting the buzz in messaging - HornetQ + ActiveMQ 2 2.1.0 1 - The User manual is an in depth manual on all aspects of HornetQ + The User manual is an in depth manual on all aspects of ActiveMQ - + &YEAR; &HOLDER; diff --git a/docs/user-manual/en/aerogear-integration.xml b/docs/user-manual/en/aerogear-integration.xml index 0b34e16f6a..ae65dd75cf 100644 --- a/docs/user-manual/en/aerogear-integration.xml +++ b/docs/user-manual/en/aerogear-integration.xml @@ -18,13 +18,13 @@ + %BOOK_ENTITIES; ]> AeroGear Integration AeroGears push technology provides support for different push notification technologies like Google Cloud Messaging, - Apple's APNs or Mozilla's SimplePush. HornetQ allows you to configure a Connector Service that will consume messages + Apple's APNs or Mozilla's SimplePush. ActiveMQ allows you to configure a Connector Service that will consume messages from a queue and forward them to an AeroGear push server and subsequently sent as notifications to mobile devices.
Configuring an AeroGear Connector Service @@ -96,7 +96,7 @@ Message message = session.createMessage(); - message.setStringProperty("AEROGEAR_ALERT", "Hello this is a notification from HornetQ"); + message.setStringProperty("AEROGEAR_ALERT", "Hello this is a notification from ActiveMQ"); producer.send(message); diff --git a/docs/user-manual/en/appserver-integration.xml b/docs/user-manual/en/appserver-integration.xml index 2a74b15c8c..63d4e55539 100644 --- a/docs/user-manual/en/appserver-integration.xml +++ b/docs/user-manual/en/appserver-integration.xml @@ -18,14 +18,14 @@ + %BOOK_ENTITIES; ]> Application Server Integration and Java EE - HornetQ can be easily installed in JBoss Application Server 4 or later. For details on - installing HornetQ in the JBoss Application Server please refer to quick-start guide. - Since HornetQ also provides a JCA adapter, it is also possible to integrate HornetQ + ActiveMQ can be easily installed in JBoss Application Server 4 or later. For details on + installing ActiveMQ in the JBoss Application Server please refer to quick-start guide. + Since ActiveMQ also provides a JCA adapter, it is also possible to integrate ActiveMQ as a JMS provider in other JEE compliant app servers. For instructions on how to integrate a remote JCA adaptor into another application sever, please consult the other application server's instructions. @@ -35,10 +35,10 @@ AS.
Configuring Message-Driven Beans - The delivery of messages to an MDB using HornetQ is configured on the JCA Adapter via + The delivery of messages to an MDB using ActiveMQ is configured on the JCA Adapter via a configuration file ra.xml which can be found under the jms-ra.rar directory. By default this is configured to consume - messages using an InVM connector from the instance of HornetQ running within the + messages using an InVM connector from the instance of ActiveMQ running within the application server. The configuration properties are listed later in this chapter. All MDBs however need to have the destination type and the destination configured. The following example shows how this can be done using annotations: @@ -48,14 +48,14 @@ @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/testQueue") }) -@ResourceAdapter("hornetq-ra.rar") +@ResourceAdapter("activemq-ra.rar") public class MDBExample implements MessageListener { public void onMessage(Message message)... } In this example you can see that the MDB will consume messages from a queue that is mapped into JNDI with the binding queue/testQueue. This queue must be - preconfigured in the usual way using the HornetQ configuration files. + preconfigured in the usual way using the ActiveMQ configuration files. The ResourceAdapter annotation is used to specify which adaptor should be used. To use this you will need to import org.jboss.ejb3.annotation.ResourceAdapter for JBoss AS 5.X and later version which can be found in the @@ -66,18 +66,18 @@ public class MDBExample implements MessageListener the following to jboss.xml<message-driven> <ejb-name>ExampleMDB</ejb-name> - <resource-adapter-name>hornetq-ra.rar</resource-adapter-name> + <resource-adapter-name>activemq-ra.rar</resource-adapter-name> </message-driven> You - can also rename the hornetq-ra.rar directory to jms-ra.rar and neither the annotation or + can also rename the activemq-ra.rar directory to jms-ra.rar and neither the annotation or the extra descriptor information will be needed. If you do this you will need to edit the jms-ds.xml datasource file and change rar-name element. - HornetQ is the default JMS provider for JBoss AS 6. Starting with this AS version, HornetQ resource + ActiveMQ is the default JMS provider for JBoss AS 6. Starting with this AS version, ActiveMQ resource adapter is named jms-ra.rar and you no longer need to annotate the MDB for the resource adapter name. - All the examples shipped with the HornetQ distribution use the annotation. + All the examples shipped with the ActiveMQ distribution use the annotation.
Using Container-Managed Transactions When an MDB is using Container-Managed Transactions (CMT), the delivery of the @@ -94,7 +94,7 @@ public class MDBExample implements MessageListener }) @TransactionManagement(value= TransactionManagementType.CONTAINER) @TransactionAttribute(value= TransactionAttributeType.REQUIRED) -@ResourceAdapter("hornetq-ra.rar") +@ResourceAdapter("activemq-ra.rar") public class MDB_CMP_TxRequiredExample implements MessageListener { public void onMessage(Message message)... @@ -137,7 +137,7 @@ public void onMessage(Message message) }) @TransactionManagement(value = TransactionManagementType.CONTAINER) @TransactionAttribute(value = TransactionAttributeType.NOT_SUPPORTED) -@ResourceAdapter("hornetq-ra.rar") +@ResourceAdapter("activemq-ra.rar") public class MDB_CMP_TxLocalExample implements MessageListener { public void onMessage(Message message)... @@ -156,7 +156,7 @@ public class MDB_CMP_TxLocalExample implements MessageListener @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Dups-ok-acknowledge") }) @TransactionManagement(value= TransactionManagementType.BEAN) -@ResourceAdapter("hornetq-ra.rar") +@ResourceAdapter("activemq-ra.rar") public class MDB_BMPExample implements MessageListener { public void onMessage(Message message) @@ -211,7 +211,7 @@ public void onMessage(Message message) }) @TransactionManagement(value= TransactionManagementType.CONTAINER) @TransactionAttribute(value= TransactionAttributeType.REQUIRED) -@ResourceAdapter("hornetq-ra.rar") +@ResourceAdapter("activemq-ra.rar") public class MDBMessageSelectorExample implements MessageListener { public void onMessage(Message message).... @@ -236,7 +236,7 @@ public class MDBMessageSelectorExample implements MessageListener }) @TransactionManagement(value= TransactionManagementType.CONTAINER) @TransactionAttribute(value= TransactionAttributeType.REQUIRED) -@ResourceAdapter("hornetq-ra.rar") +@ResourceAdapter("activemq-ra.rar") public class MDBMessageSendTxExample implements MessageListener { @Resource(mappedName = "java:/JmsXA") @@ -308,24 +308,24 @@ public class MDBMessageSendTxExample implements MessageListener }) @TransactionManagement(value= TransactionManagementType.CONTAINER) @TransactionAttribute(value= TransactionAttributeType.REQUIRED) -@ResourceAdapter("hornetq-ra.rar") +@ResourceAdapter("activemq-ra.rar") public class MyMDB implements MessageListener { ....}
Configuring the JCA Adaptor - The Java Connector Architecture (JCA) Adapter is what allows HornetQ to be integrated + The Java Connector Architecture (JCA) Adapter is what allows ActiveMQ to be integrated with JEE components such as MDBs and EJBs. It configures how components such as MDBs - consume messages from the HornetQ server and also how components such as EJBs or + consume messages from the ActiveMQ server and also how components such as EJBs or Servlets can send messages. - The HornetQ JCA adapter is deployed via the jms-ra.rar archive. The + The ActiveMQ JCA adapter is deployed via the jms-ra.rar archive. The configuration of the adapter is found in this archive under META-INF/ra.xml. The configuration will look something like the following: <resourceadapter> - <resourceadapter-class>org.apache.activemq.ra.HornetQResourceAdapter</resourceadapter-class> + <resourceadapter-class>org.apache.activemq.ra.ActiveMQResourceAdapter</resourceadapter-class> <config-property> <description>The transport type. Multiple connectors can be configured by using a comma separated list, i.e. org.apache.activemq.core.remoting.impl.invm.InVMConnectorFactory,org.apache.activemq.core.remoting.impl.invm.InVMConnectorFactory.</description> @@ -344,7 +344,7 @@ public class MyMDB implements MessageListener <outbound-resourceadapter> <connection-definition> - <managedconnectionfactory-class>org.apache.activemq.ra.HornetQRAManagedConnection + <managedconnectionfactory-class>org.apache.activemq.ra.ActiveMQRAManagedConnection Factory</managedconnectionfactory-class> <config-property> @@ -361,12 +361,12 @@ public class MyMDB implements MessageListener <config-property-value>0</config-property-value> </config-property> - <connectionfactory-interface>org.apache.activemq.ra.HornetQRAConnectionFactory + <connectionfactory-interface>org.apache.activemq.ra.ActiveMQRAConnectionFactory </connectionfactory-interface> - <connectionfactororg.apache.activemq.ra.HornetQConnectionFactoryImplonFactoryImpl + <connectionfactororg.apache.activemq.ra.ActiveMQConnectionFactoryImplonFactoryImpl </connectionfactory-impl-class> <connection-interface>javax.jms.Session</connection-interface> - <connection-impl-class>org.apache.activemq.ra.HornetQRASession + <connection-impl-class>org.apache.activemq.ra.ActiveMQRASession </connection-impl-class> </connection-definition> <transaction-support>XATransaction</transaction-support> @@ -384,7 +384,7 @@ public class MyMDB implements MessageListener <messagelistener> <messagelistener-type>javax.jms.MessageListener</messagelistener-type> <activationspec> - <activationspec-class>org.apache.activemq.ra.inflow.HornetQActivationSpec + <activationspec-class>org.apache.activemq.ra.inflow.ActiveMQActivationSpec </activationspec-class> <required-config-property> <config-property-name>destination</config-property-name> @@ -411,7 +411,7 @@ public class MyMDB implements MessageListener
Global Properties The first element you see is resourceadapter-class which should - be left unchanged. This is the HornetQ resource adapter class. + be left unchanged. This is the ActiveMQ resource adapter class. After that there is a list of configuration properties. This will be where most of the configuration is done. The first two properties configure the transport used by the adapter and the rest configure the connection factory itself. @@ -699,12 +699,12 @@ public class MyMDB implements MessageListener factories that are used by Java EE components. These Connection Factories can be defined inside a configuration file that matches the name *-ds.xml. You'll find a default jms-ds.xml - configuration under the hornetq directory in the JBoss AS + configuration under the activemq directory in the JBoss AS deployment. The connection factories defined in this file inherit their properties from the main ra.xml configuration but can also be overridden. The following example shows how to override them. - Please note that this configuration only applies when HornetQ resource adapter is installed in + Please note that this configuration only applies when ActiveMQ resource adapter is installed in JBoss Application Server. If you are using another JEE application server please refer to your application servers documentation for how to do this. @@ -714,7 +714,7 @@ public class MyMDB implements MessageListener <jndi-name>RemoteJmsXA</jndi-name> <xa-transaction/> <rar-name>jms-ra.rar</rar-name> - <connection-definition>org.apache.activemq.ra.HornetQRAConnectionFactory + <connection-definition>org.apache.activemq.ra.ActiveMQRAConnectionFactory </connection-definition> <config-property name="SessionDefaultType" type="String">javax.jms.Topic</config-property> <config-property name="ConnectorClassName" type="String"> @@ -811,8 +811,8 @@ private ConnectionFactory connectionFactory; JndiParams String A semicolon (';') delimited string of name=value pairs which represent the properties to be used for the destination JNDI - look up. The properties depends on the JNDI implementation of the server hosting HornetQ. Typically only be used when the MDB is - configured to consume from a remote destination and needs to look up a JNDI reference rather than the HornetQ name of the + look up. The properties depends on the JNDI implementation of the server hosting ActiveMQ. Typically only be used when the MDB is + configured to consume from a remote destination and needs to look up a JNDI reference rather than the ActiveMQ name of the destination. Only relevant when useJNDI is true (default is an empty string). @@ -856,9 +856,9 @@ private ConnectionFactory connectionFactory;
- Configuring the adapter to use a standalone HornetQ Server + Configuring the adapter to use a standalone ActiveMQ Server Sometime you may want your messaging server on a different machine or separate from the application server. - If this is the case you will only need the hornetq client libs installed. This section explains what config to create + If this is the case you will only need the activemq client libs installed. This section explains what config to create and what jar dependencies are needed.
There are two configuration files needed to do this, one for the incoming adapter used for MDB's @@ -870,7 +870,7 @@ private ConnectionFactory connectionFactory; deploy directory ending in .rar. - For this example we will name the directory hornetq-ra.rar. This detail is + For this example we will name the directory activemq-ra.rar. This detail is important as the name of directory is referred to by the MDB's and the outgoing configuration. @@ -882,7 +882,7 @@ private ConnectionFactory connectionFactory; Under the - hornetq-ra.rar + activemq-ra.rar directory you will need to create a META-INF directory into which you should create an @@ -890,19 +890,19 @@ private ConnectionFactory connectionFactory; configuration file. You can find a template for the ra.xml - under the config directory of the HornetQ distribution. + under the config directory of the ActiveMQ distribution. - To configure MDB's to consume messages from a remote HornetQ server you need to edit the + To configure MDB's to consume messages from a remote ActiveMQ server you need to edit the ra.xml file under - deploy/hornet-ra.rar/META-INF + deploy/activemq-ra.rar/META-INF and change the transport type to use a netty connector (instead of the invm connector that is defined) and configure its transport parameters. Heres an example of what this would look like: -<resourceadapter-class>org.apache.activemq.ra.HornetQResourceAdapter</resourceadapter-class> +<resourceadapter-class>org.apache.activemq.ra.ActiveMQResourceAdapter</resourceadapter-class> <config-property> <description>The transport type</description> <config-property-name>ConnectorClassName</config-property-name> @@ -921,7 +921,7 @@ private ConnectionFactory connectionFactory; -<resourceadapter-class>org.apache.activemq.ra.HornetQResourceAdapter</resourceadapter-class> +<resourceadapter-class>org.apache.activemq.ra.ActiveMQResourceAdapter</resourceadapter-class> <config-property> <description>The transport type</description> <config-property-name>ConnectorClassName</config-property-name> @@ -948,30 +948,30 @@ private ConnectionFactory connectionFactory;
Configuring the outgoing adaptor - You will also need to configure the outbound connection by creating a hornetq-ds.xml + You will also need to configure the outbound connection by creating a activemq-ds.xml and placing it under any directory that will be deployed under the deploy directory. - In a standard HornetQ jboss configuration this would be under hornetq or hornetq.sar + In a standard ActiveMQ jboss configuration this would be under activemq or activemq.sar but you can place it where ever you like. Actually as long as it ends in -ds.xml you can call it anything you like. You can again find a template for this file under the config directory of the - HornetQ distribution but called jms-ds.xml which is the jboss default. + ActiveMQ distribution but called jms-ds.xml which is the jboss default. The following example shows a sample configuration <tx-connection-factory> <jndi-name>RemoteJmsXA</jndi-name> <xa-transaction/> - <rar-name>hornetq-ra.rar</rar-name> - <connection-definition>org.apache.activemq.ra.HornetQRAConnectionFactory</connection-definition> + <rar-name>activemq-ra.rar</rar-name> + <connection-definition>org.apache.activemq.ra.ActiveMQRAConnectionFactory</connection-definition> <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property> <config-property name="ConnectorClassName" type="java.lang.String">org.apache.activemq.core.remoting.impl.netty.NettyConnectorFactory</config-property> <config-property name="ConnectionParameters" type="java.lang.String">host=127.0.0.1;port=5446</config-property> <max-pool-size>20</max-pool-size> </tx-connection-factory> - Again you will see that this uses the netty connector type and will connect to the HornetQ server + Again you will see that this uses the netty connector type and will connect to the ActiveMQ server running on localhost and listening on port 5446. JEE components can access this by using JNDI and looking up the connection factory using JNDI using java:/RemoteJmsXA, you can see that this is defined under thejndi-name attribute. You will also note that the outgoing connection - will be created by the resource adaptor configured under the directory hornetq-ra.rar + will be created by the resource adaptor configured under the directory activemq-ra.rar as explained in the last section. @@ -981,7 +981,7 @@ private ConnectionFactory connectionFactory;
Jar dependencies - This is a list of the HornetQ and third party jars needed + This is a list of the ActiveMQ and third party jars needed Jar Dependencies @@ -997,18 +997,18 @@ private ConnectionFactory connectionFactory; - hornetq-ra.jar - The HornetQ resource adaptor classes - deploy/hornetq-ra.rar or equivalent + activemq-ra.jar + The ActiveMQ resource adaptor classes + deploy/activemq-ra.rar or equivalent - hornetq-core-client.jar - The HornetQ core client classes + activemq-core-client.jar + The ActiveMQ core client classes either in the config lib, i.e. default/lib or the common lib dir, i.e. $JBOSS_HOME/common lib - hornetq-jms-client.jar - The HornetQ JMS classes + activemq-jms-client.jar + The ActiveMQ JMS classes as above @@ -1025,26 +1025,26 @@ private ConnectionFactory connectionFactory;
- Configuring the JBoss Application Server to connect to Remote HornetQ Server - This is a step by step guide on how to configure a JBoss application server that doesn't have HornetQ installed - to use a remote instance of HornetQ + Configuring the JBoss Application Server to connect to Remote ActiveMQ Server + This is a step by step guide on how to configure a JBoss application server that doesn't have ActiveMQ installed + to use a remote instance of ActiveMQ
Configuring JBoss 5 - Firstly download and install JBoss AS 5 as per the JBoss installation guide and HornetQ as per the - HornetQ installation guide. After that the following steps are required + Firstly download and install JBoss AS 5 as per the JBoss installation guide and ActiveMQ as per the + ActiveMQ installation guide. After that the following steps are required - Copy the following jars from the HornetQ distribution to the lib directory of + Copy the following jars from the ActiveMQ distribution to the lib directory of which ever JBossAs configuration you have chosen, i.e. default. - hornetq-core-client.jar + activemq-core-client.jar - hornetq-jms-client.jar + activemq-jms-client.jar - hornetq-ra.jar (this can be found inside the hornetq-ra.rar archive) + activemq-ra.jar (this can be found inside the activemq-ra.rar archive) netty.jar @@ -1052,12 +1052,12 @@ private ConnectionFactory connectionFactory; - create the directories hornetq-ra.rar and hornetq-ra.rar/META-INF + create the directories activemq-ra.rar and activemq-ra.rar/META-INF under the deploy directory in your JBoss config directory - under the hornetq-ra.rar/META-INF create a ra.xml file or - copy it from the HornetQ distribution (again it can be found in the hornetq-ra.rar archive) + under the activemq-ra.rar/META-INF create a ra.xml file or + copy it from the ActiveMQ distribution (again it can be found in the activemq-ra.rar archive) and configure it as follows <?xml version="1.0" encoding="UTF-8"?> @@ -1068,8 +1068,8 @@ private ConnectionFactory connectionFactory; http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd" version="1.5"> - <description>HornetQ 2.0 Resource Adapter Alternate Configuration</description> - <display-name>HornetQ 2.0 Resource Adapter Alternate Configuration</display-name> + <description>ActiveMQ 2.0 Resource Adapter Alternate Configuration</description> + <display-name>ActiveMQ 2.0 Resource Adapter Alternate Configuration</display-name> <vendor-name>Red Hat Middleware LLC</vendor-name> <eis-type>JMS 1.1 Server</eis-type> @@ -1092,7 +1092,7 @@ Copyright 2009 Red Hat, Inc. </license> <resourceadapter> - <resourceadapter-class>org.apache.activemq.ra.HornetQResourceAdapter</resourceadapter-class> + <resourceadapter-class>org.apache.activemq.ra.ActiveMQResourceAdapter</resourceadapter-class> <config-property> <description>The transport type</description> <config-property-name>ConnectorClassName</config-property-name> @@ -1108,7 +1108,7 @@ Copyright 2009 Red Hat, Inc. <outbound-resourceadapter> <connection-definition> - <managedconnectionfactory-class>org.apache.activemq.ra.HornetQRAManagedConnectionFactory</managedconnectionfactory-class> + <managedconnectionfactory-class>org.apache.activemq.ra.ActiveMQRAManagedConnectionFactory</managedconnectionfactory-class> <config-property> <description>The default session type</description> @@ -1123,10 +1123,10 @@ Copyright 2009 Red Hat, Inc. <config-property-value>0</config-property-value> </config-property> - <connectionfactory-interface>org.apache.activemq.ra.HornetQRAConnectionFactory</connectionfactory-interface> - <connectionfactory-impl-class>org.apache.activemq.ra.HornetQRAConnectionFactoryImpl</connectionfactory-impl-class> + <connectionfactory-interface>org.apache.activemq.ra.ActiveMQRAConnectionFactory</connectionfactory-interface> + <connectionfactory-impl-class>org.apache.activemq.ra.ActiveMQRAConnectionFactoryImpl</connectionfactory-impl-class> <connection-interface>javax.jms.Session</connection-interface> - <connection-impl-class>org.apache.activemq.ra.HornetQRASession</connection-impl-class> + <connection-impl-class>org.apache.activemq.ra.ActiveMQRASession</connection-impl-class> </connection-definition> <transaction-support>XATransaction</transaction-support> <authentication-mechanism> @@ -1141,7 +1141,7 @@ Copyright 2009 Red Hat, Inc. <messagelistener> <messagelistener-type>javax.jms.MessageListener</messagelistener-type> <activationspec> - <activationspec-class>org.apache.activemq.ra.inflow.HornetQActivationSpec</activationspec-class> + <activationspec-class>org.apache.activemq.ra.inflow.ActiveMQActivationSpec</activationspec-class> <required-config-property> <config-property-name>destination</config-property-name> </required-config-property> @@ -1153,19 +1153,19 @@ Copyright 2009 Red Hat, Inc. </resourceadapter> </connector> The important part of this configuration is the part in bold, i.e. <config-property-value>host=127.0.0.1;port=5445</config-property-value>. - This should be configured to the host and port of the remote HornetQ server. + This should be configured to the host and port of the remote ActiveMQ server. At this point you should be able to now deploy MDB's that consume from the remote server. You will however, - have to make sure that your MDB's have the annotation @ResourceAdapter("hornetq-ra.rar") + have to make sure that your MDB's have the annotation @ResourceAdapter("activemq-ra.rar") added, this is illustrated in the Configuring Message-Driven Beans section. If you don't want to add this annotation then you can delete the generic resource adapter jms-ra.rar - and rename the hornetq-ra.rar to this. - If you also want to use the remote HornetQ server for outgoing connections, i.e. sending messages, then + and rename the activemq-ra.rar to this. + If you also want to use the remote ActiveMQ server for outgoing connections, i.e. sending messages, then do the following: - Create a file called hornetq-ds.xml in the deploy directory + Create a file called activemq-ds.xml in the deploy directory (in fact you can call this anything you want as long as it ends in -ds.xml). Then add the following: @@ -1177,8 +1177,8 @@ Copyright 2009 Red Hat, Inc. <tx-connection-factory> <jndi-name>RemoteJmsXA</jndi-name> <xa-transaction/> - <rar-name>hornetq-ra.rar</rar-name> - <connection-definition>org.apache.activemq.ra.HornetQRAConnectionFactory</connection-definition> + <rar-name>activemq-ra.rar</rar-name> + <connection-definition>org.apache.activemq.ra.ActiveMQRAConnectionFactory</connection-definition> <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property> <config-property name="ConnectorClassName" type="java.lang.String">org.apache.activemq.core.remoting.impl.netty.NettyConnectorFactory</config-property> <config-property name="ConnectionParameters" type="java.lang.String">host=127.0.0.1;port=5445</config-property> @@ -1187,7 +1187,7 @@ Copyright 2009 Red Hat, Inc. </connection-factories> - Again you will see that the host and port are configured here to match the remote HornetQ servers + Again you will see that the host and port are configured here to match the remote ActiveMQ servers configuration. The other important attributes are: @@ -1244,32 +1244,32 @@ initialContext = new InitialContext(jndiParameters); or lose network connectivity. For more information on XA Recovery,please refer to JBoss Transactions. - When HornetQ is integrated with JBoss AS, it can take advantage of JBoss Transactions + When ActiveMQ is integrated with JBoss AS, it can take advantage of JBoss Transactions to provide recovery of messaging resources. If messages are involved in a XA transaction, in the event of a server crash, the recovery manager will ensure that the transactions are recovered and the messages will either be committed or rolled back (depending on the transaction outcome) when the server is restarted.
XA Recovery Configuration - To enable HornetQ's XA Recovery, the Recovery Manager must be configured to connect - to HornetQ to recover its resources. The following property must be added to the + To enable ActiveMQ's XA Recovery, the Recovery Manager must be configured to connect + to ActiveMQ to recover its resources. The following property must be added to the jta section of conf/jbossts-properties.xml of JBoss AS profiles: <properties depends="arjuna" name="jta"> ... - <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.HornetQ1" - value="org.apache.activemq.jms.server.recovery.HornetQXAResourceRecovery;[connection configuration]"/> + <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.ActiveMQ1" + value="org.apache.activemq.jms.server.recovery.ActiveMQXAResourceRecovery;[connection configuration]"/> <property name="com.arjuna.ats.jta.xaRecoveryNode" value="1"/> </properties> The [connection configuration] contains all the information - required to connect to HornetQ node under the form [connector factory class + required to connect to ActiveMQ node under the form [connector factory class name],[user name], [password], [connector parameters]. [connector factory class name] corresponds to the name - of the ConnectorFactory used to connect to HornetQ. + of the ConnectorFactory used to connect to ActiveMQ. Values can be org.apache.activemq.core.remoting.impl.invm.InVMConnectorFactory or enabled then this must be configured to what ever the tx node id is set to, this is configured in the same file by the com.arjuna.ats.arjuna.xa.nodeIdentifier property. - HornetQ must have a valid acceptor which corresponds to the connector + ActiveMQ must have a valid acceptor which corresponds to the connector specified in conf/jbossts-properties.xml.
Configuration Settings - If HornetQ is configured with a default in-vm acceptor: + If ActiveMQ is configured with a default in-vm acceptor: <acceptor name="in-vm"> <factory-class>org.apache.activemq.core.remoting.impl.invm.InVMAcceptorFactory</factory-class> @@ -1307,8 +1307,8 @@ initialContext = new InitialContext(jndiParameters); the corresponding configuration in conf/jbossts-properties.xml is: -<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.HORNETQ1" - value="org.apache.activemq.jms.server.recovery.HornetQXAResourceRecovery;org.apache.activemq.core.remoting.impl.invm.InVMConnectorFactory"/> +<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.ACTIVEMQ1" + value="org.apache.activemq.jms.server.recovery.ActiveMQXAResourceRecovery;org.apache.activemq.core.remoting.impl.invm.InVMConnectorFactory"/> If it is now configured with a netty acceptor on a non-default port: <acceptor name="netty"> @@ -1318,8 +1318,8 @@ initialContext = new InitialContext(jndiParameters); the corresponding configuration in conf/jbossts-properties.xml is: -<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.HORNETQ1" - value="org.apache.activemq.jms.server.recovery.HornetQXAResourceRecovery;org.apache.activemq.core.remoting.impl.netty.NettyConnectorFactory, , , port=8888"/> +<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.ACTIVEMQ1" + value="org.apache.activemq.jms.server.recovery.ActiveMQXAResourceRecovery;org.apache.activemq.core.remoting.impl.netty.NettyConnectorFactory, , , port=8888"/> Note the additional commas to skip the user and password before connector parameters @@ -1327,9 +1327,9 @@ initialContext = new InitialContext(jndiParameters); If the recovery must use admin, adminpass, the configuration would have been: -<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.HORNETQ1" - value="org.apache.activemq.jms.server.recovery.HornetQXAResourceRecovery;org.apache.activemq.core.remoting.impl.netty.NettyConnectorFactory, admin, adminpass, port=8888"/> - Configuring HornetQ with an invm acceptor and configuring the Recovery Manager +<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.ACTIVEMQ1" + value="org.apache.activemq.jms.server.recovery.ActiveMQXAResourceRecovery;org.apache.activemq.core.remoting.impl.netty.NettyConnectorFactory, admin, adminpass, port=8888"/> + Configuring ActiveMQ with an invm acceptor and configuring the Recovery Manager with an invm connector is the recommended way to enable XA Recovery.
diff --git a/docs/user-manual/en/architecture.xml b/docs/user-manual/en/architecture.xml index 8b7085cba7..21089003b4 100644 --- a/docs/user-manual/en/architecture.xml +++ b/docs/user-manual/en/architecture.xml @@ -18,29 +18,29 @@ + %BOOK_ENTITIES; ]> Architecture - In this section we will give an overview of the HornetQ high level architecture. + In this section we will give an overview of the ActiveMQ high level architecture.
Core Architecture - HornetQ core is designed simply as set of Plain Old Java Objects (POJOs) - we hope you + ActiveMQ core is designed simply as set of Plain Old Java Objects (POJOs) - we hope you like its clean-cut design. We've also designed it to have as few dependencies on external jars as possible. In - fact, HornetQ core has only one jar dependency, netty.jar, + fact, ActiveMQ core has only one jar dependency, netty.jar, other than the standard JDK classes! This is because we use some of the netty buffer classes internally. - This allows HornetQ to be easily embedded in your own project, or instantiated in any + This allows ActiveMQ to be easily embedded in your own project, or instantiated in any dependency injection framework such as JBoss Microcontainer, Spring or Google Guice. - Each HornetQ server has its own ultra high performance persistent journal, which it + Each ActiveMQ server has its own ultra high performance persistent journal, which it uses for message and other persistence. Using a high performance journal allows outrageous persistence message performance, something not achievable when using a relational database for persistence. - HornetQ clients, potentially on different physical machines interact with the HornetQ - server. HornetQ currently provides two APIs for messaging at the client side: + ActiveMQ clients, potentially on different physical machines interact with the ActiveMQ + server. ActiveMQ currently provides two APIs for messaging at the client side: @@ -55,35 +55,35 @@ JMS semantics are implemented by a thin JMS facade layer on the client side. - The HornetQ server does not speak JMS and in fact does not know anything about JMS, + The ActiveMQ server does not speak JMS and in fact does not know anything about JMS, it is a protocol agnostic messaging server designed to be used with multiple different protocols. When a user uses the JMS API on the client side, all JMS interactions are translated - into operations on the HornetQ core client API before being transferred over the wire - using the HornetQ wire format. + into operations on the ActiveMQ core client API before being transferred over the wire + using the ActiveMQ wire format. The server always just deals with core API interactions. A schematic illustrating this relationship is shown in figure 3.1 below: - Figure 3.1 shows two user applications interacting with a HornetQ server. User + Figure 3.1 shows two user applications interacting with a ActiveMQ server. User Application 1 is using the JMS API, while User Application 2 is using the core client API directly. You can see from the diagram that the JMS API is implemented by a thin facade layer on the client side.
- HornetQ embedded in your own application - HornetQ core is designed as a set of simple POJOs so if you have an application that + ActiveMQ embedded in your own application + ActiveMQ core is designed as a set of simple POJOs so if you have an application that requires messaging functionality internally but you don't want to expose that as a - HornetQ server you can directly instantiate and embed HornetQ servers in your own + ActiveMQ server you can directly instantiate and embed ActiveMQ servers in your own application. - For more information on embedding HornetQ, see For more information on embedding ActiveMQ, see .
- HornetQ integrated with a JEE application server - HornetQ provides its own fully functional Java Connector Architecture (JCA) adaptor + ActiveMQ integrated with a JEE application server + ActiveMQ provides its own fully functional Java Connector Architecture (JCA) adaptor which enables it to be integrated easily into any JEE compliant application server or servlet engine. JEE application servers provide Message Driven Beans (MDBs), which are a special type @@ -106,12 +106,12 @@ an EJB, MDB or servlet without going through a JCA adapter, but this is not recommended since you will not be able to take advantage of the JCA features, such as caching of JMS sessions, which can result in poor performance. - Figure 3.2 below shows a JEE application server integrating with a HornetQ server via - the HornetQ JCA adaptor. Note that all communication between EJB sessions or entity + Figure 3.2 below shows a JEE application server integrating with a ActiveMQ server via + the ActiveMQ JCA adaptor. Note that all communication between EJB sessions or entity beans and Message Driven beans go through the adaptor and not directly to - HornetQ. + ActiveMQ. The large arrow with the prohibited sign shows an EJB session bean talking directly to - the HornetQ server. This is not recommended as you'll most likely end up creating a new + the ActiveMQ server. This is not recommended as you'll most likely end up creating a new connection and session every time you want to interact from the EJB, which is an anti-pattern. @@ -121,22 +121,22 @@ linkend="appserver-integration"/>.
- HornetQ stand-alone server - HornetQ can also be deployed as a stand-alone server. This means a fully independent + ActiveMQ stand-alone server + ActiveMQ can also be deployed as a stand-alone server. This means a fully independent messaging server not dependent on a JEE application server. The standard stand-alone messaging server configuration comprises a core messaging server, a JMS service and a JNDI service. The role of the JMS Service is to deploy any JMS Queue, Topic and ConnectionFactory - instances from any server side hornetq-jms.xml configuration files. + instances from any server side activemq-jms.xml configuration files. It also provides a simple management API for creating and destroying Queues, Topics and ConnectionFactory instances which can be accessed via JMX or the connection. It is a - separate service to the HornetQ core server, since the core server is JMS agnostic. If + separate service to the ActiveMQ core server, since the core server is JMS agnostic. If you don't want to deploy any JMS Queue, Topic or ConnectionFactory instances via server side XML configuration and don't require a JMS management API on the server side then you can disable this service. We also include a JNDI server since JNDI is a common requirement when using JMS to lookup Queues, Topics and ConnectionFactory instances. If you do not require JNDI then - this service can also be disabled. HornetQ allows you to programmatically create JMS and + this service can also be disabled. ActiveMQ allows you to programmatically create JMS and core objects directly on the client side as opposed to looking them up from JNDI, so a JNDI server is not always a requirement. The stand-alone server configuration uses JBoss Microcontainer to instantiate and diff --git a/docs/user-manual/en/client-classpath.xml b/docs/user-manual/en/client-classpath.xml index be94909c57..798e6bbaa9 100644 --- a/docs/user-manual/en/client-classpath.xml +++ b/docs/user-manual/en/client-classpath.xml @@ -18,30 +18,30 @@ + %BOOK_ENTITIES; ]> The Client Classpath - HornetQ requires several jars on the Client Classpath depending on - whether the client uses HornetQ Core API, JMS, and JNDI. + ActiveMQ requires several jars on the Client Classpath depending on + whether the client uses ActiveMQ Core API, JMS, and JNDI. All the jars mentioned here can be found in the lib directory of - the HornetQ distribution. Be sure you only use the jars from the correct version of the + the ActiveMQ distribution. Be sure you only use the jars from the correct version of the release, you must not mix and match versions of jars from different - HornetQ versions. Mixing and matching different jar versions may cause subtle errors and + ActiveMQ versions. Mixing and matching different jar versions may cause subtle errors and failures to occur.
- HornetQ Core Client - If you are using just a pure HornetQ Core client (i.e. no JMS) then you need hornetq-core-client.jar, hornetq-commons.jar, and + ActiveMQ Core Client + If you are using just a pure ActiveMQ Core client (i.e. no JMS) then you need activemq-core-client.jar, activemq-commons.jar, and netty.jar on your client classpath.
JMS Client If you are using JMS on the client side, then you will also need to include hornetq-jms-client.jar and jboss-jms-api.jar. + >activemq-jms-client.jar and jboss-jms-api.jar. jboss-jms-api.jar just contains Java EE API interface classes @@ -52,7 +52,7 @@
JMS Client with JNDI - If you are looking up JMS resources from the JNDI server co-located with the HornetQ + If you are looking up JMS resources from the JNDI server co-located with the ActiveMQ standalone server, you will also need the jar jnp-client.jar jar on your client classpath as well as any other jars mentioned previously.
diff --git a/docs/user-manual/en/client-reconnection.xml b/docs/user-manual/en/client-reconnection.xml index d647011672..ef99ae44ab 100644 --- a/docs/user-manual/en/client-reconnection.xml +++ b/docs/user-manual/en/client-reconnection.xml @@ -18,12 +18,12 @@ + %BOOK_ENTITIES; ]> Client Reconnection and Session Reattachment - HornetQ clients can be configured to automatically reconnect or re-attach to the server in + ActiveMQ clients can be configured to automatically reconnect or re-attach to the server in the event that a failure is detected in the connection between the client and the server.
100% Transparent session re-attachment @@ -31,11 +31,11 @@ and the target server was not restarted, then the sessions will still be existent on the server, assuming the client hasn't been disconnected for more than connection-ttl . - In this scenario, HornetQ will automatically re-attach the client sessions to the + In this scenario, ActiveMQ will automatically re-attach the client sessions to the server sessions when the connection reconnects. This is done 100% transparently and the client can continue exactly as if nothing had happened. The way this works is as follows: - As HornetQ clients send commands to their servers they store each sent command in an + As ActiveMQ clients send commands to their servers they store each sent command in an in-memory buffer. In the case that connection failure occurs and the client subsequently reattaches to the same server, as part of the reattachment protocol the server informs the client during reattachment with the id of the last command it successfully received @@ -49,9 +49,9 @@ and the client can then free up space in the buffer. If you are using JMS and you're using the JMS service on the server to load your JMS connection factory instances into JNDI then this parameter can be configured in hornetq-jms.xml using the element activemq-jms.xml using the element confirmation-window-size a. If you're using JMS but not using JNDI then - you can set these values directly on the HornetQConnectionFactory + you can set these values directly on the ActiveMQConnectionFactory instance using the appropriate setter method. If you're using the core API you can set these values directly on the ServerLocator instance using the appropriate setter method. @@ -65,7 +65,7 @@ Alternatively, the server might have actually been restarted after crashing or being stopped. In this case any sessions will no longer be existent on the server and it won't be possible to 100% transparently re-attach to them. - In this case, HornetQ will automatically reconnect the connection and In this case, ActiveMQ will automatically reconnect the connection and recreate any sessions and consumers on the server corresponding to the sessions and consumers on the client. This process is exactly the same as what happens during failover onto a backup server. @@ -118,7 +118,7 @@ If you're using JMS, and you're using the JMS Service on the server to load your JMS connection factory instances directly into JNDI, then you can specify these parameters - in the xml configuration in hornetq-jms.xml, for example: + in the xml configuration in activemq-jms.xml, for example: <connection-factory name="ConnectionFactory"> <connectors> @@ -135,7 +135,7 @@ </connection-factory> If you're using JMS, but instantiating your JMS connection factory directly, you can specify the parameters using the appropriate setter methods on the HornetQConnectionFactory immediately after creating it. + >ActiveMQConnectionFactory immediately after creating it. If you're using the core API and instantiating the ServerLocator instance directly you can also specify the parameters using the appropriate setter methods on the + %BOOK_ENTITIES; ]> Clusters
Clusters Overview - HornetQ clusters allow groups of HornetQ servers to be grouped together in order to - share message processing load. Each active node in the cluster is an active HornetQ + ActiveMQ clusters allow groups of ActiveMQ servers to be grouped together in order to + share message processing load. Each active node in the cluster is an active ActiveMQ server which manages its own messages and handles its own connections. The clustered parameter is deprecated and no longer needed for @@ -35,7 +35,7 @@ The cluster is formed by each node declaring cluster connections to other nodes in the core configuration file hornetq-configuration.xml. When a node forms a cluster connection to + >activemq-configuration.xml. When a node forms a cluster connection to another node, internally it creates a core bridge (as described in ) connection between it and the other node, this is done transparently behind the scenes - you don't have to declare an explicit bridge for @@ -44,7 +44,7 @@ Nodes can be connected together to form a cluster in many different topologies, we will discuss a couple of the more common topologies later in this chapter. We'll also discuss client side load balancing, where we can balance client connections - across the nodes of the cluster, and we'll consider message redistribution where HornetQ + across the nodes of the cluster, and we'll consider message redistribution where ActiveMQ will redistribute messages between nodes to avoid starvation. Another important part of clustering is server discovery where servers can broadcast their connection details so clients or other servers can connect @@ -52,7 +52,7 @@ Once a cluster node has been configured it is common to simply copy that configuration to other nodes to produce a symmetric cluster. However, care must be taken when copying the - HornetQ files. Do not copy the HornetQ data (i.e. the + ActiveMQ files. Do not copy the ActiveMQ data (i.e. the bindings, journal, and large-messages directories) from one node to another. When a node is started for the first time and initializes its journal files it also persists a special identifier to the journal @@ -78,7 +78,7 @@ - This information, let's call it the Cluster Topology, is actually sent around normal HornetQ + This information, let's call it the Cluster Topology, is actually sent around normal ActiveMQ connections to clients and to other servers over cluster connections. This being the case we need a way of establishing the initial first connection. This can be done using dynamic discovery techniques like UDP @@ -102,11 +102,11 @@ the network. Depending on which broadcasting technique you configure the cluster, it uses either UDP or JGroups to broadcast connector pairs information. Broadcast groups are defined in the server configuration file hornetq-configuration.xml. There can be many broadcast groups per - HornetQ server. All broadcast groups must be defined in a activemq-configuration.xml. There can be many broadcast groups per + ActiveMQ server. All broadcast groups must be defined in a broadcast-groups element. Let's take a look at an example broadcast group from hornetq-configuration.xml that defines a UDP broadcast group: + >activemq-configuration.xml that defines a UDP broadcast group: <broadcast-groups> <broadcast-group name="my-broadcast-group"> @@ -171,7 +171,7 @@ <broadcast-groups> <broadcast-group name="my-broadcast-group"> <jgroups-file>test-jgroups-file_ping.xml</jgroups-file> - <jgroups-channel>hornetq_broadcast_channel</jgroups-channel> + <jgroups-channel>activemq_broadcast_channel</jgroups-channel> <broadcast-period>2000</broadcast-period> <connector-ref connector-name="netty-connector"/> </broadcast-group> @@ -183,7 +183,7 @@ jgroups-file attribute. This is the name of JGroups configuration file. It will be used to initialize JGroups channels. Make sure the file is in the - java resource path so that HornetQ can load it. + java resource path so that ActiveMQ can load it. jgroups-channel attribute. The name that JGroups channels connect @@ -251,7 +251,7 @@ </config> - As it shows, the file content defines a jgroups protocol stacks. If you want hornetq + As it shows, the file content defines a jgroups protocol stacks. If you want activemq to use this stacks for channel creation, you have to make sure the value of jgroups-file in your broadcast-group/discovery-group configuration to be the name of this jgroups configuration file. For example if the above stacks @@ -271,7 +271,7 @@ particular server it updates its entry in the list for that server. If it has not received a broadcast from a particular server for a length of time it will remove that server's entry from its list. - Discovery groups are used in two places in HornetQ: + Discovery groups are used in two places in ActiveMQ: By cluster connections so they know how to obtain an initial connection to download the topology @@ -283,7 +283,7 @@ Although a discovery group will always accept broadcasts, its current list of available live and backup servers is only ever used when an initial connection is made, from then server discovery is - done over the normal HornetQ connections. + done over the normal ActiveMQ connections. @@ -296,9 +296,9 @@
Defining Discovery Groups on the Server For cluster connections, discovery groups are defined in the server side - configuration file hornetq-configuration.xml. All discovery + configuration file activemq-configuration.xml. All discovery groups must be defined inside a discovery-groups element. There - can be many discovery groups defined by HornetQ server. Let's look at an + can be many discovery groups defined by ActiveMQ server. Let's look at an example: <discovery-groups> @@ -348,7 +348,7 @@ <discovery-groups> <discovery-group name="my-broadcast-group"> <jgroups-file>test-jgroups-file_ping.xml</jgroups-file> - <jgroups-channel>hornetq_broadcast_channel</jgroups-channel> + <jgroups-channel>activemq_broadcast_channel</jgroups-channel> <refresh-timeout>10000</refresh-timeout> </discovery-group> </discovery-groups> @@ -359,7 +359,7 @@ jgroups-file attribute. This is the name of JGroups configuration file. It will be used to initialize JGroups channels. Make sure the file is in the - java resource path so that HornetQ can load it. + java resource path so that ActiveMQ can load it. jgroups-channel attribute. The name that JGroups channels connect @@ -374,7 +374,7 @@
Discovery Groups on the Client Side - Let's discuss how to configure a HornetQ client to use discovery to discover a + Let's discuss how to configure a ActiveMQ client to use discovery to discover a list of servers to which it can connect. The way to do this differs depending on whether you're using JMS or the core API.
@@ -382,7 +382,7 @@ If you're using JMS and you're also using the JMS Service on the server to load your JMS connection factory instances into JNDI, then you can specify which discovery group to use for your JMS connection factory in the server side xml - configuration hornetq-jms.xml. Let's take a look at an + configuration activemq-jms.xml. Let's take a look at an example: <connection-factory name="ConnectionFactory"> @@ -392,7 +392,7 @@ </entries> </connection-factory> The element discovery-group-ref specifies the name of a - discovery group defined in hornetq-configuration.xml. + discovery group defined in activemq-configuration.xml. When this connection factory is downloaded from JNDI by a client application and JMS connections are created from it, those connections will be load-balanced across the list of servers that the discovery group maintains by listening on @@ -408,7 +408,7 @@ final String groupAddress = "231.7.7.7"; final int groupPort = 9876; ConnectionFactory jmsConnectionFactory = -HornetQJMSClient.createConnectionFactory(new DiscoveryGroupConfiguration(groupAddress, groupPort, +ActiveMQJMSClient.createConnectionFactory(new DiscoveryGroupConfiguration(groupAddress, groupPort, new UDPBroadcastGroupConfiguration(groupAddress, groupPort, null, -1)), JMSFactoryType.CF); Connection jmsConnection1 = jmsConnectionFactory.createConnection(); @@ -434,7 +434,7 @@ Connection jmsConnection2 = jmsConnectionFactory.createConnection(); final String groupAddress = "231.7.7.7"; final int groupPort = 9876; -ServerLocator factory = HornetQClient.createServerLocatorWithHA(new DiscoveryGroupConfiguration(groupAddress, groupPort, +ServerLocator factory = ActiveMQClient.createServerLocatorWithHA(new DiscoveryGroupConfiguration(groupAddress, groupPort, new UDPBroadcastGroupConfiguration(groupAddress, groupPort, null, -1)))); ClientSessionFactory factory = locator.createSessionFactory(); ClientSession session1 = factory.createSession(); @@ -475,7 +475,7 @@ ClientSession session2 = factory.createSession(); If you're using JMS and you're also using the JMS Service on the server to load your JMS connection factory instances into JNDI, then you can specify which connectors to use for your JMS connection factory in the server side xml - configuration hornetq-jms.xml. Let's take a look at an + configuration activemq-jms.xml. Let's take a look at an example: <connection-factory name="ConnectionFactory"> @@ -490,7 +490,7 @@ ClientSession session2 = factory.createSession(); </connection-factory> The element connectors contains a list of pre defined connectors in the - hornetq-configuration.xml file. When this connection factory is downloaded + activemq-configuration.xml file. When this connection factory is downloaded from JNDI by a client application and JMS connections are created from it, those connections will be load-balanced across the list of servers defined by these connectors. @@ -509,7 +509,7 @@ map2.put("host", "myhost2"); map2.put("port", "5446"); TransportConfiguration server2 = new TransportConfiguration(NettyConnectorFactory.class.getName(), map2); -HornetQConnectionFactory cf = HornetQJMSClient.createConnectionFactoryWithHA(JMSFactoryType.CF, server1, server2); +ActiveMQConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithHA(JMSFactoryType.CF, server1, server2);
Configuring client discovery using Core @@ -524,7 +524,7 @@ map2.put("host", "myhost2"); map2.put("port", "5446"); TransportConfiguration server2 = new TransportConfiguration(NettyConnectorFactory.class.getName(), map2); -ServerLocator locator = HornetQClient.createServerLocatorWithHA(server1, server2); +ServerLocator locator = ActiveMQClient.createServerLocatorWithHA(server1, server2); ClientSessionFactory factory = locator.createSessionFactory(); ClientSession session = factory.createSession();
@@ -533,7 +533,7 @@ ClientSession session = factory.createSession();
Server-Side Message Load Balancing - If cluster connections are defined between nodes of a cluster, then HornetQ will load + If cluster connections are defined between nodes of a cluster, then ActiveMQ will load balance messages arriving at a particular node from a client. Let's take a simple example of a cluster of four nodes A, B, C, and D arranged in a symmetric cluster (described in @@ -552,7 +552,7 @@ ClientSession session = factory.createSession(); For example, messages arriving on node A might be distributed in the following order between the nodes: B, D, C, A, B, D, C, A, B, D. The exact order depends on the order the nodes started up, but the algorithm used is round robin. - HornetQ cluster connections can be configured to always blindly load balance messages + ActiveMQ cluster connections can be configured to always blindly load balance messages in a round robin fashion irrespective of whether there are any matching consumers on other nodes, but they can be a bit cleverer than that and also be configured to only distribute to other nodes if they have matching consumers. We'll look at both these @@ -563,9 +563,9 @@ ClientSession session = factory.createSession(); Cluster connections group servers into clusters so that messages can be load balanced between the nodes of the cluster. Let's take a look at a typical cluster connection. Cluster connections are always defined in hornetq-configuration.xml inside a activemq-configuration.xml inside a cluster-connection element. There can be zero or more cluster - connections defined per HornetQ server. + connections defined per ActiveMQ server. <cluster-connections> <cluster-connection name="my-cluster"> @@ -607,7 +607,7 @@ ClientSession session = factory.createSession(); with different values of address, simultaneously balancing messages for those addresses, potentially to different clusters of servers. By having multiple cluster connections on different addresses a - single HornetQ Server can effectively take part in multiple clusters + single ActiveMQ Server can effectively take part in multiple clusters simultaneously. Be careful not to have multiple cluster connections with overlapping values of address, e.g. "europe" and "europe.news" since @@ -708,11 +708,11 @@ ClientSession session = factory.createSession(); If this is set to true then each incoming message will be round robin'd even though the same queues on the other nodes of the cluster may have no consumers at all, or they may have consumers that have - non matching message filters (selectors). Note that HornetQ will + non matching message filters (selectors). Note that ActiveMQ will not forward messages to other nodes if there are no queues of the same name on the other nodes, even if this parameter is set to true. - If this is set to false then HornetQ will only forward + If this is set to false then ActiveMQ will only forward messages to other nodes of the cluster if the address to which they are being forwarded has queues which have consumers, and if those consumers have message filters (selectors) at least one of those selectors must match the @@ -722,15 +722,15 @@ ClientSession session = factory.createSession(); max-hops. When a cluster connection decides the set of nodes to which it might load balance a message, those nodes do not have to - be directly connected to it via a cluster connection. HornetQ can be + be directly connected to it via a cluster connection. ActiveMQ can be configured to also load balance messages to nodes which might be connected - to it only indirectly with other HornetQ servers as intermediates in a + to it only indirectly with other ActiveMQ servers as intermediates in a chain. - This allows HornetQ to be configured in more complex topologies and still + This allows ActiveMQ to be configured in more complex topologies and still provide message load balancing. We'll discuss this more later in this chapter. The default value for this parameter is 1, which means - messages are only load balanced to other HornetQ serves which are directly + messages are only load balanced to other ActiveMQ serves which are directly connected to this server. This parameter is optional. @@ -777,26 +777,26 @@ ClientSession session = factory.createSession();
Cluster User Credentials When creating connections between nodes of a cluster to form a cluster connection, - HornetQ uses a cluster user and cluster password which is defined in hornetq-configuration.xml: + ActiveMQ uses a cluster user and cluster password which is defined in activemq-configuration.xml: -<cluster-user>HORNETQ.CLUSTER.ADMIN.USER</cluster-user> +<cluster-user>ACTIVEMQ.CLUSTER.ADMIN.USER</cluster-user> <cluster-password>CHANGE ME!!</cluster-password> It is imperative that these values are changed from their default, or remote clients will be able to make connections to the server using the default values. - If they are not changed from the default, HornetQ will detect this and pester + If they are not changed from the default, ActiveMQ will detect this and pester you with a warning on every start-up.
Client-Side Load balancing - With HornetQ client-side load balancing, subsequent sessions created using a single + With ActiveMQ client-side load balancing, subsequent sessions created using a single session factory can be connected to different nodes of the cluster. This allows sessions to spread smoothly across the nodes of a cluster and not be "clumped" on any particular node. - The load balancing policy to be used by the client factory is configurable. HornetQ + The load balancing policy to be used by the client factory is configurable. ActiveMQ provides four out-of-the-box load balancing policies, and you can also implement your own and use that. The out-of-the-box policies are @@ -833,7 +833,7 @@ ClientSession session = factory.createSession(); >org.apache.activemq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy. If you're using JMS, and you're using JNDI on the server to put your JMS connection factories into JNDI, then you can specify the load balancing policy directly in the - hornetq-jms.xml configuration file on the server as follows: + activemq-jms.xml configuration file on the server as follows: <connection-factory name="ConnectionFactory"> <discovery-group-ref discovery-group-name="my-discovery-group"/> @@ -848,14 +848,14 @@ ClientSession session = factory.createSession(); balancing policy. If you're using JMS but you're instantiating your connection factory directly on the client side then you can set the load balancing policy using the setter on the - HornetQConnectionFactory before using it: + ActiveMQConnectionFactory before using it: -ConnectionFactory jmsConnectionFactory = HornetQJMSClient.createConnectionFactory(...); +ConnectionFactory jmsConnectionFactory = ActiveMQJMSClient.createConnectionFactory(...); jmsConnectionFactory.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy"); If you're using the core API, you can set the load balancing policy directly on the ServerLocator instance you are using: -ServerLocator locator = HornetQClient.createServerLocatorWithHA(server1, server2); +ServerLocator locator = ActiveMQClient.createServerLocatorWithHA(server1, server2); locator.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy"); The set of servers over which the factory load balances can be determined in one of two ways: @@ -904,7 +904,7 @@ locator.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy");starvation situation. - This is where message redistribution comes in. With message redistribution HornetQ can + This is where message redistribution comes in. With message redistribution ActiveMQ can be configured to automatically redistribute messages from queues which have no consumers back to other nodes in the cluster which do have matching consumers. @@ -915,7 +915,7 @@ locator.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy");Message redistribution can be configured on a per address basis, by specifying the redistribution delay in the address settings, for more information on configuring address settings, please see . - Here's an address settings snippet from hornetq-configuration.xml + Here's an address settings snippet from activemq-configuration.xml showing how message redistribution is enabled for a set of queues: <address-settings> @@ -929,7 +929,7 @@ locator.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy"); The attribute match can be an exact match or it can be a string - that conforms to the HornetQ wildcard syntax (described in ). The element redistribution-delay defines the delay in milliseconds after the last consumer is closed on a queue before redistributing messages from that @@ -944,7 +944,7 @@ locator.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy");
Cluster topologies - HornetQ clusters can be connected together in many different topologies, let's + ActiveMQ clusters can be connected together in many different topologies, let's consider the two most common ones here
Symmetric cluster @@ -994,11 +994,11 @@ locator.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy");
Scaling Down - HornetQ supports scaling down a cluster with no message loss (even for non-durable messages). This is especially + ActiveMQ supports scaling down a cluster with no message loss (even for non-durable messages). This is especially useful in certain environments (e.g. the cloud) where the size of a cluster may change relatively frequently. When scaling up a cluster (i.e. adding nodes) there is no risk of message loss, but when scaling down a cluster (i.e. removing nodes) the messages on those nodes would be lost unless the broker sent them to another node in - the cluster. HornetQ can be configured to do just that. + the cluster. ActiveMQ can be configured to do just that. The simplest way to enable this behavior is to set scale-down to true. If the server is clustered and scale-down is true then when the server is shutdown gracefully (i.e. stopped without crashing) it will find diff --git a/docs/user-manual/en/configuration-index.xml b/docs/user-manual/en/configuration-index.xml index 9e6cf84f12..fb08c55260 100644 --- a/docs/user-manual/en/configuration-index.xml +++ b/docs/user-manual/en/configuration-index.xml @@ -18,7 +18,7 @@ + %BOOK_ENTITIES; ]> @@ -28,7 +28,7 @@
Server Configuration
- hornetq-configuration.xml + activemq-configuration.xml This is the main core server configuration file.
Server Configuration @@ -54,7 +54,7 @@
- hornetq-jms.xml + activemq-jms.xml This is the configuration file used by the server side JMS service to load JMS Queues, Topics and Connection Factories. @@ -436,16 +436,16 @@
Using Masked Passwords in Configuration Files - By default all passwords in HornetQ server's configuration files are in plain text form. This usually poses no security issues as those + By default all passwords in ActiveMQ server's configuration files are in plain text form. This usually poses no security issues as those files should be well protected from unauthorized accessing. However, in some circumstances a user doesn't want to expose its passwords to more eyes than necessary. - HornetQ can be configured to use 'masked' passwords in its configuration files. A masked password is an obscure string representation + ActiveMQ can be configured to use 'masked' passwords in its configuration files. A masked password is an obscure string representation of a real password. To mask a password a user will use an 'encoder'. The encoder takes in the real password and outputs the masked version. A user can then replace the real password in the configuration files with the new masked password. - When HornetQ loads a masked password, it uses a suitable 'decoder' to decode it into real password. + When ActiveMQ loads a masked password, it uses a suitable 'decoder' to decode it into real password. - HornetQ provides a default password encoder and decoder. Optionally users can use or implement their own encoder and decoder for + ActiveMQ provides a default password encoder and decoder. Optionally users can use or implement their own encoder and decoder for masking the passwords.
Password Masking in Server Configuration File @@ -472,9 +472,9 @@ if a users wants to use an SSL-enabled NettyAcceptor, it can specify a key-store-password and a trust-store-password. Because Acceptors and Connectors are pluggable implementations, each transport will have different password masking needs. - When a Connector or Acceptor configuration is initialised, HornetQ will add the "mask-password" and - "password-codec" values to the Connector or Acceptors params using the keys hornetq.usemaskedpassword - and hornetq.passwordcodec respectively. The Netty and InVM implementations will use these + When a Connector or Acceptor configuration is initialised, ActiveMQ will add the "mask-password" and + "password-codec" values to the Connector or Acceptors params using the keys activemq.usemaskedpassword + and activemq.passwordcodec respectively. The Netty and InVM implementations will use these as needed and any other implementations will have access to these to use if they so wish.
@@ -543,7 +543,7 @@ <mask-password>true</mask-password> <cluster-password>80cf731af62c290</cluster-password> - This indicates the cluster password is a masked value and HornetQ will use its built-in decoder to decode it. All other + This indicates the cluster password is a masked value and ActiveMQ will use its built-in decoder to decode it. All other passwords in the configuration file, Connectors, Acceptors and Bridges, will also use masked passwords.
@@ -565,12 +565,12 @@ <property name="passwordCodec">com.foo.FooDecoder;key=value</property> - HornetQ will load this property and initialize the class with a parameter map containing the "key"->"value" pair. + ActiveMQ will load this property and initialize the class with a parameter map containing the "key"->"value" pair. If passwordCodec is not specified, the built-in decoder is used. -
Masking passwords in HornetQ ResourceAdapters and MDB activation configurations +
Masking passwords in ActiveMQ ResourceAdapters and MDB activation configurations Both ra.xml and MDB activation configuration have a 'password' property that can be masked. They are controlled by the following two optional Resource Adapter properties in ra.xml: @@ -596,9 +596,9 @@
-
Masking passwords in hornetq-users.xml +
Masking passwords in activemq-users.xml - HornetQ's built-in security manager uses plain configuration files where the user passwords are specified in plaintext + ActiveMQ's built-in security manager uses plain configuration files where the user passwords are specified in plaintext forms by default. To mask those parameters the following two properties are needed: mask-password -- If set to "true" all the passwords are masked. Default is false. @@ -610,7 +610,7 @@ <mask-password>true</mask-password> <password-codec>org.apache.activemq.utils.DefaultSensitiveStringCodec;key=hello world</password-codec> - When so configured, the HornetQ security manager will initialize a DefaultSensitiveStringCodec with the parameters + When so configured, the ActiveMQ security manager will initialize a DefaultSensitiveStringCodec with the parameters "key"->"hello world", then use it to decode all the masked passwords in this configuration file.
@@ -621,7 +621,7 @@ convert a masked password into its original clear text form in order to be used in various security operations. The algorithm used for decoding must match that for encoding. Otherwise the decoding may not be successful. - For user's convenience HornetQ provides a default built-in Decoder. However a user can if they so wish implement their own. + For user's convenience ActiveMQ provides a default built-in Decoder. However a user can if they so wish implement their own.
The built-in Decoder @@ -644,7 +644,7 @@ Encoded password: 80cf731af62c290
Using a different decoder It is possible to use a different decoder rather than the built-in one. Simply make sure the decoder - is in HornetQ's classpath and configure the server to use it as follows: + is in ActiveMQ's classpath and configure the server to use it as follows: <password-codec>com.foo.SomeDecoder;key1=value1;key2=value2</password-codec> @@ -661,7 +661,7 @@ Encoded password: 80cf731af62c290 <mask-password>true</mask-password> <cluster-password>masked_password</cluster-password> - When HornetQ reads the cluster-password it will initialize the NewDecoder and use it to decode "mask_password". + When ActiveMQ reads the cluster-password it will initialize the NewDecoder and use it to decode "mask_password". It also process all passwords using the new defined decoder.
@@ -696,7 +696,7 @@ public class MyNewDecoder implements SensitiveDataCodec<String> } } - Last but not least, once you get your own decoder, please add it to the classpath. Otherwise HornetQ will + Last but not least, once you get your own decoder, please add it to the classpath. Otherwise ActiveMQ will fail to load it!
diff --git a/docs/user-manual/en/configuring-transports.xml b/docs/user-manual/en/configuring-transports.xml index b3919c314e..68b885067b 100644 --- a/docs/user-manual/en/configuring-transports.xml +++ b/docs/user-manual/en/configuring-transports.xml @@ -18,22 +18,22 @@ + %BOOK_ENTITIES; ]> Configuring the Transport - HornetQ has a fully pluggable and highly flexible transport layer and defines its own + ActiveMQ has a fully pluggable and highly flexible transport layer and defines its own Service Provider Interface (SPI) to make plugging in a new transport provider relatively straightforward. - In this chapter we'll describe the concepts required for understanding HornetQ transports + In this chapter we'll describe the concepts required for understanding ActiveMQ transports and where and how they're configured.
Understanding Acceptors - One of the most important concepts in HornetQ transports is the + One of the most important concepts in ActiveMQ transports is the acceptor. Let's dive straight in and take a look at an acceptor defined in xml in the configuration file hornetq-configuration.xml. + >activemq-configuration.xml. <acceptors> <acceptor name="netty"> @@ -46,7 +46,7 @@ Acceptors are always defined inside an acceptors element. There can be one or more acceptors defined in the acceptors element. There's no upper limit to the number of acceptors per server. - Each acceptor defines a way in which connections can be made to the HornetQ + Each acceptor defines a way in which connections can be made to the ActiveMQ server. In the above example we're defining an acceptor that uses Netty to listen for connections at port @@ -72,7 +72,7 @@ Understanding Connectors Whereas acceptors are used on the server to define how we accept connections, connectors are used by a client to define how it connects to a server. - Let's look at a connector defined in our hornetq-configuration.xml + Let's look at a connector defined in our activemq-configuration.xml file: <connectors> @@ -99,13 +99,13 @@ If you're using JMS and the server side JMS service to instantiate JMS ConnectionFactory instances and bind them in JNDI, then when creating the - HornetQConnectionFactory it needs to know what server + ActiveMQConnectionFactory it needs to know what server that connection factory will create connections to. That's defined by the connector-ref element in the hornetq-jms.xml file on the server side. Let's take a look at a - snipped from a hornetq-jms.xml file that shows a JMS + >activemq-jms.xml file on the server side. Let's take a look at a + snipped from a activemq-jms.xml file that shows a JMS connection factory that references our netty connector defined in our hornetq-configuration.xml file: + >activemq-configuration.xml file: <connection-factory name="ConnectionFactory"> <connectors> @@ -143,7 +143,7 @@ TransportConfiguration transportConfiguration = "org.apache.activemq.core.remoting.impl.netty.NettyConnectorFactory", connectionParams); -ServerLocator locator = HornetQClient.createServerLocatorWithoutHA(transportConfiguration); +ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(transportConfiguration); ClientSessionFactory sessionFactory = locator.createClientSessionFactory(); @@ -152,7 +152,7 @@ ClientSession session = sessionFactory.createSession(...); etc Similarly, if you're using JMS, you can configure the JMS connection factory directly on the client side without having to define a connector on the server side or define a - connection factory in hornetq-jms.xml: + connection factory in activemq-jms.xml: Map<String, Object> connectionParams = new HashMap<String, Object>(); @@ -163,7 +163,7 @@ TransportConfiguration transportConfiguration = "org.apache.activemq.core.remoting.impl.netty.NettyConnectorFactory", connectionParams); -ConnectionFactory connectionFactory = HornetQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration); +ConnectionFactory connectionFactory = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF, transportConfiguration); Connection jmsConnection = connectionFactory.createConnection(); @@ -171,7 +171,7 @@ etc
Configuring the Netty transport - Out of the box, HornetQ currently uses Out of the box, ActiveMQ currently uses Netty, a high performance low level network library. Our Netty transport can be configured in several different ways; to use old (blocking) Java IO, or NIO (non-blocking), also to use straightforward TCP sockets, SSL, or to @@ -179,8 +179,8 @@ etc We believe this caters for the vast majority of transport requirements.
Single Port Support - As of version 2.4 HornetQ now supports using a single port for all protocols, HornetQ will automatically - detect which protocol is being used CORE, AMQP, STOMP or OPENWIRE and use the appropriate HornetQ handler. It will also detect + As of version 2.4 ActiveMQ now supports using a single port for all protocols, ActiveMQ will automatically + detect which protocol is being used CORE, AMQP, STOMP or OPENWIRE and use the appropriate ActiveMQ handler. It will also detect whether protocols such as HTTP or Web Sockets are being used and also use the appropriate decoders It is possible to limit which protocols are supported by using the protocols parameter on the Acceptor like so: @@ -275,7 +275,7 @@ buffer_size = bandwidth * RTT. batch-delay. Before writing packets to the transport, - HornetQ can be configured to batch up writes for a maximum of batch-delay milliseconds. This can increase overall throughput for very small messages. It does so at the expense of an increase in average latency for message transfer. The default value for this property @@ -295,7 +295,7 @@ buffer_size = bandwidth * RTT. nio-remoting-threads. When configured to use NIO, - HornetQ will, by default, use a number of threads equal to three times the + ActiveMQ will, by default, use a number of threads equal to three times the number of cores (or hyper-threads) as reported by Runtime.getRuntime().availableProcessors() for processing incoming packets. If you want to override this value, you can set the number @@ -341,8 +341,8 @@ buffer_size = bandwidth * RTT. authentication). Although this value is configured on the server, it is downloaded and used by the client. If the client needs to use a different path from that set on the server then it can override the server-side setting by either - using the customary "javax.net.ssl.keyStore" system property or the HornetQ-specific - "org.apache.activemq.ssl.keyStore" system property. The HornetQ-specific system property + using the customary "javax.net.ssl.keyStore" system property or the ActiveMQ-specific + "org.apache.activemq.ssl.keyStore" system property. The ActiveMQ-specific system property is useful if another component on client is already making use of the standard, Java system property. @@ -356,8 +356,8 @@ buffer_size = bandwidth * RTT. be configured on the server, it is downloaded and used by the client. If the client needs to use a different password from that set on the server then it can override the server-side setting by either using the customary "javax.net.ssl.keyStorePassword" - system property or the HornetQ-specific "org.apache.activemq.ssl.keyStorePassword" system - property. The HornetQ-specific system property is useful if another component on client + system property or the ActiveMQ-specific "org.apache.activemq.ssl.keyStorePassword" system + property. The ActiveMQ-specific system property is useful if another component on client is already making use of the standard, Java system property. @@ -371,8 +371,8 @@ buffer_size = bandwidth * RTT. trusts. Although this value can be configured on the server, it is downloaded and used by the client. If the client needs to use a different path from that set on the server then it can override the server-side setting by either - using the customary "javax.net.ssl.trustStore" system property or the HornetQ-specific - "org.apache.activemq.ssl.trustStore" system property. The HornetQ-specific system property + using the customary "javax.net.ssl.trustStore" system property or the ActiveMQ-specific + "org.apache.activemq.ssl.trustStore" system property. The ActiveMQ-specific system property is useful if another component on client is already making use of the standard, Java system property. @@ -386,8 +386,8 @@ buffer_size = bandwidth * RTT. downloaded and used by the client. If the client needs to use a different password from that set on the server then it can override the server-side setting by either using the customary "javax.net.ssl.trustStorePassword" - system property or the HornetQ-specific "org.apache.activemq.ssl.trustStorePassword" system - property. The HornetQ-specific system property is useful if another component on client + system property or the ActiveMQ-specific "org.apache.activemq.ssl.trustStorePassword" system + property. The ActiveMQ-specific system property is useful if another component on client is already making use of the standard, Java system property. @@ -420,7 +420,7 @@ buffer_size = bandwidth * RTT. http-enabled. This is now no longer needed as of version 2.4. With single - port support HornetQ will now automatically detect if http is being used and configure itself. + port support ActiveMQ will now automatically detect if http is being used and configure itself. http-client-idle-time. How long a client can be idle @@ -447,7 +447,7 @@ buffer_size = bandwidth * RTT.
Configuring Netty Servlet - As of 2.4 HornetQ Servlet support will be provided via Undertow in Wildfly + As of 2.4 ActiveMQ Servlet support will be provided via Undertow in Wildfly
diff --git a/docs/user-manual/en/connection-ttl.xml b/docs/user-manual/en/connection-ttl.xml index 42359e67ca..ddb886c390 100644 --- a/docs/user-manual/en/connection-ttl.xml +++ b/docs/user-manual/en/connection-ttl.xml @@ -18,17 +18,17 @@ + %BOOK_ENTITIES; ]> Detecting Dead Connections - In this section we will discuss connection time-to-live (TTL) and explain how HornetQ + In this section we will discuss connection time-to-live (TTL) and explain how ActiveMQ deals with crashed clients and clients which have exited without cleanly closing their resources.
Cleaning up Dead Connection Resources on the Server - Before a HornetQ client application exits it is considered good practice that it + Before a ActiveMQ client application exits it is considered good practice that it should close its resources in a controlled manner, using a finally block. Here's an example of a well behaved core client application closing its session and @@ -40,7 +40,7 @@ ClientSession session = null; try { - locator = HornetQClient.createServerLocatorWithoutHA(..); + locator = ActiveMQClient.createServerLocatorWithoutHA(..); sf = locator.createClientSessionFactory();; @@ -71,7 +71,7 @@ Connection jmsConnection = null; try { - ConnectionFactory jmsConnectionFactory = HornetQJMSClient.createConnectionFactoryWithoutHA(...); + ConnectionFactory jmsConnectionFactory = ActiveMQJMSClient.createConnectionFactoryWithoutHA(...); jmsConnection = jmsConnectionFactory.createConnection(); @@ -91,11 +91,11 @@ finally over time this result in the server running out of memory or other resources. We have to balance the requirement for cleaning up dead client resources with the fact that sometimes the network between the client and the server can fail and then come - back, allowing the client to reconnect. HornetQ supports client reconnection, so we + back, allowing the client to reconnect. ActiveMQ supports client reconnection, so we don't want to clean up "dead" server side resources too soon or this will prevent any client from reconnecting, as it won't be able to find its old sessions on the server. - HornetQ makes all of this configurable. For each ActiveMQ makes all of this configurable. For each ClientSessionFactory we define a connection TTL. Basically, the TTL determines how long the server will keep a connection alive in the absence of any data arriving from the client. The client will automatically send "ping" @@ -104,7 +104,7 @@ finally automatically close all the sessions on the server that relate to that connection. If you're using JMS, the connection TTL is defined by the ConnectionTTL attribute on a HornetQConnectionFactory + >ConnectionTTL attribute on a ActiveMQConnectionFactory instance, or if you're deploying JMS connection factory instances direct into JNDI on the server side, you can specify it in the xml config, using the parameter connection-ttl. @@ -124,7 +124,7 @@ finally As previously discussed, it's important that all core client sessions and JMS connections are always closed explicitly in a finally block when you are finished using them. - If you fail to do so, HornetQ will detect this at garbage collection time, and log + If you fail to do so, ActiveMQ will detect this at garbage collection time, and log a warning similar to the following in the logs (If you are using JMS the warning will involve a JMS connection not a client session): @@ -134,7 +134,7 @@ ting them go out of scope! java.lang.Exception at org.apache.activemq.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:83) at org.acme.yourproject.YourClass (YourClass.java:666) - HornetQ will then close the connection / client session for you. + ActiveMQ will then close the connection / client session for you. Note that the log will also tell you the exact line of your user code where you created the JMS connection / client session that you later did not close. This will enable you to pinpoint the error in your code and correct it appropriately. @@ -154,9 +154,9 @@ java.lang.Exception >FailureListener instances (or ExceptionListener instances if you are using JMS) depending on how it has been configured. If you're using JMS it's defined by the ClientFailureCheckPeriod - attribute on a HornetQConnectionFactory instance, or if you're + attribute on a ActiveMQConnectionFactory instance, or if you're deploying JMS connection factory instances direct into JNDI on the server side, you can - specify it in the hornetq-jms.xml configuration file, using the + specify it in the activemq-jms.xml configuration file, using the parameter client-failure-check-period. The default value for client failure check period on an "unreliable" connection (e.g. a Netty connection) is 30000ms, i.e. 30 seconds. The default value @@ -197,7 +197,7 @@ java.lang.Exception To disable asynchronous connection execution, set the parameter async-connection-execution-enabled in - hornetq-configuration.xml to false (default value is + activemq-configuration.xml to false (default value is true).
diff --git a/docs/user-manual/en/core-bridges.xml b/docs/user-manual/en/core-bridges.xml index 408de0200e..97bf4ac999 100644 --- a/docs/user-manual/en/core-bridges.xml +++ b/docs/user-manual/en/core-bridges.xml @@ -18,28 +18,28 @@ + %BOOK_ENTITIES; ]> Core Bridges The function of a bridge is to consume messages from a source queue, and forward them to a - target address, typically on a different HornetQ server. + target address, typically on a different ActiveMQ server. The source and target servers do not have to be in the same cluster which makes bridging suitable for reliably sending messages from one cluster to another, for instance across a WAN, or internet and where the connection may be unreliable. The bridge has built in resilience to failure so if the target server connection is lost, e.g. due to network failure, the bridge will retry connecting to the target until it comes back online. When it comes back online it will resume operation as normal. - In summary, bridges are a way to reliably connect two separate HornetQ servers together. - With a core bridge both source and target servers must be HornetQ servers. + In summary, bridges are a way to reliably connect two separate ActiveMQ servers together. + With a core bridge both source and target servers must be ActiveMQ servers. Bridges can be configured to provide once and only once delivery guarantees even in the event of the failure of the source or the target server. They do this by using duplicate detection (described in ). Although they have similar function, don't confuse core bridges with JMS bridges! - Core bridges are for linking a HornetQ node with another HornetQ node and do not use + Core bridges are for linking a ActiveMQ node with another ActiveMQ node and do not use the JMS API. A JMS Bridge is used for linking any two JMS 1.1 compliant JMS providers. So, a JMS Bridge could be used for bridging to or from different JMS compliant messaging system. It's always preferable to use a core bridge if you can. Core bridges use @@ -49,7 +49,7 @@
Configuring Bridges - Bridges are configured in hornetq-configuration.xml. Let's kick off + Bridges are configured in activemq-configuration.xml. Let's kick off with an example (this is actually from the bridge example): <bridge name="my-bridge"> @@ -92,8 +92,8 @@ start-up. If you're using JMS then normally the JMS configuration hornetq-jms.xml is loaded after the core configuration file - hornetq-configuration.xml is loaded. If your bridge + >activemq-jms.xml is loaded after the core configuration file + activemq-configuration.xml is loaded. If your bridge is consuming from a JMS queue then you'll need to make sure the JMS queue is also deployed as a core queue in the core configuration. Take a look at the bridge example for an example of how this is done. @@ -107,7 +107,7 @@ filter-string. An optional filter string can be supplied. If specified then only messages which match the filter expression specified in - the filter string will be forwarded. The filter string follows the HornetQ + the filter string will be forwarded. The filter string follows the ActiveMQ filter expression syntax described in . @@ -210,13 +210,13 @@ user. This optional parameter determines the user name to use when creating the bridge connection to the remote server. If it is not specified the default cluster user specified by cluster-user - in hornetq-configuration.xml will be used. + in activemq-configuration.xml will be used. password. This optional parameter determines the password to use when creating the bridge connection to the remote server. If it is not specified the default cluster password specified by cluster-password in hornetq-configuration.xml + >cluster-password in activemq-configuration.xml will be used. diff --git a/docs/user-manual/en/diverts.xml b/docs/user-manual/en/diverts.xml index 8d815681a1..178cf48c8a 100644 --- a/docs/user-manual/en/diverts.xml +++ b/docs/user-manual/en/diverts.xml @@ -19,13 +19,13 @@ + %BOOK_ENTITIES; ]> Diverting and Splitting Message Flows - HornetQ allows you to configure objects called diverts with + ActiveMQ allows you to configure objects called diverts with some simple server configuration. Diverts allow you to transparently divert messages routed to one address to some other address, without making any changes to any client application logic. @@ -49,7 +49,7 @@ thought of as a type of routing table for messages. Combining diverts with bridges allows you to create a distributed network of reliable routing connections between multiple geographically distributed servers, creating your global messaging mesh. - Diverts are defined as xml in the hornetq-configuration.xml file. There can + Diverts are defined as xml in the activemq-configuration.xml file. There can be zero or more diverts in the file. Please see for a full working example showing you how to configure and use diverts. @@ -86,7 +86,7 @@ change the messages body or properties before it is diverted. In this example the transformer simply adds a header that records the time the divert happened. This example is actually diverting messages to a local store and forward queue, which - is configured with a bridge which forwards the message to an address on another HornetQ + is configured with a bridge which forwards the message to an address on another ActiveMQ server. Please see the example for more details.
diff --git a/docs/user-manual/en/duplicate-detection.xml b/docs/user-manual/en/duplicate-detection.xml index 97c7a6410f..9da24e36a2 100644 --- a/docs/user-manual/en/duplicate-detection.xml +++ b/docs/user-manual/en/duplicate-detection.xml @@ -19,15 +19,15 @@ + %BOOK_ENTITIES; ]> Duplicate Message Detection - HornetQ includes powerful automatic duplicate message detection, filtering out + ActiveMQ includes powerful automatic duplicate message detection, filtering out duplicate messages without you having to code your own fiddly duplicate detection logic at - the application level. This chapter will explain what duplicate detection is, how HornetQ + the application level. This chapter will explain what duplicate detection is, how ActiveMQ uses it and how and where to configure it. When sending messages from a client to a server, or indeed from a server to another server, if the target server or connection fails sometime after sending the message, but @@ -48,7 +48,7 @@ Sending the message(s) in a transaction does not help out either. If the server or connection fails while the transaction commit is being processed it is also indeterminate whether the transaction was successfully committed or not! - To solve these issues HornetQ provides automatic duplicate messages detection for + To solve these issues ActiveMQ provides automatic duplicate messages detection for messages sent to addresses.
Using Duplicate Detection for Message Sending @@ -107,11 +107,11 @@ message.setStringProperty(HDR_DUPLICATE_DETECTION_ID.toString(), myUniqueID); >n elements, then the n + 1th id stored will overwrite the 0th element in the cache. The maximum size of the cache is configured by the parameter id-cache-size in hornetq-configuration.xml, the default + >id-cache-size in activemq-configuration.xml, the default value is 2000 elements. The caches can also be configured to persist to disk or not. This is configured by the parameter persist-id-cache, also in hornetq-configuration.xml. If this is set to true then + >activemq-configuration.xml. If this is set to true then each id will be persisted to permanent storage as they are received. The default value for this parameter is true. @@ -129,7 +129,7 @@ message.setStringProperty(HDR_DUPLICATE_DETECTION_ID.toString(), myUniqueID); it will be ignored. To configure a core bridge to add the duplicate id header, simply set the use-duplicate-detection to true when configuring a - bridge in hornetq-configuration.xml. + bridge in activemq-configuration.xml. The default value for this parameter is true. For more information on core bridges and how to configure them, please see . @@ -141,7 +141,7 @@ message.setStringProperty(HDR_DUPLICATE_DETECTION_ID.toString(), myUniqueID); id header for each message they move using their internal bridges. To configure a cluster connection to add the duplicate id header, simply set the use-duplicate-detection to true when - configuring a cluster connection in hornetq-configuration.xml. + configuring a cluster connection in activemq-configuration.xml. The default value for this parameter is true. For more information on cluster connections and how to configure them, please see . diff --git a/docs/user-manual/en/embedding-hornetq.xml b/docs/user-manual/en/embedding-activemq.xml similarity index 76% rename from docs/user-manual/en/embedding-hornetq.xml rename to docs/user-manual/en/embedding-activemq.xml index 3b8e421981..e41ca8a628 100644 --- a/docs/user-manual/en/embedding-hornetq.xml +++ b/docs/user-manual/en/embedding-activemq.xml @@ -20,52 +20,52 @@ + %BOOK_ENTITIES; ]> - - Embedding HornetQ + + Embedding ActiveMQ - HornetQ is designed as set of simple Plain Old Java Objects (POJOs). - This means HornetQ can be instantiated and run in any dependency injection + ActiveMQ is designed as set of simple Plain Old Java Objects (POJOs). + This means ActiveMQ can be instantiated and run in any dependency injection framework such as JBoss Microcontainer, Spring or Google Guice. It also means that if you have an application that could use messaging functionality - internally, then it can directly instantiate HornetQ + internally, then it can directly instantiate ActiveMQ clients and servers in its own application code to perform that - functionality. We call this embedding HornetQ. + functionality. We call this embedding ActiveMQ. Examples of applications that might want to do this include any application that needs very high performance, transactional, persistent messaging but doesn't want the hassle of writing it all from scratch. - Embedding HornetQ can be done in very few easy steps. Instantiate the + Embedding ActiveMQ can be done in very few easy steps. Instantiate the configuration object, instantiate the server, start it, and you have a - HornetQ running in your virtual machine. It's as simple and easy as + ActiveMQ running in your virtual machine. It's as simple and easy as that.
Simple Config File Embedding - The simplest way to embed HornetQ is to use the embedded wrapper - classes and configure HornetQ through its configuration files. There are + The simplest way to embed ActiveMQ is to use the embedded wrapper + classes and configure ActiveMQ through its configuration files. There are two different helper classes for this depending on whether your using the - HornetQ Core API or JMS. + ActiveMQ Core API or JMS.
Core API Only - For instantiating a core HornetQ Server only, the steps are pretty + For instantiating a core ActiveMQ Server only, the steps are pretty simple. The example requires that you have defined a configuration file - hornetq-configuration.xml in your + activemq-configuration.xml in your classpath: -import org.apache.activemq.core.server.embedded.EmbeddedHornetQ; +import org.apache.activemq.core.server.embedded.EmbeddedActiveMQ; ... -EmbeddedHornetQ embedded = new EmbeddedHornetQ(); +EmbeddedActiveMQ embedded = new EmbeddedActiveMQ(); embedded.start(); -ClientSessionFactory nettyFactory = HornetQClient.createClientSessionFactory( +ClientSessionFactory nettyFactory = ActiveMQClient.createClientSessionFactory( new TransportConfiguration( InVMConnectorFactory.class.getName())); @@ -91,7 +91,7 @@ System.out.println("message = " + msgReceived.getBody().readString()); session.close(); -The EmbeddedHornetQ class has a +The EmbeddedActiveMQ class has a few additional setter methods that allow you to specify a different config file name as well as other properties. See the javadocs for this class for more details. @@ -102,11 +102,11 @@ session.close(); JMS embedding is simple as well. This example requires that you have defined the config files - hornetq-configuration.xml, - hornetq-jms.xml, and a - hornetq-users.xml if you have security enabled. Let's + activemq-configuration.xml, + activemq-jms.xml, and a + activemq-users.xml if you have security enabled. Let's also assume that a queue and connection factory has been defined in the - hornetq-jms.xml config file. + activemq-jms.xml config file. import org.apache.activemq.jms.server.embedded.EmbeddedJMS; @@ -116,14 +116,14 @@ import org.apache.activemq.jms.server.embedded.EmbeddedJMS; EmbeddedJMS jms = new EmbeddedJMS(); jms.start(); -// This assumes we have configured hornetq-jms.xml with the appropriate config information +// This assumes we have configured activemq-jms.xml with the appropriate config information ConnectionFactory connectionFactory = jms.lookup("ConnectionFactory"); Destination destination = jms.lookup("/example/queue"); ... regular JMS code ... By default, the EmbeddedJMS class will store component entries defined within your - hornetq-jms.xml file in an internal concurrent hash + activemq-jms.xml file in an internal concurrent hash map. The EmbeddedJMS.lookup() method returns components stored in this map. If you want to use JNDI, call the EmbeddedJMS.setContext() method with the root JNDI @@ -136,10 +136,10 @@ Destination destination = jms.lookup("/example/queue"); POJO instantiation - Embedding Programmatically You can follow this step-by-step guide to programmatically embed the - core, non-JMS HornetQ Server instance: + core, non-JMS ActiveMQ Server instance: Create the configuration object - this contains configuration - information for a HornetQ instance. The setter methods of this class allow + information for a ActiveMQ instance. The setter methods of this class allow you to programmatically set configuration options as describe in the section. @@ -163,25 +163,25 @@ transports.add(new TransportConfiguration(InVMAcceptorFactory.class.getName())); config.setAcceptorConfigurations(transports); You need to instantiate an instance of - org.apache.activemq.api.core.server.embedded.EmbeddedHornetQ + org.apache.activemq.api.core.server.embedded.EmbeddedActiveMQ and add the configuration object to it. -import org.apache.activemq.api.core.server.HornetQ; -import org.apache.activemq.core.server.embedded.EmbeddedHornetQ; +import org.apache.activemq.api.core.server.ActiveMQ; +import org.apache.activemq.core.server.embedded.EmbeddedActiveMQ; ... -EmbeddedHornetQ server = new EmbeddedHornetQ(); +EmbeddedActiveMQ server = new EmbeddedActiveMQ(); server.setConfiguration(config); server.start(); You also have the option of instantiating - HornetQServerImpl directly: + ActiveMQServerImpl directly: -HornetQServer server = new HornetQServerImpl(config); +ActiveMQServer server = new ActiveMQServerImpl(config); server.start(); For JMS POJO instantiation, you work with the EmbeddedJMS class @@ -191,7 +191,7 @@ server.start(); example of this: -// Step 1. Create HornetQ core configuration, and set the properties accordingly +// Step 1. Create ActiveMQ core configuration, and set the properties accordingly Configuration configuration = new ConfigurationImpl(); configuration.setPersistenceEnabled(false); configuration.setSecurityEnabled(false); @@ -209,14 +209,14 @@ jmsConfig.getConnectionFactoryConfigurations().add(cfConfig); JMSQueueConfiguration queueConfig = new JMSQueueConfigurationImpl("queue1", null, false, "/queue/queue1"); jmsConfig.getQueueConfigurations().add(queueConfig); -// Step 5. Start the JMS Server using the HornetQ core server and the JMS configuration +// Step 5. Start the JMS Server using the ActiveMQ core server and the JMS configuration EmbeddedJMS jmsServer = new EmbeddedJMS(); jmsServer.setConfiguration(configuration); jmsServer.setJmsConfiguration(jmsConfig); jmsServer.start(); Please see for an example which - shows how to setup and run HornetQ embedded with JMS. + shows how to setup and run ActiveMQ embedded with JMS.
@@ -225,17 +225,17 @@ jmsServer.start(); You may also choose to use a dependency injection framework such as JBoss Micro Container or Spring Framework. See for more - details on Spring and HornetQ, but here's how you would do things with the + details on Spring and ActiveMQ, but here's how you would do things with the JBoss Micro Container. - HornetQ standalone uses JBoss Micro Container as the injection - framework. HornetQBootstrapServer and - hornetq-beans.xml which are part of the HornetQ + ActiveMQ standalone uses JBoss Micro Container as the injection + framework. ActiveMQBootstrapServer and + activemq-beans.xml which are part of the ActiveMQ distribution provide a very complete implementation of what's needed to bootstrap the server using JBoss Micro Container. When using JBoss Micro Container, you need to provide an XML file - declaring the HornetQServer and + declaring the ActiveMQServer and Configuration object, you can also inject a security manager and a MBean server if you want, but those are optional. @@ -251,8 +251,8 @@ jmsServer.start(); </bean> <!-- The core server --> - <bean name="HornetQServer" - class="org.apache.activemq.core.server.impl.HornetQServerImpl"> + <bean name="ActiveMQServer" + class="org.apache.activemq.core.server.impl.ActiveMQServerImpl"> <constructor> <parameter> <inject bean="Configuration"/> @@ -261,11 +261,11 @@ jmsServer.start(); </bean> </deployment> - HornetQBootstrapServer provides an easy + ActiveMQBootstrapServer provides an easy encapsulation of JBoss Micro Container. -HornetQBootstrapServer bootStrap = new HornetQBootstrapServer(new String[] {"hornetq-beans.xml"}); +ActiveMQBootstrapServer bootStrap = new ActiveMQBootstrapServer(new String[] {"activemq-beans.xml"}); bootStrap.run();
diff --git a/docs/user-manual/en/examples.xml b/docs/user-manual/en/examples.xml index d202c899c3..a128deaf71 100644 --- a/docs/user-manual/en/examples.xml +++ b/docs/user-manual/en/examples.xml @@ -18,12 +18,12 @@ + %BOOK_ENTITIES; ]> Examples - The HornetQ distribution comes with over 70 run out-of-the-box examples demonstrating many + The ActiveMQ distribution comes with over 70 run out-of-the-box examples demonstrating many of the features. The examples are available in the distribution, in the examples directory. Examples are split into JMS and core examples. JMS examples show how a particular @@ -49,11 +49,11 @@
Application-Layer Failover - HornetQ also supports Application-Layer failover, useful in the case that + ActiveMQ also supports Application-Layer failover, useful in the case that replication is not enabled on the server side. With Application-Layer failover, it's up to the application to register a JMS - ExceptionListener with HornetQ which will be called by - HornetQ in the event that connection failure is detected. + ExceptionListener with ActiveMQ which will be called by + ActiveMQ in the event that connection failure is detected. The code in the ExceptionListener then recreates the JMS connection, session, etc on another node and the application can continue. Application-layer failover is an alternative approach to High Availability (HA). @@ -68,7 +68,7 @@ The bridge example demonstrates a core bridge deployed on one server, which consumes messages from a local queue and forwards them to an address on a second server. - Core bridges are used to create message flows between any two HornetQ servers + Core bridges are used to create message flows between any two ActiveMQ servers which are remotely separated. Core bridges are resilient and will cope with temporary connection failure allowing them to be an ideal choice for forwarding over unreliable connections, e.g. a WAN. @@ -76,7 +76,7 @@
Browser The browser example shows you how to use a JMS QueueBrowser with HornetQ. + >QueueBrowser with ActiveMQ. Queues are a standard part of JMS, please consult the JMS 1.1 specification for full details. A QueueBrowser is used to look at messages on the queue @@ -98,7 +98,7 @@ The client-side-load-balancing example demonstrates how sessions created from a single JMS Connection can be created to different nodes of the cluster. In other words it demonstrates how - HornetQ does client-side load-balancing of sessions across the cluster. + ActiveMQ does client-side load-balancing of sessions across the cluster.
Clustered Durable Subscription @@ -154,10 +154,10 @@
Message Consumer Rate Limiting - With HornetQ you can specify a maximum consume rate at which a JMS MessageConsumer + With ActiveMQ you can specify a maximum consume rate at which a JMS MessageConsumer will consume messages. This can be specified when creating or deploying the connection factory. - If this value is specified then HornetQ will ensure that messages are never + If this value is specified then ActiveMQ will ensure that messages are never consumed at a rate higher than the specified rate. This is a form of consumer throttling.
@@ -176,7 +176,7 @@
Delayed Redelivery - The delayed-redelivery example demonstrates how HornetQ can be + The delayed-redelivery example demonstrates how ActiveMQ can be configured to provide a delayed redelivery in the case a message needs to be redelivered. Delaying redelivery can often be useful in the case that clients regularly fail or @@ -187,14 +187,14 @@
Divert - HornetQ diverts allow messages to be transparently "diverted" or copied from one + ActiveMQ diverts allow messages to be transparently "diverted" or copied from one address to another with just some simple configuration defined on the server side.
Durable Subscription The durable-subscription example shows you how to use a durable - subscription with HornetQ. Durable subscriptions are a standard part of JMS, please + subscription with ActiveMQ. Durable subscriptions are a standard part of JMS, please consult the JMS 1.1 specification for full details. Unlike non-durable subscriptions, the key function of durable subscriptions is that the messages contained in them persist longer than the lifetime of the @@ -210,7 +210,7 @@
Embedded Simple - The embedded example shows how to embed JMS within your own code using regular HornetQ XML files. + The embedded example shows how to embed JMS within your own code using regular ActiveMQ XML files.
Message Expiration @@ -219,19 +219,19 @@ period of time before being removed. JMS specification states that clients should not receive messages that have been expired (but it does not guarantee this will not happen). - HornetQ can assign an expiry address to a given queue so that when messages + ActiveMQ can assign an expiry address to a given queue so that when messages are expired, they are removed from the queue and sent to the expiry address. These "expired" messages can later be consumed from the expiry address for further inspection.
-
- HornetQ Resource Adapter example - This examples shows how to build the hornetq resource adapters a rar for deployment in other Application +
+ ActiveMQ Resource Adapter example + This examples shows how to build the activemq resource adapters a rar for deployment in other Application Server's
HTTP Transport - The http-transport example shows you how to configure HornetQ + The http-transport example shows you how to configure ActiveMQ to use the HTTP protocol as its transport layer.
@@ -241,18 +241,18 @@ before being used by the client code. This objects are called "administered objects" in JMS terminology. However, in some cases a JNDI server may not be available or desired. To come to - the rescue HornetQ also supports the direct instantiation of these administered + the rescue ActiveMQ also supports the direct instantiation of these administered objects on the client side so you don't have to use JNDI for JMS.
Interceptor - HornetQ allows an application to use an interceptor to hook into the messaging - system. Interceptors allow you to handle various message events in HornetQ. + ActiveMQ allows an application to use an interceptor to hook into the messaging + system. Interceptors allow you to handle various message events in ActiveMQ.
JAAS - The jaas example shows you how to configure HornetQ to use JAAS - for security. HornetQ can leverage JAAS to delegate user authentication and + The jaas example shows you how to configure ActiveMQ to use JAAS + for security. ActiveMQ can leverage JAAS to delegate user authentication and authorization to existing security infrastructure.
@@ -263,18 +263,18 @@
JMS Completion Listener The jms-completion-listener example shows how to send a message - asynchronously to HornetQ and use a CompletionListener to be notified of the Broker + asynchronously to ActiveMQ and use a CompletionListener to be notified of the Broker receiving it.
JMS Bridge The jms-brige example shows how to setup a bridge - between two standalone HornetQ servers. + between two standalone ActiveMQ servers.
JMS Context The jms-context example shows how to send and receive a message - to a JMS Queue using HornetQ by using a JMS Context. + to a JMS Queue using ActiveMQ by using a JMS Context. A JMSContext is part of JMS 2.0 and combines the JMS Connection and Session Objects into a simple Interface.
@@ -287,17 +287,17 @@
JMX Management - The jmx example shows how to manage HornetQ using JMX. + The jmx example shows how to manage ActiveMQ using JMX.
Large Message The large-message example shows you how to send and receive - very large messages with HornetQ. HornetQ supports the sending and receiving of huge + very large messages with ActiveMQ. ActiveMQ supports the sending and receiving of huge messages, much larger than can fit in available RAM on the client or server. Effectively the only limit to message size is the amount of disk space you have on the server. Large messages are persisted on the server so they can survive a server restart. - In other words HornetQ doesn't just do a simple socket stream from the sender to the + In other words ActiveMQ doesn't just do a simple socket stream from the sender to the consumer.
@@ -312,13 +312,13 @@
Management - The management example shows how to manage HornetQ using JMS + The management example shows how to manage ActiveMQ using JMS Messages to invoke management operations on the server.
Management Notification The management-notification example shows how to receive - management notifications from HornetQ using JMS messages. HornetQ servers emit + management notifications from ActiveMQ using JMS messages. ActiveMQ servers emit management notifications when events of interest occur (consumers are created or closed, addresses are created or deleted, security authentication fails, etc.). @@ -331,7 +331,7 @@
Message Group The message-group example shows you how to configure and use - message groups with HornetQ. Message groups allow you to pin messages so they are + message groups with ActiveMQ. Message groups allow you to pin messages so they are only consumed by a single consumer. Message groups are sets of messages that has the following characteristics: @@ -350,7 +350,7 @@
Message Group The message-group2 example shows you how to configure and use - message groups with HornetQ via a connection factory. + message groups with ActiveMQ via a connection factory.
Message Priority @@ -376,16 +376,16 @@
No Consumer Buffering - By default, HornetQ consumers buffer messages from the server in a client side + By default, ActiveMQ consumers buffer messages from the server in a client side buffer before you actually receive them on the client side. This improves performance since otherwise every time you called receive() or had processed the - last message in a MessageListener onMessage() method, the HornetQ + last message in a MessageListener onMessage() method, the ActiveMQ client would have to go the server to request the next message, which would then get sent to the client side, if one was available. This would involve a network round trip for every message and reduce performance. - Therefore, by default, HornetQ pre-fetches messages into a buffer on each + Therefore, by default, ActiveMQ pre-fetches messages into a buffer on each consumer. - In some case buffering is not desirable, and HornetQ allows it to be switched off. + In some case buffering is not desirable, and ActiveMQ allows it to be switched off. This example demonstrates that.
@@ -394,7 +394,7 @@ as a live-backup pair for high availability (HA), and a client using a non-transacted JMS session failing over from live to backup when the live server is crashed. - HornetQ implements failover of client connections between + ActiveMQ implements failover of client connections between live and backup servers. This is implemented by the replication of state between live and backup nodes. When replication is configured and a live node crashes, the client connections can carry and continue to send and consume messages. When non-transacted @@ -403,12 +403,12 @@
OpenWire - The Openwire example shows how to configure a HornetQ + The Openwire example shows how to configure a ActiveMQ server to communicate with an ActiveMQ JMS client that uses open-wire protocol.
Paging - The paging example shows how HornetQ can support huge queues + The paging example shows how ActiveMQ can support huge queues even when the server is running in limited RAM. It does this by transparently paging messages to disk, and depaging them when they are required. @@ -422,24 +422,24 @@ All of these standard modes involve sending acknowledgements from the client to the server. However in some cases, you really don't mind losing messages in event of failure, so it would make sense to acknowledge the message on the server before - delivering it to the client. This example demonstrates how HornetQ allows this with + delivering it to the client. This example demonstrates how ActiveMQ allows this with an extra acknowledgement mode.
Message Producer Rate Limiting - The producer-rte-limit example demonstrates how, with HornetQ, + The producer-rte-limit example demonstrates how, with ActiveMQ, you can specify a maximum send rate at which a JMS message producer will send messages.
Proton Qpid - HornetQ can be configured to accept requests from any AMQP client that supports the + ActiveMQ can be configured to accept requests from any AMQP client that supports the 1.0 version of the protocol. This proton-j example shows a simply qpid java 1.0 client example.
Proton Ruby - HornetQ can be configured to accept requests from any AMQP client that supports the + ActiveMQ can be configured to accept requests from any AMQP client that supports the 1.0 version of the protocol. This example shows a simply proton ruby client that sends and receives messages
@@ -466,7 +466,7 @@ Reattach Node example The Reattach Node example shows how a client can try to reconnect to the same server instead of failing the connection immediately and - notifying any user ExceptionListener objects. HornetQ can be configured to automatically + notifying any user ExceptionListener objects. ActiveMQ can be configured to automatically retry the connection, and reattach to the server when it becomes available again across the network.
@@ -494,71 +494,71 @@
Rest example - An example showing how to use the HornetQ Rest API + An example showing how to use the ActiveMQ Rest API
Scheduled Message The scheduled-message example shows you how to send a scheduled - message to a JMS Queue with HornetQ. Scheduled messages won't get delivered until a + message to a JMS Queue with ActiveMQ. Scheduled messages won't get delivered until a specified time in the future.
Security The security example shows you how configure and use role based - queue security with HornetQ. + queue security with ActiveMQ.
Send Acknowledgements The send-acknowledgements example shows you how to use - HornetQ's advanced asynchronous send acknowledgements feature + ActiveMQ's advanced asynchronous send acknowledgements feature to obtain acknowledgement from the server that sends have been received and processed in a separate stream to the sent messages.
Spring Integration - This example shows how to use embedded JMS using HornetQ's Spring integration. + This example shows how to use embedded JMS using ActiveMQ's Spring integration.
SSL Transport - The ssl-enabled shows you how to configure SSL with HornetQ to + The ssl-enabled shows you how to configure SSL with ActiveMQ to send and receive message.
Static Message Selector The static-selector example shows you how to configure a - HornetQ core queue with static message selectors (filters). + ActiveMQ core queue with static message selectors (filters).
Static Message Selector Using JMS The static-selector-jms example shows you how to configure a - HornetQ queue with static message selectors (filters) using JMS. + ActiveMQ queue with static message selectors (filters) using JMS.
Stomp The stomp example shows you how to configure a - HornetQ server to send and receive Stomp messages. + ActiveMQ server to send and receive Stomp messages.
Stomp1.1 The stomp example shows you how to configure a - HornetQ server to send and receive Stomp messages via a Stomp 1.1 connection. + ActiveMQ server to send and receive Stomp messages via a Stomp 1.1 connection.
Stomp1.2 The stomp example shows you how to configure a - HornetQ server to send and receive Stomp messages via a Stomp 1.2 connection. + ActiveMQ server to send and receive Stomp messages via a Stomp 1.2 connection.
Stomp Over Web Sockets The stomp-websockets example shows you how to configure a - HornetQ server to send and receive Stomp messages directly from Web browsers (provided + ActiveMQ server to send and receive Stomp messages directly from Web browsers (provided they support Web Sockets).
Symmetric Cluster The symmetric-cluster example demonstrates a symmetric cluster - set-up with HornetQ. - HornetQ has extremely flexible clustering which allows you to set-up servers in + set-up with ActiveMQ. + ActiveMQ has extremely flexible clustering which allows you to set-up servers in many different topologies. The most common topology that you'll perhaps be familiar with if you are used to application server clustering is a symmetric cluster. With a symmetric cluster, the cluster is homogeneous, i.e. each node is configured @@ -575,14 +575,14 @@
Topic Hierarchy - HornetQ supports topic hierarchies. With a topic hierarchy you can register a + ActiveMQ supports topic hierarchies. With a topic hierarchy you can register a subscriber with a wild-card and that subscriber will receive any messages sent to an address that matches the wild card.
Topic Selector 1 The topic-selector-example1 example shows you how to send - message to a JMS Topic, and subscribe them using selectors with HornetQ. + message to a JMS Topic, and subscribe them using selectors with ActiveMQ.
Topic Selector 2 @@ -595,7 +595,7 @@ as a live-backup pair for high availability (HA), and a client using a transacted JMS session failing over from live to backup when the live server is crashed. - HornetQ implements failover of client connections between + ActiveMQ implements failover of client connections between live and backup servers. This is implemented by the sharing of a journal between the servers. When a live node crashes, the client connections can carry and continue to send and consume messages. When transacted @@ -610,29 +610,29 @@
Transactional Session The transactional example shows you how to use a transactional - Session with HornetQ. + Session with ActiveMQ.
XA Heuristic The xa-heuristic example shows you how to make an XA heuristic - decision through HornetQ Management Interface. A heuristic decision is a unilateral + decision through ActiveMQ Management Interface. A heuristic decision is a unilateral decision to commit or rollback an XA transaction branch after it has been prepared.
XA Receive The xa-receive example shows you how message receiving behaves - in an XA transaction in HornetQ. + in an XA transaction in ActiveMQ.
XA Send The xa-send example shows you how message sending behaves in an - XA transaction in HornetQ. + XA transaction in ActiveMQ.
XA with Transaction Manager The xa-with-jta example shows you how to use JTA interfaces to - control transactions with HornetQ. + control transactions with ActiveMQ.
@@ -641,7 +641,7 @@ directory and type ant
Embedded - The embedded example shows how to embed the HornetQ server + The embedded example shows how to embed the ActiveMQ server within your own code.
@@ -653,8 +653,8 @@ variable set. Please refer to the examples documentation for further instructions. When running the Java EE examples you may see warning messages in the WildFly log about incompatible client and - server versions. This is normal if a newer version of the HornetQ project is being used with a version of WildFly that - ships an older version of HornetQ. These examples should still complete without any functional errors. + server versions. This is normal if a newer version of the ActiveMQ project is being used with a version of WildFly that + ships an older version of ActiveMQ. These examples should still complete without any functional errors.
EJB/JMS Transaction @@ -662,16 +662,16 @@
Resource Adapter Configuration - This example demonstrates how to configure several properties on the HornetQ JCA + This example demonstrates how to configure several properties on the ActiveMQ JCA resource adaptor.
Resource Adapter Remote Server Configuration - This example demonstrates how to configure the HornetQ resource adapter to talk to a remote HornetQ server + This example demonstrates how to configure the ActiveMQ resource adapter to talk to a remote ActiveMQ server
JMS Bridge - An example demonstrating the use of the HornetQ JMS bridge. + An example demonstrating the use of the ActiveMQ JMS bridge.
MDB (Message Driven Bean) @@ -679,16 +679,16 @@
Servlet Transport - An example of how to use the HornetQ servlet transport. + An example of how to use the ActiveMQ servlet transport.
Servlet SSL Transport - An example of how to use the HornetQ servlet transport over SSL. + An example of how to use the ActiveMQ servlet transport over SSL.
XA Recovery An example of how XA recovery works within the JBoss Application server using - HornetQ. + ActiveMQ.
diff --git a/docs/user-manual/en/filter-expressions.xml b/docs/user-manual/en/filter-expressions.xml index 2cf7bd2762..4df6f71f72 100644 --- a/docs/user-manual/en/filter-expressions.xml +++ b/docs/user-manual/en/filter-expressions.xml @@ -19,23 +19,23 @@ + %BOOK_ENTITIES; ]> Filter Expressions - HornetQ provides a powerful filter language based on a subset of the SQL 92 + ActiveMQ provides a powerful filter language based on a subset of the SQL 92 expression syntax. It is the same as the syntax used for JMS selectors, but the predefined identifiers are different. For documentation on JMS selector syntax please the JMS javadoc for javax.jms.Message. - Filter expressions are used in several places in HornetQ + Filter expressions are used in several places in ActiveMQ Predefined Queues. When pre-defining a queue, either in hornetq-configuration.xml or hornetq-jms.xml a filter + >activemq-configuration.xml or activemq-jms.xml a filter expression can be defined for a queue. Only messages that match the filter expression will enter the queue. @@ -52,8 +52,8 @@ several places as described in . - There are some differences between JMS selector expressions and HornetQ core - filter expressions. Whereas JMS selector expressions operate on a JMS message, HornetQ + There are some differences between JMS selector expressions and ActiveMQ core + filter expressions. Whereas JMS selector expressions operate on a JMS message, ActiveMQ core filter expressions operate on a core message. The following identifiers can be used in a core filter expressions to refer to attributes of the core message in an expression: diff --git a/docs/user-manual/en/flow-control.xml b/docs/user-manual/en/flow-control.xml index 0de82760cc..5f107e4b32 100644 --- a/docs/user-manual/en/flow-control.xml +++ b/docs/user-manual/en/flow-control.xml @@ -18,7 +18,7 @@ + %BOOK_ENTITIES; ]> @@ -36,14 +36,14 @@ in time.
Window-Based Flow Control - By default, HornetQ consumers buffer messages from the server in a client side buffer + By default, ActiveMQ consumers buffer messages from the server in a client side buffer before the client consumes them. This improves performance: otherwise every time the - client consumes a message, HornetQ would have to go the server to request the next + client consumes a message, ActiveMQ would have to go the server to request the next message. In turn, this message would then get sent to the client side, if one was available. A network round trip would be involved for every message and considerably reduce performance. - To prevent this, HornetQ pre-fetches messages into a buffer on each consumer. The + To prevent this, ActiveMQ pre-fetches messages into a buffer on each consumer. The total maximum size of messages (in bytes) that will be buffered on each consumer is determined by the consumer-window-size parameter. By default, the consumer-window-size is set to 1 MiB (1024 * 1024 @@ -106,14 +106,14 @@ find the optimal value, but a value of 1MiB is fine in most cases.
Using Core API - If HornetQ Core API is used, the consumer window size is specified by If ActiveMQ Core API is used, the consumer window size is specified by ServerLocator.setConsumerWindowSize() method and some of the ClientSession.createConsumer() methods.
Using JMS if JNDI is used to look up the connection factory, the consumer window size is - configured in hornetq-jms.xml: + configured in activemq-jms.xml: <connection-factory name="ConnectionFactory"> <connectors> @@ -127,10 +127,10 @@ <consumer-window-size>0</consumer-window-size> </connection-factory> If the connection factory is directly instantiated, the consumer window size is - specified by HornetQConnectionFactory.setConsumerWindowSize() + specified by ActiveMQConnectionFactory.setConsumerWindowSize() method. Please see for an example which - shows how to configure HornetQ to prevent consumer buffering when dealing with slow + shows how to configure ActiveMQ to prevent consumer buffering when dealing with slow consumers.
@@ -147,7 +147,7 @@ limiting consumer rate.
Using Core API - If the HornetQ core API is being used the rate can be set via the If the ActiveMQ core API is being used the rate can be set via the ServerLocator.setConsumerMaxRate(int consumerMaxRate) method or alternatively via some of the ClientSession.createConsumer() methods. @@ -155,7 +155,7 @@
Using JMS If JNDI is used to look up the connection factory, the max rate can be configured - in hornetq-jms.xml: + in activemq-jms.xml: <connection-factory name="ConnectionFactory"> <connectors> @@ -169,7 +169,7 @@ <consumer-max-rate>10</consumer-max-rate> </connection-factory> If the connection factory is directly instantiated, the max rate size can be set - via the HornetQConnectionFactory.setConsumerMaxRate(int + via the ActiveMQConnectionFactory.setConsumerMaxRate(int consumerMaxRate) method. Rate limited flow control can be used in conjunction with window based flow @@ -179,18 +179,18 @@ soon fill up with messages. Please see for an example which - shows how to configure HornetQ to prevent consumer buffering when dealing with slow + shows how to configure ActiveMQ to prevent consumer buffering when dealing with slow consumers.
Producer flow control - HornetQ also can limit the amount of data sent from a client to a server to prevent the + ActiveMQ also can limit the amount of data sent from a client to a server to prevent the server being overwhelmed.
Window based flow control - In a similar way to consumer window based flow control, HornetQ producers, by + In a similar way to consumer window based flow control, ActiveMQ producers, by default, can only send messages to an address as long as they have sufficient credits to do so. The amount of credits required to send a message is given by the size of the message. @@ -203,14 +203,14 @@ getting overloaded.
Using Core API - If the HornetQ core API is being used, window size can be set via the If the ActiveMQ core API is being used, window size can be set via the ServerLocator.setProducerWindowSize(int producerWindowSize) method.
Using JMS If JNDI is used to look up the connection factory, the producer window size can be - configured in hornetq-jms.xml: + configured in activemq-jms.xml: <connection-factory name="ConnectionFactory"> <connectors> @@ -222,7 +222,7 @@ <producer-window-size>10</producer-window-size> </connection-factory> If the connection factory is directly instantiated, the producer window size can - be set via the HornetQConnectionFactory.setProducerWindowSize(int + be set via the ActiveMQConnectionFactory.setProducerWindowSize(int producerWindowSize) method.
@@ -275,8 +275,8 @@
Rate limited flow control - HornetQ also allows the rate a producer can emit message to be limited, in units of - messages per second. By specifying such a rate, HornetQ will ensure that producer never + ActiveMQ also allows the rate a producer can emit message to be limited, in units of + messages per second. By specifying such a rate, ActiveMQ will ensure that producer never produces messages at a rate higher than that specified. The rate must be a positive integer to enable this functionality and is the maximum desired message consumption rate specified in units of messages per second. Setting this @@ -286,7 +286,7 @@ of limiting producer rate.
Using Core API - If the HornetQ core API is being used the rate can be set via the If the ActiveMQ core API is being used the rate can be set via the ServerLocator.setProducerMaxRate(int consumerMaxRate) method or alternatively via some of the ClientSession.createProducer() methods. @@ -294,7 +294,7 @@
Using JMS If JNDI is used to look up the connection factory, the max rate can be configured - in hornetq-jms.xml: + in activemq-jms.xml: <connection-factory name="ConnectionFactory"> <connectors> @@ -308,7 +308,7 @@ <producer-max-rate>10</producer-max-rate> </connection-factory> If the connection factory is directly instantiated, the max rate size can be set - via the HornetQConnectionFactory.setProducerMaxRate(int + via the ActiveMQConnectionFactory.setProducerMaxRate(int consumerMaxRate) method.
diff --git a/docs/user-manual/en/ha.xml b/docs/user-manual/en/ha.xml index b1f35574cc..7e9eb72fa5 100644 --- a/docs/user-manual/en/ha.xml +++ b/docs/user-manual/en/ha.xml @@ -18,7 +18,7 @@ + %BOOK_ENTITIES; ]> @@ -33,13 +33,13 @@
Live - Backup Groups - HornetQ allows servers to be linked together as live - backup + ActiveMQ allows servers to be linked together as live - backup groups where each live server can have 1 or more backup servers. A backup server is owned by only one live server. Backup servers are not operational until failover occurs, however 1 chosen backup, which will be in passive mode, announces its status and waits to take over the live servers work - Before failover, only the live server is serving the HornetQ clients while the backup + Before failover, only the live server is serving the ActiveMQ clients while the backup servers remain passive or awaiting to become a backup server. When a live server crashes or is brought down in the correct mode, the backup server currently in passive mode will become live and another backup server will become passive. If a live server restarts after a @@ -49,7 +49,7 @@
HA Policies - HornetQ supports two different strategies for backing up a server shared + ActiveMQ supports two different strategies for backing up a server shared store and replication. Which is configured via the ha-policy configuration element. @@ -73,7 +73,7 @@ The ha-policy configurations replaces any current HA configuration in the root of the - hornetq-configuration.xml configuration. All old configuration is now deprecated altho + activemq-configuration.xml configuration. All old configuration is now deprecated altho best efforts will be made to honour it if configured this way. @@ -162,7 +162,7 @@ specifying a node group. You can specify a group of live servers that a backup server can connect to. This is done by configuring group-name in either the master or the slave element of the - hornetq-configuration.xml. A Backup server will only connect to a live server that + activemq-configuration.xml. A Backup server will only connect to a live server that shares the same node group name @@ -226,7 +226,7 @@ Configuration To configure the live and backup servers to be a replicating pair, configure - the live server in ' hornetq-configuration.xml to have: + the live server in ' activemq-configuration.xml to have: <ha-policy> @@ -362,7 +362,7 @@
Configuration To configure the live and backup servers to share their store, configure - id via the ha-policy configuration in hornetq-configuration.xml: + id via the ha-policy configuration in activemq-configuration.xml: <ha-policy> <shared-store> @@ -427,7 +427,7 @@ request the other server (which it assumes it is a back that has assumed its duties) to shutdown for it to take over. This is necessary because otherwise the live server has no means to know whether there was a fail-over or not, and if there was if the server that took its duties is still running or not. - To configure this option at your hornetq-configuration.xml configuration file as follows: + To configure this option at your activemq-configuration.xml configuration file as follows: <ha-policy> <replication> @@ -459,7 +459,7 @@ API as explained at You can also force the running live server to shutdown when the old live server comes back up allowing the original live server to take over automatically by setting the following property in the - hornetq-configuration.xml configuration file as follows: + activemq-configuration.xml configuration file as follows: <ha-policy> <shared-store> @@ -550,7 +550,7 @@ and its Connectors and Acceptors which are discussed later on in this chapter. A live server can also be configured to allow requests from backups and also how many backups a live server can start. this way you can evenly distribute backups around the cluster. This is configured via the ha-policy - element in the hornetq-configuration.xml file like so: + element in the activemq-configuration.xml file like so: <ha-policy> <replication> @@ -741,7 +741,7 @@
Failover Modes - HornetQ defines two types of client failover: + ActiveMQ defines two types of client failover: Automatic client failover @@ -750,7 +750,7 @@ Application-level client failover - HornetQ also provides 100% transparent automatic reattachment of connections to the + ActiveMQ also provides 100% transparent automatic reattachment of connections to the same server (e.g. in case of transient network problems). This is similar to failover, except it is reconnecting to the same server and is discussed in @@ -759,20 +759,20 @@ since the backup node will not have any knowledge of non persistent queues.
Automatic Client Failover - HornetQ clients can be configured to receive knowledge of all live and backup servers, so + ActiveMQ clients can be configured to receive knowledge of all live and backup servers, so that in event of connection failure at the client - live server connection, the client will detect this and reconnect to the backup server. The backup server will then automatically recreate any sessions and consumers that existed on each connection before failover, thus saving the user from having to hand-code manual reconnection logic. - HornetQ clients detect connection failure when it has not received packets from + ActiveMQ clients detect connection failure when it has not received packets from the server within the time given by client-failure-check-period as explained in section . If the client does not receive data in good time, it will assume the connection has failed and attempt failover. Also if the socket is closed by the OS, usually if the server process is killed rather than the machine itself crashing, then the client will failover straight away. - HornetQ clients can be configured to discover the list of live-backup server groups in a + ActiveMQ clients can be configured to discover the list of live-backup server groups in a number of different ways. They can be configured explicitly or probably the most common way of doing this is to use server discovery for the client to automatically discover the list. For full details on how to configure @@ -794,7 +794,7 @@ connection is made there is a window where it does not know about the backup. If a failure happens at this point the client can only try reconnecting to the original live server. To configure how many attempts the client will make you can set the property initialConnectAttempts - on the ClientSessionFactoryImpl or HornetQConnectionFactory or + on the ClientSessionFactoryImpl or ActiveMQConnectionFactory or initial-connect-attempts in xml. The default for this is 0, that is try only once. Once the number of attempts has been made an exception will be thrown. @@ -804,7 +804,7 @@ linkend="examples.non-transaction-failover"/>.
A Note on Server Replication - HornetQ does not replicate full server state between live and backup servers. + ActiveMQ does not replicate full server state between live and backup servers. When the new session is automatically recreated on the backup it won't have any knowledge of messages already sent or acknowledged in that session. Any in-flight sends or acknowledgements at the time of failover might also be @@ -838,14 +838,14 @@ to continue its execution, when failover occurs, the new session will not have any knowledge of the call that was in progress. This call might otherwise hang for ever, waiting for a response that will never come. - To prevent this, HornetQ will unblock any blocking calls that were in progress + To prevent this, ActiveMQ will unblock any blocking calls that were in progress at the time of failover by making them throw a javax.jms.JMSException (if using JMS), or a ActiveMQException with error code ActiveMQException.UNBLOCKED. It is up to the client code to catch this exception and retry any operations if desired. If the method being unblocked is a call to commit(), or prepare(), then the - transaction will be automatically rolled back and HornetQ will throw a javax.jms.TransactionRolledBackException (if using JMS), or a ActiveMQException with error code ActiveMQException.TRANSACTION_ROLLED_BACK if using the core @@ -879,7 +879,7 @@ rollback code as necessary. There is no need to manually rollback the session - it is already rolled back. The user can then just retry the transactional operations again on the same session. - HornetQ ships with a fully functioning example demonstrating how to do this, + ActiveMQ ships with a fully functioning example demonstrating how to do this, please see If failover occurs when a commit call is being executed, the server, as previously described, will unblock the call to prevent a hang, since no response @@ -925,10 +925,10 @@ connection failure: java.jms.ExceptionListener. Please consult the JMS javadoc or any good JMS tutorial for more information on how to use this. - The HornetQ core API also provides a similar feature in the form of the class - org.hornet.core.client.SessionFailureListener + The ActiveMQ core API also provides a similar feature in the form of the class + org.apache.activemq.core.client.SessionFailureListener Any ExceptionListener or SessionFailureListener instance will always be called by - HornetQ on event of connection failure, irrespective of whether the connection was successfully failed over, reconnected or reattached, however you can find out if reconnect or reattach has happened by either the failedOver flag passed in on the connectionFailed @@ -970,7 +970,7 @@ failover, since the failover is handled at the user application level. To implement application-level failover, if you're using JMS then you need to set an ExceptionListener class on the JMS connection. The - ExceptionListener will be called by HornetQ in the event that + ExceptionListener will be called by ActiveMQ in the event that connection failure is detected. In your ExceptionListener, you would close your old JMS connections, potentially look up new connection factory instances from JNDI and creating new connections. In this case you may well be using diff --git a/docs/user-manual/en/images/hornetQ-banner_final.png b/docs/user-manual/en/images/hornetQ-banner_final.png deleted file mode 100644 index 6388dff1f5..0000000000 Binary files a/docs/user-manual/en/images/hornetQ-banner_final.png and /dev/null differ diff --git a/docs/user-manual/en/images/hornetQ_logo_600px.png b/docs/user-manual/en/images/hornetQ_logo_600px.png deleted file mode 100644 index b71f4ba130..0000000000 Binary files a/docs/user-manual/en/images/hornetQ_logo_600px.png and /dev/null differ diff --git a/docs/user-manual/en/intercepting-operations.xml b/docs/user-manual/en/intercepting-operations.xml index f87423026c..93a6655e1d 100644 --- a/docs/user-manual/en/intercepting-operations.xml +++ b/docs/user-manual/en/intercepting-operations.xml @@ -19,13 +19,13 @@ + %BOOK_ENTITIES; ]> Intercepting Operations - HornetQ supports interceptors to intercept packets entering + ActiveMQ supports interceptors to intercept packets entering and exiting the server. Incoming and outgoing interceptors are be called for any packet entering or exiting the server respectively. This allows custom code to be executed, e.g. for auditing packets, filtering or other reasons. Interceptors can change the @@ -55,7 +55,7 @@ public interface Interceptor
Configuring The Interceptors Both incoming and outgoing interceptors are configured in - hornetq-configuration.xml: + activemq-configuration.xml: <remoting-incoming-interceptors> <class-name>org.apache.activemq.jms.example.LoginInterceptor</class-name> diff --git a/docs/user-manual/en/interoperability.xml b/docs/user-manual/en/interoperability.xml index 86dadc1b72..96a4ed84fa 100644 --- a/docs/user-manual/en/interoperability.xml +++ b/docs/user-manual/en/interoperability.xml @@ -18,7 +18,7 @@ + %BOOK_ENTITIES; ]> @@ -26,12 +26,12 @@
Stomp Stomp is a text-orientated wire protocol that allows - Stomp clients to communicate with Stomp Brokers. HornetQ now supports Stomp 1.0, 1.1 and 1.2. + Stomp clients to communicate with Stomp Brokers. ActiveMQ now supports Stomp 1.0, 1.1 and 1.2. Stomp clients are available for several languages and platforms making it a good choice for interoperability.
Native Stomp support - HornetQ provides native support for Stomp. To be able to send and receive Stomp messages, + ActiveMQ provides native support for Stomp. To be able to send and receive Stomp messages, you must configure a NettyAcceptor with a protocols parameter set to have stomp: @@ -40,9 +40,9 @@ <param key="protocols" value="STOMP"/> <param key="port" value="61613"/> </acceptor> - With this configuration, HornetQ will accept Stomp connections on + With this configuration, ActiveMQ will accept Stomp connections on the port 61613 (which is the default port of the Stomp brokers). - See the stomp example which shows how to configure a HornetQ server with Stomp. + See the stomp example which shows how to configure a ActiveMQ server with Stomp.
Limitations Message acknowledgements are not transactional. The ACK frame can not be part of a transaction @@ -52,12 +52,12 @@ Stomp 1.1/1.2 Notes
Virtual Hosting - HornetQ currently doesn't support virtual hosting, which means the 'host' header + ActiveMQ currently doesn't support virtual hosting, which means the 'host' header in CONNECT fram will be ignored.
Heart-beating - HornetQ specifies a minimum value for both client and server heart-beat intervals. + ActiveMQ specifies a minimum value for both client and server heart-beat intervals. The minimum interval for both client and server heartbeats is 500 milliseconds. That means if a client sends a CONNECT frame with heartbeat values lower than 500, the server will defaults the value to 500 milliseconds regardless the values of the 'heart-beat' header in the frame. @@ -66,15 +66,15 @@
- Mapping Stomp destinations to HornetQ addresses and queues + Mapping Stomp destinations to ActiveMQ addresses and queues Stomp clients deals with destinations when sending messages and subscribing. Destination names are simply strings which are mapped to some form of destination on the server - how the server translates these is left to the server implementation. - In HornetQ, these destinations are mapped to addresses and queues. + In ActiveMQ, these destinations are mapped to addresses and queues. When a Stomp client sends a message (using a SEND frame), the specified destination is mapped to an address. When a Stomp client subscribes (or unsubscribes) for a destination (using a SUBSCRIBE - or UNSUBSCRIBE frame), the destination is mapped to a HornetQ queue. + or UNSUBSCRIBE frame), the destination is mapped to a ActiveMQ queue.
STOMP and connection-ttl @@ -108,7 +108,7 @@ Stomp and JMS interoperability
Using JMS destinations - As explained in , JMS destinations are also mapped to HornetQ addresses and queues. + As explained in , JMS destinations are also mapped to ActiveMQ addresses and queues. If you want to use Stomp to send messages to JMS destinations, the Stomp destinations must follow the same convention: @@ -134,8 +134,8 @@ destination:jms.topic.stocks
- Sending and consuming Stomp message from JMS or HornetQ Core API - Stomp is mainly a text-orientated protocol. To make it simpler to interoperate with JMS and HornetQ Core API, + Sending and consuming Stomp message from JMS or ActiveMQ Core API + Stomp is mainly a text-orientated protocol. To make it simpler to interoperate with JMS and ActiveMQ Core API, our Stomp implementation checks for presence of the content-length header to decide how to map a Stomp message to a JMS Message or a Core message. @@ -151,7 +151,7 @@ destination:jms.topic.stocks Message IDs for Stomp messages When receiving Stomp messages via a JMS consumer or a QueueBrowser, the messages have no properties like JMSMessageID by default. However this may bring some inconvenience to - clients who wants an ID for their purpose. HornetQ Stomp provides a parameter to enable + clients who wants an ID for their purpose. ActiveMQ Stomp provides a parameter to enable message ID on each incoming Stomp message. If you want each Stomp message to have a unique ID, just set the stomp-enable-message-id to true. For example: @@ -172,9 +172,9 @@ hq-message-id : STOMP12345
Handling of Large Messages with Stomp - Stomp clients may send very large bodys of frames which can exceed the size of HornetQ + Stomp clients may send very large bodys of frames which can exceed the size of ActiveMQ server's internal buffer, causing unexpected errors. To prevent this situation from happening, - HornetQ provides a stomp configuration attribute stomp-min-large-message-size. + ActiveMQ provides a stomp configuration attribute stomp-min-large-message-size. This attribute can be configured inside a stomp acceptor, as a parameter. For example: <acceptor name="stomp-acceptor"> @@ -183,7 +183,7 @@ hq-message-id : STOMP12345 <param key="port" value="61613"/> <param key="stomp-min-large-message-size" value="10240"/> </acceptor> - The type of this attribute is integer. When this attributed is configured, HornetQ server + The type of this attribute is integer. When this attributed is configured, ActiveMQ server will check the size of the body of each Stomp frame arrived from connections established with this acceptor. If the size of the body is equal or greater than the value of stomp-min-large-message, the message will be persisted as a large message. @@ -197,8 +197,8 @@ hq-message-id : STOMP12345
Stomp Over Web Sockets - HornetQ also support Stomp over Web Sockets. Modern web browser which support Web Sockets can send and receive - Stomp messages from HornetQ. + ActiveMQ also support Stomp over Web Sockets. Modern web browser which support Web Sockets can send and receive + Stomp messages from ActiveMQ. To enable Stomp over Web Sockets, you must configure a NettyAcceptor with a protocol parameter set to stomp_ws: @@ -207,14 +207,14 @@ hq-message-id : STOMP12345 <param key="protocols" value="STOMP_WS"/> <param key="port" value="61614"/> </acceptor> - With this configuration, HornetQ will accept Stomp connections over Web Sockets on + With this configuration, ActiveMQ will accept Stomp connections over Web Sockets on the port 61614 with the URL path /stomp. Web browser can then connect to ws://<server>:61614/stomp using a Web Socket to send and receive Stomp messages. A companion JavaScript library to ease client-side development is available from GitHub (please see its documentation for a complete description). - The stomp-websockets example shows how to configure HornetQ server to have web browsers and Java + The stomp-websockets example shows how to configure ActiveMQ server to have web browsers and Java applications exchanges messages on a JMS topic.
@@ -222,10 +222,10 @@ hq-message-id : STOMP12345 StompConnect StompConnect is a server that can act as a Stomp broker and proxy the Stomp protocol to the standard JMS API. - Consequently, using StompConnect it is possible to turn HornetQ into a Stomp Broker and + Consequently, using StompConnect it is possible to turn ActiveMQ into a Stomp Broker and use any of the available stomp clients. These include clients written in C, C++, c# and .net etc. - To run StompConnect first start the HornetQ server and make sure that it is using + To run StompConnect first start the ActiveMQ server and make sure that it is using JNDI. Stomp requires the file jndi.properties to be available on the classpath. This should look something like: @@ -234,7 +234,7 @@ java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.provider.url=jnp://localhost:1099 java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces Make sure this file is in the classpath along with the StompConnect jar and the - HornetQ jars and simply run java org.codehaus.stomp.jms.Main. + ActiveMQ jars and simply run java org.codehaus.stomp.jms.Main.
@@ -244,7 +244,7 @@ java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
AMQP - HornetQ supports the AMQP 1.0 + ActiveMQ supports the AMQP 1.0 specification. To enable AMQP you must configure a Netty Acceptor to receive AMQP clients, like so: <acceptor name="stomp-acceptor"> @@ -253,20 +253,20 @@ java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces </acceptor> - HornetQ will then accept AMQP 1.0 clients on port 5672 which is the default AMQP port. + ActiveMQ will then accept AMQP 1.0 clients on port 5672 which is the default AMQP port. There are 2 Stomp examples available see proton-j and proton-ruby which use the qpid Java and Ruby clients respectively
AMQP and security - The HornetQ Server accepts AMQP SASL Authentication and will use this to map onto the underlying session created - for the connection so you can use the normal HornetQ security configuration. + The ActiveMQ Server accepts AMQP SASL Authentication and will use this to map onto the underlying session created + for the connection so you can use the normal ActiveMQ security configuration.
AMQP Links An AMQP Link is a uni directional transport for messages between a source and a target, i.e. a client and the - HornetQ Broker. A link will have an endpoint of which there are 2 kinds, a Sender and A Receiver. At the Broker a - Sender will have its messages converted into a HornetQ Message and forwarded to its destination or target. A - Receiver will map onto a HornetQ Server Consumer and convert HornetQ messages back into AMQP messages before being delivered. + ActiveMQ Broker. A link will have an endpoint of which there are 2 kinds, a Sender and A Receiver. At the Broker a + Sender will have its messages converted into a ActiveMQ Message and forwarded to its destination or target. A + Receiver will map onto a ActiveMQ Server Consumer and convert ActiveMQ messages back into AMQP messages before being delivered.
AMQP and destinations @@ -282,13 +282,13 @@ java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces AMQP allows the use of multiple transactions per session, amqp:multi-txns-per-ssn, - however in this version HornetQ will only support single transactions per session + however in this version ActiveMQ will only support single transactions per session
OpenWire - HornetQ now supports the OpenWire - protocol so that an ActiveMQ JMS client can talk directly to a HornetQ server. To enable OpenWire support + ActiveMQ now supports the OpenWire + protocol so that an ActiveMQ JMS client can talk directly to a ActiveMQ server. To enable OpenWire support you must configure a Netty Acceptor, like so: <acceptor name="openwire-acceptor"> @@ -297,11 +297,11 @@ java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces </acceptor> - The HornetQ server will then listens on port 61616 for incoming openwire commands. Please note the "protocols" is not mandatory here. - The openwire configuration conforms to HornetQ's "Single Port" feature. Please refer to + The ActiveMQ server will then listens on port 61616 for incoming openwire commands. Please note the "protocols" is not mandatory here. + The openwire configuration conforms to ActiveMQ's "Single Port" feature. Please refer to Configuring Single Port for details. Please refer to the openwire example for more coding details. Currently we support ActiveMQ clients that using standard JMS APIs. In the future we will get more supports - for some advanced, ActiveMQ specific features into HornetQ. + for some advanced, ActiveMQ specific features into ActiveMQ.
diff --git a/docs/user-manual/en/jms-bridge.xml b/docs/user-manual/en/jms-bridge.xml index 13d5fb3ebc..208db8b38a 100644 --- a/docs/user-manual/en/jms-bridge.xml +++ b/docs/user-manual/en/jms-bridge.xml @@ -18,24 +18,24 @@ + %BOOK_ENTITIES; ]> The JMS Bridge - HornetQ includes a fully functional JMS message bridge. + ActiveMQ includes a fully functional JMS message bridge. The function of the bridge is to consume messages from a source queue or topic, and send them to a target queue or topic, typically on a different server. The source and target servers do not have to be in the same cluster which makes bridging suitable for reliably sending messages from one cluster to another, for instance across a WAN, and where the connection may be unreliable. - A bridge can be deployed as a standalone application, with HornetQ standalone server or inside a JBoss AS + A bridge can be deployed as a standalone application, with ActiveMQ standalone server or inside a JBoss AS instance. The source and the target can be located in the same virtual machine or another one. - The bridge can also be used to bridge messages from other non HornetQ JMS servers, as + The bridge can also be used to bridge messages from other non ActiveMQ JMS servers, as long as they are JMS 1.1 compliant.Do not confuse a JMS bridge with a core bridge. A JMS bridge can be used to bridge any two JMS 1.1 compliant JMS providers and uses the JMS API. A core bridge (described in ) is used to bridge any two HornetQ instances and + linkend="core-bridges"/>) is used to bridge any two ActiveMQ instances and uses the core API. Always use a core bridge if you can in preference to a JMS bridge. The core bridge will typically provide better performance than a JMS bridge. Also the core bridge can provide once and only once @@ -56,8 +56,8 @@ <?xml version="1.0" encoding="UTF-8"?> <deployment xmlns="urn:jboss:bean-deployer:2.0"> <bean name="JMSBridge" class="org.apache.activemq.api.jms.bridge.impl.JMSBridgeImpl"> - <!-- HornetQ must be started before the bridge --> - <depends>HornetQServer</depends> + <!-- ActiveMQ must be started before the bridge --> + <depends>ActiveMQServer</depends> <constructor> <!-- Source ConnectionFactory Factory --> <parameter> @@ -320,7 +320,7 @@ Add MessageID In Header If true, then the original message's message ID will be appended in the message sent to the destination in the header HORNETQ_BRIDGE_MSG_ID_LIST. If the message is bridged more + >ACTIVEMQ_BRIDGE_MSG_ID_LIST. If the message is bridged more than once, each message ID will be appended. This enables a distributed request-response pattern to be used @@ -341,10 +341,10 @@ The "transactionManager" property points to a JTA transaction manager implementation. - HornetQ doesn't ship with such an implementation, but one is available in the JBoss - Community. If you are running HornetQ in standalone mode and wish to use a JMS bridge + ActiveMQ doesn't ship with such an implementation, but one is available in the JBoss + Community. If you are running ActiveMQ in standalone mode and wish to use a JMS bridge simply download the latest version of JBossTS from http://www.jboss.org/jbosstm/downloads - and add it to HornetQ's classpath. If you are running HornetQ with JBoss AS then you + and add it to ActiveMQ's classpath. If you are running ActiveMQ with JBoss AS then you won't need to do this as JBoss AS ships with a JTA transaction manager already. The bean definition for the transaction manager would look something like this: @@ -356,7 +356,7 @@ connection factory used to create the connection for the source or target server. The configuration example above uses the default implementation provided by - HornetQ that looks up the connection factory using JNDI. For other Application + ActiveMQ that looks up the connection factory using JNDI. For other Application Servers or JMS providers a new implementation may have to be provided. This can easily be done by implementing the interface org.apache.activemq.jms.bridge.ConnectionFactoryFactory. @@ -364,7 +364,7 @@
Source and Target Destination Factories Again, similarly, these are used to create or lookup up the destinations. - In the configuration example above, we have used the default provided by HornetQ + In the configuration example above, we have used the default provided by ActiveMQ that looks up the destination using JNDI. A new implementation can be provided by implementing org.apache.activemq.jms.bridge.DestinationFactory interface. @@ -396,7 +396,7 @@ ONCE_AND_ONLY_ONCE This QoS mode ensures messages will reach the destination from the source once and only once. (Sometimes this mode is known as "exactly once"). If both the - source and the destination are on the same HornetQ server instance then this can + source and the destination are on the same ActiveMQ server instance then this can be achieved by sending and acknowledging the messages in the same local transaction. If the source and destination are on different servers this is achieved by enlisting the sending and consuming sessions in a JTA transaction. @@ -444,7 +444,7 @@ and use a JMS Bridge with JBoss AS to send messages to the source destination and consume them from the target destination. Please see which shows how to configure - and use a JMS Bridge between two standalone HornetQ servers. + and use a JMS Bridge between two standalone ActiveMQ servers.
diff --git a/docs/user-manual/en/jms-core-mapping.xml b/docs/user-manual/en/jms-core-mapping.xml index bc80b552af..9987440bcf 100644 --- a/docs/user-manual/en/jms-core-mapping.xml +++ b/docs/user-manual/en/jms-core-mapping.xml @@ -18,13 +18,13 @@ + %BOOK_ENTITIES; ]> Mapping JMS Concepts to the Core API - This chapter describes how JMS destinations are mapped to HornetQ addresses. - HornetQ core is JMS-agnostic. It does not have any concept of a JMS topic. A JMS topic is + This chapter describes how JMS destinations are mapped to ActiveMQ addresses. + ActiveMQ core is JMS-agnostic. It does not have any concept of a JMS topic. A JMS topic is implemented in core as an address (the topic name) with zero or more queues bound to it. Each queue bound to that address represents a topic subscription. Likewise, a JMS queue is implemented as an address (the JMS queue name) with one single queue bound to it which diff --git a/docs/user-manual/en/large-messages.xml b/docs/user-manual/en/large-messages.xml index 8c11c844d9..d98818111a 100644 --- a/docs/user-manual/en/large-messages.xml +++ b/docs/user-manual/en/large-messages.xml @@ -17,18 +17,18 @@ + %BOOK_ENTITIES; ]> Large Messages - HornetQ supports sending and receiving of huge messages, even when the client and server + ActiveMQ supports sending and receiving of huge messages, even when the client and server are running with limited memory. The only realistic limit to the size of a message that can be sent or consumed is the amount of disk space you have available. We have tested sending and consuming messages up to 8 GiB in size with a client and server running in just 50MiB of RAM! To send a large message, the user can set an InputStream on a message - body, and when that message is sent, HornetQ will read the InputStream. A + body, and when that message is sent, ActiveMQ will read the InputStream. A FileInputStream could be used for example to send a huge message from a huge file on disk. As the InputStream is read the data is sent to the server as a stream @@ -47,7 +47,7 @@ <configuration xmlns="urn:activemq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="urn:hornetq /schema/activemq-configuration.xsd"> + xsi:schemaLocation="urn:activemq /schema/activemq-configuration.xsd"> ... <large-messages-directory>/data/large-messages</large-messages-directory> ... @@ -62,8 +62,8 @@ will be split up and sent in fragments. This is determined by the parameter min-large-message-size - HornetQ messages are encoded using 2 bytes per character so if the message data is filled - with ASCII characters (which are 1 byte) the size of the resulting HornetQ message would roughly + ActiveMQ messages are encoded using 2 bytes per character so if the message data is filled + with ASCII characters (which are 1 byte) the size of the resulting ActiveMQ message would roughly double. This is important when calculating the size of a "large" message as it may appear to be less than the min-large-message-size before it is sent, but it then turns into a "large" message once it is encoded. @@ -71,21 +71,21 @@ The default value is 100KiB.
Using Core API - If the HornetQ Core API is used, the minimal large message size is specified by + If the ActiveMQ Core API is used, the minimal large message size is specified by ServerLocator.setMinLargeMessageSize. -ServerLocator locator = HornetQClient.createServerLocatorWithoutHA(new TransportConfiguration(NettyConnectorFactory.class.getName())) +ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(new TransportConfiguration(NettyConnectorFactory.class.getName())) locator.setMinLargeMessageSize(25 * 1024); -ClientSessionFactory factory = HornetQClient.createClientSessionFactory(); +ClientSessionFactory factory = ActiveMQClient.createClientSessionFactory(); will provide more information on how to instantiate the session factory.
Using JMS If JNDI is used to look up the connection factory, the minimum large message size - is specified in hornetq-jms.xml + is specified in activemq-jms.xml ... <connection-factory name="ConnectionFactory"> <connectors> @@ -101,7 +101,7 @@ ClientSessionFactory factory = HornetQClient.createClientSessionFactory(); If the connection factory is being instantiated directly, the minimum large message size is specified by HornetQConnectionFactory.setMinLargeMessageSize. + >ActiveMQConnectionFactory.setMinLargeMessageSize.
Compressed Large Messages @@ -138,7 +138,7 @@ ClientSessionFactory factory = HornetQClient.createClientSessionFactory();
Streaming large messages - HornetQ supports setting the body of messages using input and output streams (ActiveMQ supports setting the body of messages using input and output streams (java.lang.io) These streams are then used directly for sending (input streams) and receiving (output streams) messages. @@ -221,7 +221,7 @@ msg.setInputStream(dataInputStream);
Streaming over JMS - When using JMS, HornetQ maps the streaming methods on the core API (see When using JMS, ActiveMQ maps the streaming methods on the core API (see ) by setting object properties . You can use the method Message.setObjectProperty to set the input and output streams. @@ -264,7 +264,7 @@ messageReceived.setObjectProperty("JMS_HQ_OutputStream", bufferedOutput); Streaming Alternative If you choose not to use the InputStream or OutputStream capability of HornetQ You could still access the data + >OutputStream capability of ActiveMQ You could still access the data directly in an alternative fashion. On the Core API just get the bytes of the body as you normally would. diff --git a/docs/user-manual/en/last-value-queues.xml b/docs/user-manual/en/last-value-queues.xml index def6115716..f38f760065 100644 --- a/docs/user-manual/en/last-value-queues.xml +++ b/docs/user-manual/en/last-value-queues.xml @@ -18,7 +18,7 @@ + %BOOK_ENTITIES; ]> diff --git a/docs/user-manual/en/libaio.xml b/docs/user-manual/en/libaio.xml index d0e2c760a4..9a287e307b 100644 --- a/docs/user-manual/en/libaio.xml +++ b/docs/user-manual/en/libaio.xml @@ -18,12 +18,12 @@ + %BOOK_ENTITIES; ]> Libaio Native Libraries - HornetQ distributes a native library, used as a bridge between HornetQ and Linux + ActiveMQ distributes a native library, used as a bridge between ActiveMQ and Linux libaio. libaio is a library, developed as part of the Linux kernel project. With libaio we submit writes to the operating system where they are @@ -31,16 +31,16 @@ processed. We use this in our high performance journal if configured to do so, please see . - These are the native libraries distributed by HornetQ: + These are the native libraries distributed by ActiveMQ: - libHornetQAIO32.so - x86 32 bits + libActiveMQAIO32.so - x86 32 bits - libHornetQAIO64.so - x86 64 bits + libActiveMQAIO64.so - x86 64 bits - When using libaio, HornetQ will always try loading these files as long as they are on the + When using libaio, ActiveMQ will always try loading these files as long as they are on the library path.
Compiling the native libraries @@ -120,10 +120,10 @@ config.status: executing libtool commands ... The produced library will be at ./native-src/src/.libs/libHornetQAIO.so. Simply move that file over + >./native-src/src/.libs/libActiveMQAIO.so. Simply move that file over bin on the distribution or the place you have chosen on the library path. - If you want to perform changes on the HornetQ libaio code, you could just call + If you want to perform changes on the ActiveMQ libaio code, you could just call make directly at the native-src directory.
diff --git a/docs/user-manual/en/logging.xml b/docs/user-manual/en/logging.xml index c65f3e8c7b..33dc4f9d31 100644 --- a/docs/user-manual/en/logging.xml +++ b/docs/user-manual/en/logging.xml @@ -18,12 +18,12 @@ + %BOOK_ENTITIES; ]> Logging - HornetQ uses the JBoss Logging framework to do its logging and is configurable via the logging.properties + ActiveMQ uses the JBoss Logging framework to do its logging and is configurable via the logging.properties file found in the configuration directories. This is configured by Default to log to both the console and to a file. There are 6 loggers available which are as follows:
@@ -40,7 +40,7 @@ org.jboss.logging - Logs any calls not handled by the HornetQ loggers + Logs any calls not handled by the ActiveMQ loggers org.apache.activemq.core.server @@ -92,7 +92,7 @@ </dependency> <dependency> <groupId>org.apache.activemq</groupId> - <artifactId>hornetq-core-client</artifactId> + <artifactId>activemq-core-client</artifactId> <version>2.3.0.Final</version> </dependency> The first dependency jnp-client is not actually needed for logging, however this is needed for @@ -116,7 +116,7 @@ loggers=org.jboss.logging,org.apache.activemq.core.server,org.apache.activemq.ut # Root logger level logger.level=INFO -# HornetQ logger levels +# ActiveMQ logger levels logger.org.apache.activemq.core.server.level=INFO logger.org.apache.activemq.utils.level=INFO logger.org.apache.activemq.jms.level=DEBUG @@ -136,7 +136,7 @@ handler.FILE=org.jboss.logmanager.handlers.FileHandler handler.FILE.level=FINE handler.FILE.properties=autoFlush,fileName handler.FILE.autoFlush=true -handler.FILE.fileName=hornetq.log +handler.FILE.fileName=activemq.log handler.FILE.formatter=PATTERN # Formatter pattern configuration @@ -147,7 +147,7 @@ formatter.PATTERN.pattern=%d{HH:mm:ss,SSS} %-5p [%c] %s%E%n
Logging With The JBoss Application Server - When HornetQ is deployed within the JBoss Application Server version 7.x or above then + When ActiveMQ is deployed within the JBoss Application Server version 7.x or above then it will still use JBoss Logging, refer to the AS7 documentation on how to configure AS7 logging.
diff --git a/docs/user-manual/en/management.xml b/docs/user-manual/en/management.xml index b9576a05dd..0f987c58c4 100644 --- a/docs/user-manual/en/management.xml +++ b/docs/user-manual/en/management.xml @@ -18,31 +18,31 @@ + %BOOK_ENTITIES; ]> Management - HornetQ has an extensive management API that allows a user to modify a server + ActiveMQ has an extensive management API that allows a user to modify a server configuration, create new resources (e.g. JMS queues and topics), inspect these resources (e.g. how many messages are currently held in a queue) and interact with it (e.g. to remove messages from a queue). All the operations allows a client to manage - HornetQ. It also allows clients to subscribe to management notifications. - There are 3 ways to manage HornetQ: + ActiveMQ. It also allows clients to subscribe to management notifications. + There are 3 ways to manage ActiveMQ: Using JMX -- JMX is the standard way to manage Java applications - Using the core API -- management operations are sent to HornetQ server using + Using the core API -- management operations are sent to ActiveMQ server using core messages - Using the JMS API -- management operations are sent to HornetQ server using + Using the JMS API -- management operations are sent to ActiveMQ server using JMS messages - Although there are 3 different ways to manage HornetQ each API supports the same + Although there are 3 different ways to manage ActiveMQ each API supports the same functionality. If it is possible to manage a resource using JMX it is also possible to achieve the same result using Core messages or JMS messages. This choice depends on your requirements, your application settings and your environment to @@ -53,7 +53,7 @@ management API is the same. For each managed resource, there exists a Java interface describing what can be invoked for this type of resource. - HornetQ exposes its managed resources in 2 packages: + ActiveMQ exposes its managed resources in 2 packages: Core resources are located in the
Core Management API - HornetQ defines a core management API to manage core resources. For full details of + ActiveMQ defines a core management API to manage core resources. For full details of the API please consult the javadoc. In summary:
Core Server Management @@ -86,7 +86,7 @@ Core queues can be created or destroyed using the management operations createQueue() or deployQueue() or destroyQueue())on the HornetQServerControl (with the ObjectName ActiveMQServerControl (with the ObjectName org.apache.activemq:module=Core,type=Server or the resource name core.server) createQueue will fail if the queue already exists while @@ -132,7 +132,7 @@ Retrieving the server configuration and attributes - The HornetQServerControl exposes HornetQ server + The ActiveMQServerControl exposes ActiveMQ server configuration through all its attributes (e.g. getVersion() method to retrieve the server's version, etc.) @@ -143,14 +143,14 @@ Core bridges (resp. diverts) can be created or destroyed using the management operations createBridge() and destroyBridge() (resp. createDivert() and destroyDivert()) on the HornetQServerControl (with the ObjectName ActiveMQServerControl (with the ObjectName org.apache.activemq:module=Core,type=Server or the resource name core.server). It is possible to stop the server and force failover to occur with any currently attached clients. to do this use the forceFailover() on the HornetQServerControl (with the ObjectName ActiveMQServerControl (with the ObjectName org.apache.activemq:module=Core,type=Server or the resource name core.server) @@ -258,7 +258,7 @@
Other Core Resources Management - HornetQ allows to start and stop its remote resources (acceptors, diverts, + ActiveMQ allows to start and stop its remote resources (acceptors, diverts, bridges, etc.) so that a server can be taken off line for a given period of time without stopping it completely (e.g. if other management operations must be performed such as resolving heuristic transactions). These resources are: @@ -335,7 +335,7 @@
JMS Management API - HornetQ defines a JMS Management API to manage JMS administrated + ActiveMQ defines a JMS Management API to manage JMS administrated objects (i.e. JMS queues, topics and connection factories).
JMS Server Management @@ -520,10 +520,10 @@
Using Management Via JMX - HornetQ can be managed using ActiveMQ can be managed using JMX. - The management API is exposed by HornetQ using MBeans interfaces. HornetQ registers its + The management API is exposed by ActiveMQ using MBeans interfaces. ActiveMQ registers its resources with the domain org.apache.activemq. For example, the ObjectName to manage a JMS Queue exampleQueue is: @@ -536,17 +536,17 @@ org.apache.activemq.api.jms.management.JMSQueueControl >org.apache.activemq.api.core.management.ObjectNameBuilder. You can also use jconsole to find the ObjectName of the MBeans you want to manage. - Managing HornetQ using JMX is identical to management of any Java Applications using + Managing ActiveMQ using JMX is identical to management of any Java Applications using JMX. It can be done by reflection or by creating proxies of the MBeans.
Configuring JMX - By default, JMX is enabled to manage HornetQ. It can be disabled by setting By default, JMX is enabled to manage ActiveMQ. It can be disabled by setting jmx-management-enabled to false in hornetq-configuration.xml: + >activemq-configuration.xml: -<!-- false to disable JMX management for HornetQ --> +<!-- false to disable JMX management for ActiveMQ --> <jmx-management-enabled>false</jmx-management-enabled> - If JMX is enabled, HornetQ can be managed locally using jconsole. + If JMX is enabled, ActiveMQ can be managed locally using jconsole. Remote connections to JMX are not enabled by default for security reasons. Please refer to properties must be set in run.sh or run.bat scripts). - By default, HornetQ server uses the JMX domain "org.apache.activemq". To manage several - HornetQ servers from the same MBeanServer, the JMX domain can be - configured for each individual HornetQ server by setting jmx-domain - in hornetq-configuration.xml: + By default, ActiveMQ server uses the JMX domain "org.apache.activemq". To manage several + ActiveMQ servers from the same MBeanServer, the JMX domain can be + configured for each individual ActiveMQ server by setting jmx-domain + in activemq-configuration.xml: -<!-- use a specific JMX domain for HornetQ MBeans --> +<!-- use a specific JMX domain for ActiveMQ MBeans --> <jmx-domain>my.org.apache.activemq</jmx-domain>
MBeanServer configuration - When HornetQ is run in standalone, it uses the Java Virtual Machine's When ActiveMQ is run in standalone, it uses the Java Virtual Machine's Platform MBeanServer to register its MBeans. This is configured in JBoss Microcontainer Beans file (see ): @@ -586,12 +586,12 @@ org.apache.activemq.api.jms.management.JMSQueueControl
Example See for an example which shows how to use a remote - connection to JMX and MBean proxies to manage HornetQ. + connection to JMX and MBean proxies to manage ActiveMQ.
Using Management Via Core API - The core management API in HornetQ is called by sending Core messages to a special + The core management API in ActiveMQ is called by sending Core messages to a special address, the management address. Management messages are regular Core messages with well-known properties that the server needs to understand to interact with the management API: @@ -606,7 +606,7 @@ org.apache.activemq.api.jms.management.JMSQueueControl The parameters of the management operation - When such a management message is sent to the management address, HornetQ server will + When such a management message is sent to the management address, ActiveMQ server will handle it, extract the information, invoke the operation on the managed resources and send a management reply to the management message's reply-to address (specified by ClientMessageImpl.REPLYTO_HEADER_NAME). @@ -643,7 +643,7 @@ org.apache.activemq.api.jms.management.JMSQueueControl >exampleQueue: ClientSession session = ... -ClientRequestor requestor = new ClientRequestor(session, "jms.queue.hornetq.management"); +ClientRequestor requestor = new ClientRequestor(session, "jms.queue.activemq.management"); ClientMessage message = session.createMessage(false); ManagementHelper.putAttribute(message, "core.queue.exampleQueue", "messageCount"); session.start(); @@ -660,31 +660,31 @@ System.out.println("There are " + count + " messages in exampleQueue"); Configuring Core Management The management address to send management messages is configured in hornetq-configuration.xml: + >activemq-configuration.xml: -<management-address>jms.queue.hornetq.management</management-address> - By default, the address is jms.queue.hornetq.management (it is +<management-address>jms.queue.activemq.management</management-address> + By default, the address is jms.queue.activemq.management (it is prepended by "jms.queue" so that JMS clients can also send management messages). The management address requires a special user permission manage to be able to receive and handle management messages. This - is also configured in hornetq-configuration.xml: + is also configured in activemq-configuration.xml: <!-- users with the admin role will be allowed to manage --> -<!-- HornetQ using management messages --> -<security-setting match="jms.queue.hornetq.management"> +<!-- ActiveMQ using management messages --> +<security-setting match="jms.queue.activemq.management"> <permission type="manage" roles="admin" /> </security-setting>
Using Management Via JMS - Using JMS messages to manage HornetQ is very similar to using core API. + Using JMS messages to manage ActiveMQ is very similar to using core API. An important difference is that JMS requires a JMS queue to send the messages to (instead of an address for the core API). The management queue is a special queue and needs to be instantiated directly by the client: -Queue managementQueue = HornetQJMSClient.createQueue("hornetq.management"); +Queue managementQueue = ActiveMQJMSClient.createQueue("activemq.management"); All the other steps are the same than for the Core API but they use JMS API instead: @@ -712,7 +712,7 @@ Queue managementQueue = HornetQJMSClient.createQueue("hornetq.management");For example, to know the number of messages in the JMS queue exampleQueue: -Queue managementQueue = HornetQJMSClient.createQueue("hornetq.management"); +Queue managementQueue = ActiveMQJMSClient.createQueue("activemq.management"); QueueSession session = ... QueueRequestor requestor = new QueueRequestor(session, managementQueue); @@ -730,13 +730,13 @@ System.out.println("There are " + count + " messages in exampleQueue"); Example See for an example which shows how to use JMS - messages to manage HornetQ server. + messages to manage ActiveMQ server.
Management Notifications - HornetQ emits notifications to inform listeners of potentially + ActiveMQ emits notifications to inform listeners of potentially interesting events (creation of new resources, security violation, etc.). These notifications can be received by 3 different ways: @@ -767,7 +767,7 @@ System.out.println("There are " + count + " messages in exampleQueue");
Core Messages Notifications - HornetQ defines a special management notification address. Core + ActiveMQ defines a special management notification address. Core queues can be bound to this address so that clients will receive management notifications as Core messages A Core client which wants to receive management notifications must create a core @@ -782,15 +782,15 @@ System.out.println("There are " + count + " messages in exampleQueue"); Configuring The Core Management Notification Address The management notification address to receive management notifications is - configured in hornetq-configuration.xml: + configured in activemq-configuration.xml: -<management-notification-address>hornetq.notifications</management-notification-address> - By default, the address is hornetq.notifications. +<management-notification-address>activemq.notifications</management-notification-address> + By default, the address is activemq.notifications.
JMS Messages Notifications - HornetQ's notifications can also be received using JMS messages. + ActiveMQ's notifications can also be received using JMS messages. It is similar to receiving notifications using Core API but an important difference is that JMS requires a JMS Destination to receive the messages (preferably a Topic). @@ -803,7 +803,7 @@ System.out.println("There are " + count + " messages in exampleQueue");Once the notification topic is created, you can receive messages from it or set a MessageListener: -Topic notificationsTopic = HornetQJMSClient.createTopic("notificationsTopic"); +Topic notificationsTopic = ActiveMQJMSClient.createTopic("notificationsTopic"); Session session = ... MessageConsumer notificationConsumer = session.createConsumer(notificationsTopic); @@ -833,7 +833,7 @@ notificationConsumer.setMessageListener(new MessageListener() Example See for an example which shows how to use a JMS MessageListener to receive management notifications - from HornetQ server. + from ActiveMQ server.
Notification Types and Headers @@ -980,7 +980,7 @@ notificationConsumer.setMessageListener(new MessageListener()
Message Counters Message counters can be used to obtain information on queues over - time as HornetQ keeps a history on queue metrics. + time as ActiveMQ keeps a history on queue metrics. They can be used to show trends on queues. For example, using the management API, it would be possible to query the number of messages in a queue at regular interval. However, this would not be enough to know if the queue is used: the number of @@ -1029,13 +1029,13 @@ notificationConsumer.setMessageListener(new MessageListener() By default, message counters are disabled as it might have a small negative effect on memory. To enable message counters, you can set it to true in hornetq-configuration.xml: + >activemq-configuration.xml: <message-counter-enabled>true</message-counter-enabled> Message counters keeps a history of the queue metrics (10 days by default) and samples all the queues at regular interval (10 seconds by default). If message counters are enabled, these values should be configured to suit your messaging use case in - hornetq-configuration.xml: + activemq-configuration.xml: <!-- keep history for a week --> <message-counter-max-day-history>7</message-counter-max-day-history> @@ -1044,7 +1044,7 @@ notificationConsumer.setMessageListener(new MessageListener() Message counters can be retrieved using the Management API. For example, to retrieve message counters on a JMS Queue using JMX: -// retrieve a connection to HornetQ's MBeanServer +// retrieve a connection to ActiveMQ's MBeanServer MBeanServerConnection mbsc = ... JMSQueueControlMBean queueControl = (JMSQueueControl)MBeanServerInvocationHandler.newProxyInstance(mbsc, on, @@ -1065,10 +1065,10 @@ messageCounter.getMessageCountDelta());
- Administering HornetQ Resources Using The JBoss AS Admin Console - Its possible to create and configure HornetQ resources via the admin console within the JBoss Application Server. + Administering ActiveMQ Resources Using The JBoss AS Admin Console + Its possible to create and configure ActiveMQ resources via the admin console within the JBoss Application Server. The Admin Console will allow you to create destinations (JMS Topics and Queues) and JMS Connection Factories. - Once logged in to the admin console you will see a JMS Manager item in the left hand tree. All HornetQ resources + Once logged in to the admin console you will see a JMS Manager item in the left hand tree. All ActiveMQ resources will be configured via this. This will have a child items for JMS Queues, Topics and Connection Factories, clicking on each node will reveal which resources are currently available. The following sections explain how to create and configure each resource in turn. diff --git a/docs/user-manual/en/message-expiry.xml b/docs/user-manual/en/message-expiry.xml index e4d1f3762d..f4d66ee487 100644 --- a/docs/user-manual/en/message-expiry.xml +++ b/docs/user-manual/en/message-expiry.xml @@ -18,23 +18,23 @@ + %BOOK_ENTITIES; ]> Message Expiry Messages can be set with an optional time to live when sending them. - HornetQ will not deliver a message to a consumer after it's time to live has been exceeded. + ActiveMQ will not deliver a message to a consumer after it's time to live has been exceeded. If the message hasn't been delivered by the time that time to live is reached the server can discard it. - HornetQ's addresses can be assigned a expiry address so that, when messages are expired, + ActiveMQ's addresses can be assigned a expiry address so that, when messages are expired, they are removed from the queue and sent to the expiry address. Many different queues can be bound to an expiry address. These expired messages can later be consumed for further inspection.
Message Expiry - Using HornetQ Core API, you can set an expiration time directly on the message: + Using ActiveMQ Core API, you can set an expiration time directly on the message: // message will expire in 5000ms from now message.setExpiration(System.currentTimeMillis() + 5000); @@ -79,7 +79,7 @@ producer.setTimeToLive(5000); A reaper thread will periodically inspect the queues to check if messages have expired. The reaper thread can be configured with the following properties in hornetq-configuration.xml + >activemq-configuration.xml message-expiry-scan-period diff --git a/docs/user-manual/en/message-grouping.xml b/docs/user-manual/en/message-grouping.xml index ce4e04c718..e739996750 100644 --- a/docs/user-manual/en/message-grouping.xml +++ b/docs/user-manual/en/message-grouping.xml @@ -18,7 +18,7 @@ + %BOOK_ENTITIES; ]> @@ -28,7 +28,7 @@ Messages in a message group share the same group id, i.e. they have same group identifier property (JMSXGroupID for JMS, _HQ_GROUP_ID for HornetQ Core API). + >_HQ_GROUP_ID for ActiveMQ Core API). Messages in a message group are always consumed by the same consumer, even if there @@ -79,8 +79,8 @@ message.setStringProperty("JMSXGroupID", "Group-0"); producer.send(message); Alternatively, you can set autogroup to true on the HornetQConnectonFactory which will pick a random unique id. This can also be - set in the hornetq-jms.xml file like this: + >ActiveMQConnectonFactory which will pick a random unique id. This can also be + set in the activemq-jms.xml file like this: <connection-factory name="ConnectionFactory"> <connectors> @@ -94,7 +94,7 @@ Alternatively you can set the group id via the connection factory. All messages sent with producers created via this connection factory will set the JMSXGroupID to the specified value on all messages sent. To configure the - group id set it on the connection factory in the hornetq-jms.xml config + group id set it on the connection factory in the activemq-jms.xml config file as follows <connection-factory name="ConnectionFactory"> @@ -132,7 +132,7 @@ local handler that actually makes the decision as to what route should be used, all the other remote handlers converse with this. Here is a sample config for both types of handler, this should be configured in the hornetq-configuration.xml + >activemq-configuration.xml file. <grouping-handler name="my-grouping-handler"> <type>LOCAL</type> @@ -201,7 +201,7 @@
Clustered Grouping Example See for an example of how to configure - message groups with a HornetQ cluster + message groups with a ActiveMQ cluster
diff --git a/docs/user-manual/en/messaging-concepts.xml b/docs/user-manual/en/messaging-concepts.xml index 241fd98608..f1f4853531 100644 --- a/docs/user-manual/en/messaging-concepts.xml +++ b/docs/user-manual/en/messaging-concepts.xml @@ -18,12 +18,12 @@ + %BOOK_ENTITIES; ]> Messaging Concepts - HornetQ is an asynchronous messaging system, an example of ActiveMQ is an asynchronous messaging system, an example of Message Oriented Middleware , we'll just call them messaging systems in the remainder of this book. @@ -141,7 +141,7 @@
Transactions Messaging systems typically support the sending and acknowledgement of multiple - messages in a single local transaction. HornetQ also supports the sending and + messages in a single local transaction. ActiveMQ also supports the sending and acknowledgement of message as part of a large global transaction - using the Java mapping of XA: JTA.
@@ -175,7 +175,7 @@ JMS does not define a standard wire format - it only defines a programmatic API so JMS clients and servers from different vendors cannot directly interoperate since each will use the vendor's own internal wire protocol. - HornetQ provides a fully compliant JMS 1.1 and JMS 2.0 API. + ActiveMQ provides a fully compliant JMS 1.1 and JMS 2.0 API.
System specific APIs @@ -184,7 +184,7 @@ functionality to be exposed to the client application. API's like JMS are not normally rich enough to expose all the extra features that most messaging systems provide. - HornetQ provides its own core client API for clients to use if they wish to have + ActiveMQ provides its own core client API for clients to use if they wish to have access to functionality over and above that accessible via the JMS API.
@@ -201,7 +201,7 @@ protocol. The advantage of a REST approach with HTTP is in its simplicity and the fact the internet is already tuned to deal with HTTP optimally. - Please see for using HornetQ's RESTful interface. + Please see for using ActiveMQ's RESTful interface.
STOMP @@ -211,7 +211,7 @@ systems. It defines a wire format, so theoretically any Stomp client can work with any messaging system that supports Stomp. Stomp clients are available in many different programming languages. - Please see for using STOMP with HornetQ. + Please see for using STOMP with ActiveMQ.
AMQP @@ -219,8 +219,8 @@ interoperable messaging. It also defines a wire format, so any AMQP client can work with any messaging system that supports AMQP. AMQP clients are available in many different programming languages. - HornetQ implements the AMQP 1.0 - specification. Any client that supports the 1.0 specification will be able to interact with HornetQ. + ActiveMQ implements the AMQP 1.0 + specification. Any client that supports the 1.0 specification will be able to interact with ActiveMQ.
@@ -228,7 +228,7 @@ High Availability (HA) means that the system should remain operational after failure of one or more of the servers. The degree of support for HA varies between various messaging systems. - HornetQ provides automatic failover where your sessions are automatically reconnected + ActiveMQ provides automatic failover where your sessions are automatically reconnected to the backup server on event of live server failure. For more information on HA, please see .
@@ -241,10 +241,10 @@ Degrees of support for clusters varies between messaging systems, with some systems having fairly basic clusters with the cluster members being hardly aware of each other. - HornetQ provides very configurable state-of-the-art clustering model where messages + ActiveMQ provides very configurable state-of-the-art clustering model where messages can be intelligently load balanced between the servers in the cluster, according to the number of consumers on each node, and whether they are ready for messages. - HornetQ also has the ability to automatically redistribute messages between nodes of a + ActiveMQ also has the ability to automatically redistribute messages between nodes of a cluster to prevent starvation on any particular node. For full details on clustering, please see .
@@ -256,9 +256,9 @@ A bridge normally consumes from a queue on one server and forwards messages to another queue on a different server. Bridges cope with unreliable connections, automatically reconnecting when the connections becomes available again. - HornetQ bridges can be configured with filter expressions to only forward certain + ActiveMQ bridges can be configured with filter expressions to only forward certain messages, and transformation can also be hooked in. - HornetQ also allows routing between queues to be configured in server side + ActiveMQ also allows routing between queues to be configured in server side configuration. This allows complex routing networks to be set up forwarding or copying messages from one destination to another, forming a global network of interconnected brokers. diff --git a/docs/user-manual/en/notice.xml b/docs/user-manual/en/notice.xml index 5ed879bd2d..798c27d547 100644 --- a/docs/user-manual/en/notice.xml +++ b/docs/user-manual/en/notice.xml @@ -17,7 +17,7 @@ + %BOOK_ENTITIES; ]> diff --git a/docs/user-manual/en/paging.xml b/docs/user-manual/en/paging.xml index ba82cb0f23..5affad628a 100644 --- a/docs/user-manual/en/paging.xml +++ b/docs/user-manual/en/paging.xml @@ -17,19 +17,19 @@ + %BOOK_ENTITIES; ]> Paging - HornetQ transparently supports huge queues containing millions of messages while the + ActiveMQ transparently supports huge queues containing millions of messages while the server is running with limited memory. In such a situation it's not possible to store all of the queues in memory at any one - time, so HornetQ transparently pages messages into and out of memory as + time, so ActiveMQ transparently pages messages into and out of memory as they are needed, thus allowing massive queues with a low memory footprint. - HornetQ will start paging messages to disk, when the size of all messages in memory for an + ActiveMQ will start paging messages to disk, when the size of all messages in memory for an address exceeds a configured maximum size. - By default, HornetQ does not page messages - this must be explicitly configured to + By default, ActiveMQ does not page messages - this must be explicitly configured to activate it.
Page Files @@ -46,11 +46,11 @@ Configuration You can configure the location of the paging folder Global paging parameters are specified on the main configuration file (hornetq-configuration.xml). + >activemq-configuration.xml). <configuration xmlns="urn:activemq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="urn:hornetq /schema/activemq-configuration.xsd"> + xsi:schemaLocation="urn:activemq /schema/activemq-configuration.xsd"> ... <paging-directory>/somewhere/paging-directory</paging-directory> ... @@ -71,7 +71,7 @@
paging-directory - Where page files are stored. HornetQ will create one folder for + Where page files are stored. ActiveMQ will create one folder for each address being paged under this configured location. data/paging @@ -93,7 +93,7 @@
Configuration Configuration is done at the address settings, done at the main configuration file - (hornetq-configuration.xml). + (activemq-configuration.xml). <address-settings> <address-setting match="jms.someaddress"> @@ -211,6 +211,6 @@
Example See for an example which shows how to use paging - with HornetQ. + with ActiveMQ.
diff --git a/docs/user-manual/en/perf-tuning.xml b/docs/user-manual/en/perf-tuning.xml index da0c2ede70..7866d82d0d 100644 --- a/docs/user-manual/en/perf-tuning.xml +++ b/docs/user-manual/en/perf-tuning.xml @@ -18,12 +18,12 @@ + %BOOK_ENTITIES; ]> Performance Tuning - In this chapter we'll discuss how to tune HornetQ for optimum performance. + In this chapter we'll discuss how to tune ActiveMQ for optimum performance.
Tuning persistence @@ -105,7 +105,7 @@ incur a lot more overhead in persisting them to storage. - Batch many sends or acknowledgements in a single transaction. HornetQ will + Batch many sends or acknowledgements in a single transaction. ActiveMQ will only require a network round trip on the commit, not on every send or acknowledgement. @@ -113,7 +113,7 @@
Other Tunings - There are various other places in HornetQ where we can perform some tuning: + There are various other places in ActiveMQ where we can perform some tuning: Use Asynchronous Send Acknowledgements. If you need to send durable messages @@ -132,17 +132,17 @@ Disable security. You may get a small performance boost by disabling security by setting the security-enabled parameter to false in hornetq-configuration.xml. + >false in activemq-configuration.xml. Disable persistence. If you don't need message persistence, turn it off altogether by setting persistence-enabled to false in - hornetq-configuration.xml. + activemq-configuration.xml. Sync transactions lazily. Setting journal-sync-transactional to false in - hornetq-configuration.xml can give you better + activemq-configuration.xml can give you better transactional persistent performance at the expense of some possibility of loss of transactions on failure. See for more information. @@ -150,7 +150,7 @@ Sync non transactional lazily. Setting journal-sync-non-transactional to false in - hornetq-configuration.xml can give you better + activemq-configuration.xml can give you better non-transactional persistent performance at the expense of some possibility of loss of durable messages on failure. See for more information. @@ -158,7 +158,7 @@ Send messages non blocking. Setting block-on-durable-send and block-on-non-durable-send to false in - hornetq-jms.xml (if you're using JMS and JNDI) or + activemq-jms.xml (if you're using JMS and JNDI) or directly on the ServerLocator. This means you don't have to wait a whole network round trip for every message sent. See for more information. @@ -168,7 +168,7 @@ effectively disables consumer flow control. - Socket NIO vs Socket Old IO. By default HornetQ uses old (blocking) on the + Socket NIO vs Socket Old IO. By default ActiveMQ uses old (blocking) on the server and the client side (see the chapter on configuring transports for more information ). NIO is much more scalable but can give you some latency hit compared to old blocking IO. If you need to be @@ -218,11 +218,11 @@ serveruser hard nofile 20000 Use batch-delay and set direct-deliver - to false for the best throughput for very small messages. HornetQ comes with a + to false for the best throughput for very small messages. ActiveMQ comes with a preconfigured connector/acceptor pair (netty-throughput) in - hornetq-configuration.xml and JMS connection factory + activemq-configuration.xml and JMS connection factory (ThroughputConnectionFactory) in hornetq-jms.xmlwhich can be used to give the very best + >activemq-jms.xmlwhich can be used to give the very best throughput, especially for small messages. See the for more information on this. @@ -240,7 +240,7 @@ serveruser hard nofile 20000 >-XX:+UseParallelOldGC on Sun JDKs. - Memory settings. Give as much memory as you can to the server. HornetQ can run + Memory settings. Give as much memory as you can to the server. ActiveMQ can run in low memory by using paging (described in ) but if it can run with all queues in RAM this will improve performance. The amount of memory you require will depend on the size and number of your queues and the @@ -272,7 +272,7 @@ serveruser hard nofile 20000 Some popular libraries such as the Spring JMS Template are known to use these anti-patterns. If you're using Spring JMS Template and you're getting - poor performance you know why. Don't blame HornetQ! The Spring JMS Template + poor performance you know why. Don't blame ActiveMQ! The Spring JMS Template can only safely be used in an app server which caches JMS sessions (e.g. using JCA), and only then for sending messages. It cannot be safely be used for synchronously consuming messages, even in an app server. diff --git a/docs/user-manual/en/persistence.xml b/docs/user-manual/en/persistence.xml index 14d107894f..5ab28d98fd 100644 --- a/docs/user-manual/en/persistence.xml +++ b/docs/user-manual/en/persistence.xml @@ -18,17 +18,17 @@ + %BOOK_ENTITIES; ]> Persistence - In this chapter we will describe how persistence works with HornetQ and how to configure + In this chapter we will describe how persistence works with ActiveMQ and how to configure it. - HornetQ ships with a high performance journal. Since HornetQ handles its own persistence, + ActiveMQ ships with a high performance journal. Since ActiveMQ handles its own persistence, rather than relying on a database or other 3rd party persistence engine it is very highly optimised for the specific messaging use cases. - A HornetQ journal is an append only journal. It consists of a set of + A ActiveMQ journal is an append only journal. It consists of a set of files on disk. Each file is pre-created to a fixed size and initially filled with padding. As operations are performed on the server, e.g. add message, update message, delete message, records are appended to the journal. When one journal file is full we move to the next @@ -42,16 +42,16 @@ by minimising the number of disk cylinders the file is using, we can minimise the amount of disk head movement, since an entire disk cylinder is accessible simply by the disk rotating - the head does not have to move. - As delete records are added to the journal, HornetQ has a sophisticated file garbage + As delete records are added to the journal, ActiveMQ has a sophisticated file garbage collection algorithm which can determine if a particular journal file is needed any more - i.e. has all its data been deleted in the same or other files. If so, the file can be reclaimed and re-used. - HornetQ also has a compaction algorithm which removes dead space from the journal and + ActiveMQ also has a compaction algorithm which removes dead space from the journal and compresses up the data so it takes up less files on disk. The journal also fully supports transactional operation if required, supporting both local and XA transactions. The majority of the journal is written in Java, however we abstract out the interaction - with the actual file system to allow different pluggable implementations. HornetQ ships with + with the actual file system to allow different pluggable implementations. ActiveMQ ships with two implementations: @@ -63,7 +63,7 @@ Linux Asynchronous IO The second implementation uses a thin native code wrapper to talk to the Linux - asynchronous IO library (AIO). With AIO, HornetQ will be called back when the data + asynchronous IO library (AIO). With AIO, ActiveMQ will be called back when the data has made it to disk, allowing us to avoid explicit syncs altogether and simply send back confirmation of completion when AIO informs us that the data has been persisted. @@ -80,7 +80,7 @@ libaio is part of the kernel project. - The standard HornetQ core server uses two instances of the journal: + The standard ActiveMQ core server uses two instances of the journal: Bindings journal. @@ -89,7 +89,7 @@ such as id sequence counters. The bindings journal is always a NIO journal as it is typically low throughput compared to the message journal. - The files on this journal are prefixed as hornetq-bindings. + The files on this journal are prefixed as activemq-bindings. Each file has a bindings extension. File size is 1048576, and it is located at the bindings folder. @@ -101,7 +101,7 @@ Any JMS Resources created via the management API will be persisted to this journal. Any resources configured via configuration files will not. The JMS Journal will only be created if JMS is being used. - The files on this journal are prefixed as hornetq-jms. Each + The files on this journal are prefixed as activemq-jms. Each file has a jms extension. File size is 1048576, and it is located at the bindings folder. @@ -109,26 +109,26 @@ Message journal. This journal instance stores all message related data, including the message themselves and also duplicate-id caches. - By default HornetQ will try and use an AIO journal. If AIO is not available, e.g. + By default ActiveMQ will try and use an AIO journal. If AIO is not available, e.g. the platform is not Linux with the correct kernel version or AIO has not been installed then it will automatically fall back to using Java NIO which is available on any Java platform. - The files on this journal are prefixed as hornetq-data. Each + The files on this journal are prefixed as activemq-data. Each file has a hq extension. File size is by the default 10485760 (configurable), and it is located at the journal folder. - For large messages, HornetQ persists them outside the message journal. This is discussed + For large messages, ActiveMQ persists them outside the message journal. This is discussed in . - HornetQ can also be configured to page messages to disk in low memory situations. This is + ActiveMQ can also be configured to page messages to disk in low memory situations. This is discussed in . - If no persistence is required at all, HornetQ can also be configured not to persist any + If no persistence is required at all, ActiveMQ can also be configured not to persist any data at all to storage as discussed in .
Configuring the bindings journal The bindings journal is configured using the following attributes in hornetq-configuration.xml + >activemq-configuration.xml bindings-directory @@ -151,7 +151,7 @@
Configuring the message journal The message journal is configured using the following attributes in hornetq-configuration.xml + >activemq-configuration.xml journal-directory @@ -179,18 +179,18 @@ Choosing NIO chooses the Java NIO journal. Choosing AIO chooses the Linux asynchronous IO journal. If you choose AIO but are not running Linux or you do not have - libaio installed then HornetQ will detect this and automatically fall back to + libaio installed then ActiveMQ will detect this and automatically fall back to using NIO. journal-sync-transactional - If this is set to true then HornetQ will make sure all transaction data is + If this is set to true then ActiveMQ will make sure all transaction data is flushed to disk on transaction boundaries (commit, prepare and rollback). The default value is true. journal-sync-non-transactional - If this is set to true then HornetQ will make sure non transactional message + If this is set to true then ActiveMQ will make sure non transactional message data (sends and acknowledgements) are flushed to disk each time. The default value for this is true. @@ -201,8 +201,8 @@ journal-min-files - The minimum number of files the journal will maintain. When HornetQ starts and - there is no initial message data, HornetQ will pre-create The minimum number of files the journal will maintain. When ActiveMQ starts and + there is no initial message data, ActiveMQ will pre-create journal-min-files number of files. Creating journal files and filling them with padding is a fairly expensive operation and we want to minimise doing this at run-time as files get filled. By @@ -295,7 +295,7 @@
Installing AIO - The Java NIO journal gives great performance, but If you are running HornetQ using + The Java NIO journal gives great performance, but If you are running ActiveMQ using Linux Kernel 2.6 or later, we highly recommend you use the AIO journal for the very best persistence performance. It's not possible to use the AIO journal under other operating systems or earlier @@ -309,11 +309,11 @@ apt-get install libaio
- Configuring HornetQ for Zero Persistence + Configuring ActiveMQ for Zero Persistence In some situations, zero persistence is sometimes required for a messaging system. - Configuring HornetQ to perform zero persistence is straightforward. Simply set the + Configuring ActiveMQ to perform zero persistence is straightforward. Simply set the parameter persistence-enabled in hornetq-configuration.xml to false. + >activemq-configuration.xml to false. Please note that if you set this parameter to false, then zero persistence will occur. That means no bindings data, message data, large message data, duplicate id caches or paging data will be persisted. @@ -321,21 +321,21 @@
Import/Export the Journal Data You may want to inspect the existent records on each one of the journals used by - HornetQ, and you can use the export/import tool for that purpose. The export/import are - classes located at the hornetq-core.jar, you can export the journal as a text file by + ActiveMQ, and you can use the export/import tool for that purpose. The export/import are + classes located at the activemq-core.jar, you can export the journal as a text file by using this command: - java -cp hornetq-core.jar org.apache.activemq.core.journal.impl.ExportJournal + java -cp activemq-core.jar org.apache.activemq.core.journal.impl.ExportJournal <JournalDirectory> <JournalPrefix> <FileExtension> <FileSize> <FileOutput> To import the file as binary data on the journal (Notice you also require netty.jar): - java -cp hornetq-core.jar:netty.jar org.apache.activemq.core.journal.impl.ImportJournal + java -cp activemq-core.jar:netty.jar org.apache.activemq.core.journal.impl.ImportJournal <JournalDirectory> <JournalPrefix> <FileExtension> <FileSize> <FileInput> JournalDirectory: Use the configured folder for your selected folder. Example: - ./hornetq/data/journal + ./activemq/data/journal JournalPrefix: Use the prefix for your selected journal, as discussed diff --git a/docs/user-manual/en/pre-acknowledge.xml b/docs/user-manual/en/pre-acknowledge.xml index 81abbe9c7d..5208e91365 100644 --- a/docs/user-manual/en/pre-acknowledge.xml +++ b/docs/user-manual/en/pre-acknowledge.xml @@ -18,7 +18,7 @@ + %BOOK_ENTITIES; ]> @@ -35,11 +35,11 @@ DUPS_OK_ACKNOWLEDGE - HornetQ supports two additional modes: PRE_ACKNOWLEDGE and INDIVIDUAL_ACKNOWLEDGE + ActiveMQ supports two additional modes: PRE_ACKNOWLEDGE and INDIVIDUAL_ACKNOWLEDGE In some cases you can afford to lose messages in event of failure, so it would make sense to acknowledge the message on the server before delivering it to the client. - This extra mode is supported by HornetQ and will call it + This extra mode is supported by ActiveMQ and will call it pre-acknowledge mode. The disadvantage of acknowledging on the server before delivery is that the message will be lost if the system crashes after acknowledging the message on the server @@ -58,7 +58,7 @@
Using PRE_ACKNOWLEDGE - This can be configured in the hornetq-jms.xml file on the This can be configured in the activemq-jms.xml file on the connection factory like this: <connection-factory name="ConnectionFactory"> @@ -71,12 +71,12 @@ <pre-acknowledge>true</pre-acknowledge> </connection-factory> Alternatively, to use pre-acknowledgement mode using the JMS API, create a JMS Session - with the HornetQSession.PRE_ACKNOWLEDGE constant. + with the ActiveMQSession.PRE_ACKNOWLEDGE constant. // messages will be acknowledge on the server *before* being delivered to the client -Session session = connection.createSession(false, HornetQJMSConstants.PRE_ACKNOWLEDGE); +Session session = connection.createSession(false, ActiveMQJMSConstants.PRE_ACKNOWLEDGE); Or you can set pre-acknowledge directly on the HornetQConnectionFactory instance using the setter method. + >ActiveMQConnectionFactory instance using the setter method. To use pre-acknowledgement mode using the core API you can set it directly on the ClientSessionFactory instance using the setter method.
@@ -84,7 +84,7 @@ Session session = connection.createSession(false, HornetQJMSConstants.PRE_ACKNOW Individual Acknowledge A valid use-case for individual acknowledgement would be when you need to have your own scheduling and you don't know when your message processing will be finished. You should prefer having one consumer per thread worker but this is not possible in some circumstances depending on how complex is your processing. For that you can use the individual Acknowledgement. - You basically setup Individual ACK by creating a session with the acknowledge mode with HornetQJMSConstants.INDIVIDUAL_ACKNOWLEDGE. Individual ACK inherits all the semantics from Client Acknowledge, + You basically setup Individual ACK by creating a session with the acknowledge mode with ActiveMQJMSConstants.INDIVIDUAL_ACKNOWLEDGE. Individual ACK inherits all the semantics from Client Acknowledge, with the exception the message is individually acked. Please note, that to avoid confusion on MDB processing, Individual ACKNOWLEDGE is not supported through MDBs (or the inbound resource adapter). this is because you have to finish the process of your message inside the MDB. diff --git a/docs/user-manual/en/preface.xml b/docs/user-manual/en/preface.xml index 2c1483b3de..2e914673cd 100644 --- a/docs/user-manual/en/preface.xml +++ b/docs/user-manual/en/preface.xml @@ -18,36 +18,36 @@ + %BOOK_ENTITIES; ]> Preface - What is HornetQ? + What is ActiveMQ? - HornetQ is an open source project to build a multi-protocol, embeddable, very high + ActiveMQ is an open source project to build a multi-protocol, embeddable, very high performance, clustered, asynchronous messaging system. - HornetQ is an example of Message Oriented Middleware (MoM). For a description of + ActiveMQ is an example of Message Oriented Middleware (MoM). For a description of MoMs and other messaging concepts please see the . - For answers to more questions about what HornetQ is and what it isn't please visit - the FAQs wiki + For answers to more questions about what ActiveMQ is and what it isn't please visit + the FAQs wiki page. - Why use HornetQ? Here are just a few of the reasons: + Why use ActiveMQ? Here are just a few of the reasons: - 100% open source software. HornetQ is licensed using the Apache Software License v + 100% open source software. ActiveMQ is licensed using the Apache Software License v 2.0 to minimise barriers to adoption. - HornetQ is designed with usability in mind. + ActiveMQ is designed with usability in mind. Written in Java. Runs on any platform with a Java 6+ runtime, that's everything @@ -63,7 +63,7 @@ and others you won't find anywhere else. - Elegant, clean-cut design with minimal third party dependencies. Run HornetQ + Elegant, clean-cut design with minimal third party dependencies. Run ActiveMQ stand-alone, run it in integrated in your favourite JEE application server, or run it embedded inside your own product. It's up to you. @@ -80,7 +80,7 @@ For a full list of features, please see the features wiki + url="http://www.jboss.org/community/wiki/ActiveMQFeatures">features wiki page . diff --git a/docs/user-manual/en/project-info.xml b/docs/user-manual/en/project-info.xml index 7e3ca973ca..a642c0498e 100644 --- a/docs/user-manual/en/project-info.xml +++ b/docs/user-manual/en/project-info.xml @@ -18,17 +18,17 @@ + %BOOK_ENTITIES; ]> Project Information - The official HornetQ project page is http://hornetq.org/. + The official ActiveMQ project page is http://activemq.org/.
Software Download The software can be download from the Download page:http://hornetq.org/downloads.html + url="http://activemq.org/downloads.html">http://activemq.org/downloads.html
Project Information @@ -36,41 +36,41 @@ Please take a look at our project wiki + url="http://www.jboss.org/community/wiki/ActiveMQ">wiki If you have any user questions please use our user + url="https://community.jboss.org/en/activemq">user forum If you have development related questions, please use our developer forum - Pop in and chat to us in our Pop in and chat to us in our IRC channel - Our project blog + Our project blog - Follow us on twitter + Follow us on twitter - HornetQ Git repository is https://github.com/hornetq/hornetq + ActiveMQ Git repository is https://github.com/activemq/activemq All release tags are available from https://github.com/hornetq/hornetq/tags + url="https://github.com/activemq/activemq/tags" + >https://github.com/activemq/activemq/tags - Red Hat kindly employs developers to work full time on HornetQ, they are: + Red Hat kindly employs developers to work full time on ActiveMQ, they are: Clebert Suconic (project lead) @@ -84,7 +84,7 @@ Justin Bertram - And many thanks to all our contributors, both old and new who helped create HornetQ, + And many thanks to all our contributors, both old and new who helped create ActiveMQ, for a full list of the people who made it happen, take a look at our team page.
diff --git a/docs/user-manual/en/queue-attributes.xml b/docs/user-manual/en/queue-attributes.xml index 1c12befc43..93bb227f26 100644 --- a/docs/user-manual/en/queue-attributes.xml +++ b/docs/user-manual/en/queue-attributes.xml @@ -18,7 +18,7 @@ + %BOOK_ENTITIES; ]> @@ -30,7 +30,7 @@ Predefined Queues Queues can be predefined via configuration at a core level or at a JMS level. Firstly let's look at a JMS level. - The following shows a queue predefined in the hornetq-jms.xml + The following shows a queue predefined in the activemq-jms.xml configuration file. <queue name="selectorQueue"> @@ -50,7 +50,7 @@ The durable element specifies whether the queue will be persisted. This again is optional and defaults to true if omitted. Secondly a queue can be predefined at a core level in the hornetq-configuration.xml file. The following is an example. + >activemq-configuration.xml file. The following is an example. <queues> <queue name="jms.queue.selectorQueue"> @@ -95,7 +95,7 @@ Configuring Queues Via Address Settings There are some attributes that are defined against an address wildcard rather than a specific queue. Here an example of an address-setting entry that - would be found in the hornetq-configuration.xml file. + would be found in the activemq-configuration.xml file. <address-settings> <address-setting match="jms.queue.exampleQueue"> diff --git a/docs/user-manual/en/rest.xml b/docs/user-manual/en/rest.xml index 712cfcdd7c..947d7165dc 100644 --- a/docs/user-manual/en/rest.xml +++ b/docs/user-manual/en/rest.xml @@ -19,8 +19,8 @@ REST Interface - The HornetQ REST interface allows you to leverage the reliability - and scalability features of HornetQ over a simple REST/HTTP interface. + The ActiveMQ REST interface allows you to leverage the reliability + and scalability features of ActiveMQ over a simple REST/HTTP interface. Messages are produced and consumed by sending and receiving simple HTTP messages that contain the content you want to push around. For instance, here's a simple example of posting an order to an order processing queue @@ -40,7 +40,7 @@ Content-Type: application/xml As you can see, we're just posting some arbitrary XML document to a URL. When the XML is received on the server is it processed - within HornetQ as a JMS message and distributed through core HornetQ. + within ActiveMQ as a JMS message and distributed through core ActiveMQ. Simple and easy. Consuming messages from a queue or topic looks very similar. We'll discuss the entire interface in detail later in this docbook. @@ -49,7 +49,7 @@ Content-Type: application/xml
Goals of REST Interface - Why would you want to use HornetQ's REST interface? What are the + Why would you want to use ActiveMQ's REST interface? What are the goals of the REST interface? @@ -59,10 +59,10 @@ Content-Type: application/xml - Zero client footprint. We want HornetQ to be usable by any + Zero client footprint. We want ActiveMQ to be usable by any client/programming language that has an adequate HTTP client library. You shouldn't have to download, install, and configure a - special library to interact with HornetQ. + special library to interact with ActiveMQ. @@ -72,7 +72,7 @@ Content-Type: application/xml RESTful the HTTP uniform interface provides all the interoperability you need to communicate between different languages, platforms, and even messaging implementations that choose to implement the same - RESTful interface as HornetQ (i.e. the + RESTful interface as ActiveMQ (i.e. the REST-* effort.) @@ -81,13 +81,13 @@ Content-Type: application/xml No envelope (e.g. SOAP) or feed (e.g. Atom) format requirements. You shouldn't have to learn, use, or parse a specific XML document format in order to send and receive messages through - HornetQ's REST interface. + ActiveMQ's REST interface. Leverage the reliability, scalability, and clustering features - of HornetQ on the back end without sacrificing the simplicity of a + of ActiveMQ on the back end without sacrificing the simplicity of a REST interface. @@ -98,22 +98,22 @@ Content-Type: application/xml
Installation and Configuration - HornetQ's REST interface is installed as a Web archive (WAR). It + ActiveMQ's REST interface is installed as a Web archive (WAR). It depends on the RESTEasy project and can currently only run within a servlet container. Installing - the HornetQ REST interface is a little bit different depending whether - HornetQ is already installed and configured for your environment (e.g. - you're deploying within JBoss AS 7) or you want the HornetQ REST - WAR to startup and manage the HornetQ server (e.g. you're deploying + the ActiveMQ REST interface is a little bit different depending whether + ActiveMQ is already installed and configured for your environment (e.g. + you're deploying within JBoss AS 7) or you want the ActiveMQ REST + WAR to startup and manage the ActiveMQ server (e.g. you're deploying within something like Apache Tomcat).
Installing Within Pre-configured Environment - This section should be used when you want to use the HornetQ REST - interface in an environment that already has HornetQ installed and + This section should be used when you want to use the ActiveMQ REST + interface in an environment that already has ActiveMQ installed and running, e.g. JBoss AS 7. You must create a Web archive (.WAR) file with the following web.xml settings: @@ -146,7 +146,7 @@ Content-Type: application/xml </web-app> Within your WEB-INF/lib directory you must have the - hornetq-rest.jar file. If RESTEasy is not installed within your + activemq-rest.jar file. If RESTEasy is not installed within your environment, you must add the RESTEasy jar files within the lib directory as well. Here's a sample Maven pom.xml that can build your WAR for this case. @@ -186,7 +186,7 @@ Content-Type: application/xml <dependencies> <dependency> <groupId>org.apache.activemq.rest</groupId> - <artifactId>hornetq-rest</artifactId> + <artifactId>activemq-rest</artifactId> <version>2.3.0-SNAPSHOT</version> </dependency> </dependencies> @@ -218,8 +218,8 @@ Content-Type: application/xml It is worth noting that when deploying a WAR in a Java EE application server like AS7 the URL for the resulting application will include the name of the WAR by default. For example, if you've constructed a WAR as described above - named "hornetq-rest.war" then clients will access it at, e.g. - http://localhost:8080/hornetq-rest/[queues|topics]. We'll see more about + named "activemq-rest.war" then clients will access it at, e.g. + http://localhost:8080/activemq-rest/[queues|topics]. We'll see more about this later. @@ -231,13 +231,13 @@ Content-Type: application/xml
- Bootstrapping HornetQ Along with REST + Bootstrapping ActiveMQ Along with REST - You can bootstrap HornetQ within your WAR as well. To do this, you - must have the HornetQ core and JMS jars along with Netty, Resteasy, and - the HornetQ REST jar within your WEB-INF/lib. You must also have a - hornetq-configuration.xml, hornetq-jms.xml, and hornetq-users.xml config - files within WEB-INF/classes. The examples that come with the HornetQ + You can bootstrap ActiveMQ within your WAR as well. To do this, you + must have the ActiveMQ core and JMS jars along with Netty, Resteasy, and + the ActiveMQ REST jar within your WEB-INF/lib. You must also have a + activemq-configuration.xml, activemq-jms.xml, and activemq-users.xml config + files within WEB-INF/classes. The examples that come with the ActiveMQ REST distribution show how to do this. You must also add an additional listener to your web.xml file. Here's an example: @@ -252,7 +252,7 @@ Content-Type: application/xml <listener> <listener-class> - org.apache.activemq.rest.integration.HornetqBootstrapListener + org.apache.activemq.rest.integration.ActiveMQBootstrapListener </listener-class> </listener> @@ -276,7 +276,7 @@ Content-Type: application/xml </web-app> Here's a Maven pom.xml file for creating a WAR for this - environment. Make sure your hornetq configuration files are within the + environment. Make sure your activemq configuration files are within the src/main/resources directory so that they are stuffed within the WAR's WEB-INF/classes directory! @@ -313,7 +313,7 @@ Content-Type: application/xml <dependencies> <dependency> <groupId>org.apache.activemq</groupId> - <artifactId>hornetq-core</artifactId> + <artifactId>activemq-core</artifactId> <version>2.3.0-SNAPSHOT</version> </dependency> <dependency> @@ -323,7 +323,7 @@ Content-Type: application/xml </dependency> <dependency> <groupId>org.apache.activemq</groupId> - <artifactId>hornetq-jms</artifactId> + <artifactId>activemq-jms</artifactId> <version>2.3.0-SNAPSHOT</version> </dependency> <dependency> @@ -333,7 +333,7 @@ Content-Type: application/xml </dependency> <dependency> <groupId>org.apache.activemq.rest</groupId> - <artifactId>hornetq-rest</artifactId> + <artifactId>activemq-rest</artifactId> <version>2.3.0-SNAPSHOT</version> </dependency> <dependency> @@ -353,7 +353,7 @@ Content-Type: application/xml
REST Configuration - The HornetQ REST implementation does have some configuration + The ActiveMQ REST implementation does have some configuration options. These are configured via XML configuration file that must be in your WEB-INF/classes directory. You must set the web.xml context-param rest.messaging.config.file to specify the name of the @@ -380,15 +380,15 @@ Content-Type: application/xml - server-in-vm-id. The HornetQ REST - impl uses the IN-VM transport to communicate with HornetQ. + server-in-vm-id. The ActiveMQ REST + impl uses the IN-VM transport to communicate with ActiveMQ. It uses the default server id, which is "0". use-link-headers. By default, all links (URLs) are published using custom headers. You can - instead have the HornetQ REST implementation publish links + instead have the ActiveMQ REST implementation publish links using the Link Header specification instead if you desire. @@ -421,7 +421,7 @@ Content-Type: application/xml producer-session-pool-size. The REST - implementation pools HornetQ sessions for sending messages. + implementation pools ActiveMQ sessions for sending messages. This is the size of the pool. That number of sessions will be created at startup time. @@ -446,9 +446,9 @@ Content-Type: application/xml consumer-window-size. For consumers, - this config option is the same as the HornetQ one of the + this config option is the same as the ActiveMQ one of the same name. It will be used by sessions created by the - HornetQ REST implementation. + ActiveMQ REST implementation. @@ -457,9 +457,9 @@ Content-Type: application/xml
- HornetQ REST Interface Basics + ActiveMQ REST Interface Basics - The HornetQ REST interface publishes a variety of REST resources to + The ActiveMQ REST interface publishes a variety of REST resources to perform various tasks on a queue or topic. Only the top-level queue and topic URI schemes are published to the outside world. You must discover all over resources to interact with by looking for and traversing links. @@ -479,16 +479,16 @@ Content-Type: application/xml /topics/{name} The base of the URI is the base URL of the WAR you deployed the - HornetQ REST server within as defined in the + ActiveMQ REST server within as defined in the Installation and Configuration section of this document. Replace the {name} string within the above URI pattern with the name of the queue or topic you are interested in interacting with. For example if you have configured a JMS topic named "foo" within your - hornetq-jms.xml file, the URI name should be + activemq-jms.xml file, the URI name should be "jms.topic.foo". If you have configured a JMS queue name "bar" within - your hornetq-jms.xml file, the URI name should be - "jms.queue.bar". Internally, HornetQ prepends the "jms.topic" or + your activemq-jms.xml file, the URI name should be + "jms.queue.bar". Internally, ActiveMQ prepends the "jms.topic" or "jms.queue" strings to the name of the deployed destination. Next, perform your HEAD or GET request on this URI. Here's what a request/response would look like. @@ -522,7 +522,7 @@ curl --head http://example.com/queues/jms.queue.bar are an implementation detail. Treat them as opaque and query for them each and every time you initially interact (at boot time) with the server. If you treat all URLs as opaque then you will be isolated from - implementation changes as the HornetQ REST interface evolves over + implementation changes as the ActiveMQ REST interface evolves over time.
@@ -557,7 +557,7 @@ curl --head http://example.com/queues/jms.queue.bar msg-push-consumers. This is a URL for - registering other URLs you want the HornetQ REST server to + registering other URLs you want the ActiveMQ REST server to push messages to. The semantics of this link are described in Pushing Messages. @@ -595,7 +595,7 @@ curl --head http://example.com/queues/jms.queue.bar msg-push-subscriptions. This is a - URL for registering other URLs you want the HornetQ REST + URL for registering other URLs you want the ActiveMQ REST server to push messages to. The semantics of this link are described in Pushing Messages. @@ -610,13 +610,13 @@ curl --head http://example.com/queues/jms.queue.bar Posting Messages This chapter discusses the protocol for posting messages to a queue - or a topic. In HornetQ REST Interface Basics, + or a topic. In ActiveMQ REST Interface Basics, you saw that a queue or topic resource publishes variable custom headers that are links to other RESTful resources. The msg-create header is a URL you can post a message to. Messages are published to a queue or topic by sending a simple HTTP message to the URL published by the msg-create header. The HTTP message contains whatever - content you want to publish to the HornetQ destination. Here's an example + content you want to publish to the ActiveMQ destination. Here's an example scenario: @@ -724,11 +724,11 @@ msg-create-next: http://example.com/queues/jms.queue.bar/create messages to a queue or topic. You may do a POST and never receive a response. Unfortunately, you don't know whether or not the server received the message and so a re-post of the message might cause - duplicates to be posted to the queue or topic. By default, the HornetQ + duplicates to be posted to the queue or topic. By default, the ActiveMQ REST interface is configured to accept and post duplicate messages. You can change this by turning on duplicate message detection by setting the dups-ok config option to false - as described in HornetQ REST Interface Basics. + as described in ActiveMQ REST Interface Basics. When you do this, the initial POST to the msg-create URL will redirect you, using the standard HTTP 307 redirection mechanism to a unique URL to POST to. All other interactions remain the same as @@ -832,10 +832,10 @@ msg-create-next: http://example.com/queues/jms.queue.bar/create/13582001787374 How can this work? As you can see, with each successful response, - the HornetQ REST server returns a uniquely generated URL within the + the ActiveMQ REST server returns a uniquely generated URL within the msg-create-next header. This URL is dedicated to the next new message you want to post. Behind the scenes, the code extracts an identify from - the URL and uses HornetQ's duplicate detection mechanism by setting the + the URL and uses ActiveMQ's duplicate detection mechanism by setting the DUPLICATE_DETECTION_ID property of the JMS message that is actually posted to the system. @@ -844,7 +844,7 @@ msg-create-next: http://example.com/queues/jms.queue.bar/create/13582001787374 -WARN [org.apache.activemq.core.server] (Thread-3 (HornetQ-remoting-threads-HornetQServerImpl::serverUUID=8d6be6f8-5e8b-11e2-80db-51bbde66f473-26319292-267207)) HQ112098: Duplicate message detected - message will not be routed. Message information: +WARN [org.apache.activemq.core.server] (Thread-3 (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=8d6be6f8-5e8b-11e2-80db-51bbde66f473-26319292-267207)) HQ112098: Duplicate message detected - message will not be routed. Message information: ServerMessage[messageID=20,priority=4, bodySize=1500,expiration=0, durable=true, address=jms.queue.bar,properties=TypedProperties[{http_content$type=application/x-www-form-urlencoded, http_content$length=3, postedAsHttpMessage=true, _HQ_DUPL_ID=42}]]@12835058 An alternative to this approach is to use the msg-create-with-id @@ -877,7 +877,7 @@ msg-create-with-id: http://example.com/queues/jms.queue.bar/create/{id}Persistent Messages By default, posted messages are not durable and will not be - persisted in HornetQ's journal. You can create durable messages by + persisted in ActiveMQ's journal. You can create durable messages by modifying the default configuration as expressed in Chapter 2 so that all messages are persisted when sent. Alternatively, you can set a URL query parameter called durable to true when you post @@ -935,7 +935,7 @@ Content-Type: application/xml important caveats. To start consuming you must create a consumer resource on the server that is dedicated to your client. Now, this pretty much breaks the stateless principle of REST, but after much prototyping, this - is the best way to work most effectively with HornetQ through a REST + is the best way to work most effectively with ActiveMQ through a REST interface. @@ -944,7 +944,7 @@ Content-Type: application/xml response header if you are interacting with a queue, the msg-pull-subscribers response header if you're interacting with a topic. These headers are provided by the main queue or - topic resource discussed in HornetQ REST Interface + topic resource discussed in ActiveMQ REST Interface Basics. Doing an empty POST to one of these URLs will create a consumer resource that follows an auto-acknowledge protocol and, if you are interacting with a topic, creates a temporarily @@ -979,7 +979,7 @@ Content-Type: application/xml selector. This is an optional JMS selector - string. The HornetQ REST interface adds HTTP headers to the + string. The ActiveMQ REST interface adds HTTP headers to the JMS message for REST produced messages. HTTP headers are prefixed with "http_" and every '-' character is converted to a '$'. @@ -1223,7 +1223,7 @@ msg-consume-next: http://example.com/queues/jms.queue.bar/pull-consumers/333/con should retry a post. Also notice, that another new msg-consume-next URL is present. Although it probably is the same URL you used last post, get in the habit of using URLs returned in - response headers as future versions of HornetQ REST might be + response headers as future versions of ActiveMQ REST might be redirecting you or adding additional data to the URL after timeouts like this. @@ -1594,7 +1594,7 @@ http://example.com/queues/jms.queue.bar/pull-consumers/333/acknowledge-next-2

Unless your queue or topic has a high rate of message flowing though it, if you use the pull protocol, you're going to be receiving a lot of 503 responses as you continuously pull the server for new - messages. To alleviate this problem, the HornetQ REST interface provides + messages. To alleviate this problem, the ActiveMQ REST interface provides the Accept-Wait header. This is a generic HTTP request header that is a hint to the server for how long the client is willing to wait for a response from the server. The value of this header @@ -1643,9 +1643,9 @@ msg-consume-next: http://example.com/queues/jms.queue.bar/pull-consumers/333/con
Pushing Messages - You can configure the HornetQ REST server to push messages to a + You can configure the ActiveMQ REST server to push messages to a registered URL either remotely through the REST interface, or by creating - a pre-configured XML file for the HornetQ REST server to load at boot + a pre-configured XML file for the ActiveMQ REST server to load at boot time. @@ -1702,7 +1702,7 @@ msg-consume-next: http://example.com/queues/jms.queue.bar/pull-consumers/333/con will disable the registration if all retries have failed. It will not disable the connection on non-connection-failure issues (like a bad request for instance). In these cases, the dead letter queue logic of - HornetQ will take over. + ActiveMQ will take over. The link element specifies the basis of the @@ -1720,10 +1720,10 @@ msg-consume-next: http://example.com/queues/jms.queue.bar/pull-consumers/333/con destination. The href URL is assumed to be a queue or topic resource of - another HornetQ REST server. The push registration will initially + another ActiveMQ REST server. The push registration will initially do a HEAD request to this URL to obtain a msg-create-with-id header. It will use this header to push new messages to the - HornetQ REST endpoint reliably. Here's an example: + ActiveMQ REST endpoint reliably. Here's an example: @@ -1962,13 +1962,13 @@ Location: http://example.com/topics/jms.topic.bar/push-subscriptions/1-333-1212< Currently you cannot create a temporary queue or topic. To create a queue you do a POST to the relative URL /queues with an XML representation of the queue. The XML syntax is the same queue syntax that you would specify - in hornetq-jms.xml if you were creating a queue there. For example: + in activemq-jms.xml if you were creating a queue there. For example: POST /queues Host: example.com -Content-Type: application/hornetq.jms.queue+xml +Content-Type: application/activemq.jms.queue+xml <queue name="testQueue"> <durable>true</durable> @@ -1978,14 +1978,14 @@ Content-Type: application/hornetq.jms.queue+xml HTTP/1.1 201 Created Location: http://example.com/queues/jms.queue.testQueue - Notice that the Content-Type is application/hornetq.jms.queue+xml. + Notice that the Content-Type is application/activemq.jms.queue+xml. Here's what creating a topic would look like: POST /topics Host: example.com -Content-Type: application/hornetq.jms.topic+xml +Content-Type: application/activemq.jms.topic+xml <topic name="testTopic"> </topic> @@ -1997,23 +1997,23 @@ Location: http://example.com/topics/jms.topic.testTopic
- Securing the HornetQ REST Interface + Securing the ActiveMQ REST Interface
Within JBoss Application server - Securing the HornetQ REST interface is very simple with the JBoss + Securing the ActiveMQ REST interface is very simple with the JBoss Application Server. You turn on authentication for all URLs within your - WAR's web.xml, and let the user Principal to propagate to HornetQ. This - only works if you are using the JBossSecurityManager with HornetQ. See - the HornetQ documentation for more details. + WAR's web.xml, and let the user Principal to propagate to ActiveMQ. This + only works if you are using the JBossSecurityManager with ActiveMQ. See + the ActiveMQ documentation for more details.
Security in other environments - To secure the HornetQ REST interface in other environments you + To secure the ActiveMQ REST interface in other environments you must role your own security by specifying security constraints with your web.xml for every path of every queue and topic you have deployed. Here is a list of URI patterns: @@ -2091,7 +2091,7 @@ Location: http://example.com/topics/jms.topic.testTopic
Mixing JMS and REST - The HornetQ REST interface supports mixing JMS and REST producers + The ActiveMQ REST interface supports mixing JMS and REST producers and consumers. You can send an ObjectMessage through a JMS Producer, and have a REST client consume it. You can have a REST client POST a message to a topic and have a JMS Consumer receive it. Some simple transformations @@ -2101,11 +2101,11 @@ Location: http://example.com/topics/jms.topic.testTopic
JMS Producers - REST Consumers - If you have a JMS producer, the HornetQ REST interface only + If you have a JMS producer, the ActiveMQ REST interface only supports ObjectMessage type. If the JMS producer is aware that there may be REST consumers, it should set a JMS property to specify what Content-Type the Java object should be translated into by REST clients. - The HornetQ REST server will use RESTEasy content handlers + The ActiveMQ REST server will use RESTEasy content handlers (MessageBodyReader/Writers) to transform the Java object to the type desired. Here's an example of a JMS producer setting the content type of the message. @@ -2129,7 +2129,7 @@ message.setStringProperty(org.apache.activemq.rest.HttpHeaderProperty.CONTENT_TY REST Producers - JMS Consumers If you have a REST client producing messages and a JMS consumer, - HornetQ REST has a simple helper class for you to transform the HTTP + ActiveMQ REST has a simple helper class for you to transform the HTTP body to a Java object. Here's some example code: diff --git a/docs/user-manual/en/scheduled-messages.xml b/docs/user-manual/en/scheduled-messages.xml index 509904e9e4..06407bfdd2 100644 --- a/docs/user-manual/en/scheduled-messages.xml +++ b/docs/user-manual/en/scheduled-messages.xml @@ -18,7 +18,7 @@ + %BOOK_ENTITIES; ]> diff --git a/docs/user-manual/en/security.xml b/docs/user-manual/en/security.xml index e9cd18723a..0a2b8c9118 100644 --- a/docs/user-manual/en/security.xml +++ b/docs/user-manual/en/security.xml @@ -18,26 +18,26 @@ + %BOOK_ENTITIES; ]> Security - This chapter describes how security works with HornetQ and how you can configure it. To + This chapter describes how security works with ActiveMQ and how you can configure it. To disable security completely simply set the security-enabled property to - false in the hornetq-configuration.xml file. + false in the activemq-configuration.xml file. For performance reasons security is cached and invalidated every so long. To change this period set the property security-invalidation-interval, which is in milliseconds. The default is 10000 ms.
Role based security for addresses - HornetQ contains a flexible role-based security model for applying security to queues, + ActiveMQ contains a flexible role-based security model for applying security to queues, based on their addresses. - As explained in , HornetQ core consists mainly of sets of + As explained in , ActiveMQ core consists mainly of sets of queues bound to addresses. A message is sent to an address and the server looks up the set of queues that are bound to that address, the server then routes the message to those set of queues. - HornetQ allows sets of permissions to be defined against the queues based on their + ActiveMQ allows sets of permissions to be defined against the queues based on their address. An exact match on the address can be used or a wildcard match can be used using the wildcard characters '#' and '*'. Seven different permissions can be given to the set of queues which match the address. @@ -77,7 +77,7 @@ the user has any of those roles, he/she will be granted that permission for that set of addresses. Let's take a simple example, here's a security block from hornetq-configuration.xml or hornetq-queues.xml + >activemq-configuration.xml or activemq-queues.xml file: <security-setting match="globalqueues.europe.#"> @@ -101,7 +101,7 @@ can send messages to these addresses or consume messages from queues bound to an address that starts with the string "globalqueues.europe." The mapping between a user and what roles they have is handled by the security - manager. HornetQ ships with a user manager that reads user credentials from a file on + manager. ActiveMQ ships with a user manager that reads user credentials from a file on disk, and can also plug into JAAS or JBoss Application Server security. For more information on configuring the security manager, please see . @@ -135,23 +135,23 @@
Secure Sockets Layer (SSL) Transport When messaging clients are connected to servers, or servers are connected to other - servers (e.g. via bridges) over an untrusted network then HornetQ allows that traffic to + servers (e.g. via bridges) over an untrusted network then ActiveMQ allows that traffic to be encrypted using the Secure Sockets Layer (SSL) transport. For more information on configuring the SSL transport, please see .
Basic user credentials - HornetQ ships with a security manager implementation that reads user credentials, i.e. + ActiveMQ ships with a security manager implementation that reads user credentials, i.e. user names, passwords and role information from an xml file on the classpath called - hornetq-users.xml. This is the default security manager. + activemq-users.xml. This is the default security manager. If you wish to use this security manager, then users, passwords and roles can easily be added into this file. Let's take a look at an example file: <configuration xmlns="urn:activemq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="urn:hornetq ../schemas/activemq-users.xsd "> + xsi:schemaLocation="urn:activemq ../schemas/activemq-users.xsd "> <defaultuser name="guest" password="guest"> <role name="guest"/> @@ -185,23 +185,23 @@
Changing the security manager If you do not want to use the default security manager then you can specify a - different one by editing the file hornetq-beans.xml (or hornetq-jboss-beans.xml if you're running JBoss Application Server) and - changing the class for the HornetQSecurityManager bean. + different one by editing the file activemq-beans.xml (or activemq-jboss-beans.xml if you're running JBoss Application Server) and + changing the class for the ActiveMQSecurityManager bean. Let's take a look at a snippet from the default beans file: -<bean name="HornetQSecurityManager" class="org.apache.activemq.spi.core.security.HornetQSecurityManagerImpl"> +<bean name="ActiveMQSecurityManager" class="org.apache.activemq.spi.core.security.ActiveMQSecurityManagerImpl"> <start ignored="true"/> <stop ignored="true"/> </bean> - The class org.apache.activemq.spi.core.security.HornetQSecurityManagerImpl + The class org.apache.activemq.spi.core.security.ActiveMQSecurityManagerImpl is the default security manager that is used by the standalone server. - HornetQ ships with two other security manager implementations you can use + ActiveMQ ships with two other security manager implementations you can use off-the-shelf; one a JAAS security manager and another for integrating with JBoss Application Sever security, alternatively you could write your own implementation by - implementing the org.apache.activemq.spi.core.security.HornetQSecurityManager + implementing the org.apache.activemq.spi.core.security.ActiveMQSecurityManager interface, and specifying the classname of your implementation in the file hornetq-beans.xml (or hornetq-jboss-beans.xml if + >activemq-beans.xml (or activemq-jboss-beans.xml if you're running JBoss Application Server). These two implementations are discussed in the next two sections.
@@ -214,7 +214,7 @@ you need to specify the security manager as a JAASSecurityManager in the beans file. Here's an example: -<bean name="HornetQSecurityManager" class="org.apache.activemq.integration.jboss.security.JAASSecurityManager"> +<bean name="ActiveMQSecurityManager" class="org.apache.activemq.integration.jboss.security.JAASSecurityManager"> <start ignored="true"/> <stop ignored="true"/> @@ -243,27 +243,27 @@
Example - See for an example which shows how HornetQ can be + See for an example which shows how ActiveMQ can be configured to use JAAS.
JBoss AS Security Manager - The JBoss AS security manager is used when running HornetQ inside the JBoss + The JBoss AS security manager is used when running ActiveMQ inside the JBoss Application server. This allows tight integration with the JBoss Application Server's security model. The class name of this security manager is org.apache.activemq.integration.jboss.security.JBossASSecurityManager - Take a look at one of the default hornetq-jboss-beans.xml files for + Take a look at one of the default activemq-jboss-beans.xml files for JBoss Application Server that are bundled in the distribution for an example of how this is configured.
Configuring Client Login JBoss can be configured to allow client login, basically this is when a JEE component such as a Servlet or EJB sets security credentials on the current security context and these are used throughout the call. - If you would like these credentials to be used by HornetQ when sending or consuming messages then - set allowClientLogin to true. This will bypass HornetQ authentication and propagate the - provided Security Context. If you would like HornetQ to authenticate using the propagated security then set the + If you would like these credentials to be used by ActiveMQ when sending or consuming messages then + set allowClientLogin to true. This will bypass ActiveMQ authentication and propagate the + provided Security Context. If you would like ActiveMQ to authenticate using the propagated security then set the authoriseOnClientLogin to true also. There is more info on using the JBoss client login module here @@ -273,7 +273,7 @@
Changing the Security Domain - The name of the security domain used by the JBoss AS security manager defaults to java:/jaas/hornetq + The name of the security domain used by the JBoss AS security manager defaults to java:/jaas/activemq . This can be changed by specifying securityDomainName (e.g. java:/jaas/myDomain).
diff --git a/docs/user-manual/en/send-guarantees.xml b/docs/user-manual/en/send-guarantees.xml index a89d6461bb..aeca337874 100644 --- a/docs/user-manual/en/send-guarantees.xml +++ b/docs/user-manual/en/send-guarantees.xml @@ -18,14 +18,14 @@ + %BOOK_ENTITIES; ]> Guarantees of sends and commits
Guarantees of Transaction Completion - When committing or rolling back a transaction with HornetQ, the request to commit or + When committing or rolling back a transaction with ActiveMQ, the request to commit or rollback is sent to the server, and the call will block on the client side until a response has been received from the server that the commit or rollback was executed. @@ -41,11 +41,11 @@ storage by the time the call to commit or rollback returns. Setting this parameter to false can improve performance at the expense of some loss of transaction durability. - This parameter is set in hornetq-configuration.xml + This parameter is set in activemq-configuration.xml
Guarantees of Non Transactional Message Sends - If you are sending messages to a server using a non transacted session, HornetQ can be + If you are sending messages to a server using a non transacted session, ActiveMQ can be configured to block the call to send until the message has definitely reached the server, and a response has been sent back to the client. This can be configured individually for durable and non-durable messages, and is determined by the @@ -72,14 +72,14 @@ your network, rather than the bandwidth of your network. For better performance we recommend either batching many messages sends together in a transaction since with a transactional session, only the commit / rollback blocks not every send, or, using - HornetQ's advanced asynchronous send acknowledgements feature + ActiveMQ's advanced asynchronous send acknowledgements feature described in . If you are using JMS and you're using the JMS service on the server to load your JMS connection factory instances into JNDI then these parameters can be configured in - hornetq-jms.xml using the elements activemq-jms.xml using the elements block-on-durable-send and block-on-non-durable-send. If you're using JMS but not using JNDI then - you can set these values directly on the HornetQConnectionFactory + you can set these values directly on the ActiveMQConnectionFactory instance using the appropriate setter methods. If you're using core you can set these values directly on the ClientSessionFactory instance using the appropriate setter @@ -95,7 +95,7 @@
Guarantees of Non Transactional Acknowledgements If you are acknowledging the delivery of a message at the client side using a non - transacted session, HornetQ can be configured to block the call to acknowledge until the + transacted session, ActiveMQ can be configured to block the call to acknowledge until the acknowledge has definitely reached the server, and a response has been sent back to the client. This is configured with the parameter BlockOnAcknowledge. If this is set to true then all calls to acknowledge on non transacted @@ -108,7 +108,7 @@ Asynchronous Send Acknowledgements If you are using a non transacted session but want a guarantee that every message sent to the server has reached it, then, as discussed in , you can configure HornetQ to block the call to + linkend="non-transactional-sends"/>, you can configure ActiveMQ to block the call to send until the server has received the message, persisted it and sent back a response. This works well but has a severe performance penalty - each call to send needs to block for at least the time of a network round trip (RTT) - the performance of sending is thus @@ -124,8 +124,8 @@ * 1024 * 1024 / 8) / 1500 = 89478 messages per second if messages are sent without blocking! These figures aren't an exact science but you can clearly see that being limited by network RTT can have serious effect on performance. - To remedy this, HornetQ provides an advanced new feature called asynchronous - send acknowledgements. With this feature, HornetQ can be configured to + To remedy this, ActiveMQ provides an advanced new feature called asynchronous + send acknowledgements. With this feature, ActiveMQ can be configured to send messages without blocking in one direction and asynchronously getting acknowledgement from the server that the messages were received in a separate stream. By de-coupling the send from the acknowledgement of the send, the system is not limited by @@ -142,7 +142,7 @@ Then, you just send messages as normal using your ClientSession, and as messages reach the server, the server will send back an acknowledgement of the send asynchronously, and some time later you are - informed at the client side by HornetQ calling your handler's sendAcknowledged(ClientMessage message) method, passing in a reference to the message that was sent. To enable asynchronous send acknowledgements you must make sure confirmation-window-size is set to a positive integer value, e.g. 10MiB diff --git a/docs/user-manual/en/slow-consumers.xml b/docs/user-manual/en/slow-consumers.xml index aef287d1b9..78f4bc1114 100644 --- a/docs/user-manual/en/slow-consumers.xml +++ b/docs/user-manual/en/slow-consumers.xml @@ -18,12 +18,12 @@ + %BOOK_ENTITIES; ]> Detecting Slow Consumers - In this section we will discuss how HornetQ can be configured to deal with slow consumers. A slow consumer with + In this section we will discuss how ActiveMQ can be configured to deal with slow consumers. A slow consumer with a server-side queue (e.g. JMS topic subscriber) can pose a significant problem for broker performance. If messages build up in the consumer's server-side queue then memory will begin filling up and the broker may enter paging mode which would impact performance negatively. However, criteria can be set so that consumers which don't diff --git a/docs/user-manual/en/spring-integration.xml b/docs/user-manual/en/spring-integration.xml index 2c02972c48..c69016a0d7 100644 --- a/docs/user-manual/en/spring-integration.xml +++ b/docs/user-manual/en/spring-integration.xml @@ -20,27 +20,27 @@ + %BOOK_ENTITIES; ]> Spring Integration - HornetQ provides a simple bootstrap class, + ActiveMQ provides a simple bootstrap class, org.apache.activemq.integration.spring.SpringJmsBootstrap, for - integration with Spring. To use it, you configure HornetQ as you always + integration with Spring. To use it, you configure ActiveMQ as you always would, through its various configuration files like - hornetq-configuration.xml, - hornetq-jms.xml, and - hornetq-users.xml. The Spring helper class starts the - HornetQ server and adds any factories or destinations configured within - hornetq-jms.xml directly into the namespace of the Spring - context. Let's take this hornetq-jms.xml file for + activemq-configuration.xml, + activemq-jms.xml, and + activemq-users.xml. The Spring helper class starts the + ActiveMQ server and adds any factories or destinations configured within + activemq-jms.xml directly into the namespace of the Spring + context. Let's take this activemq-jms.xml file for instance: <configuration xmlns="urn:activemq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="urn:hornetq /schema/activemq-jms.xsd"> + xsi:schemaLocation="urn:activemq /schema/activemq-jms.xsd"> <!--the connection factory used by the example--> <connection-factory name="ConnectionFactory"> <connectors> @@ -82,7 +82,7 @@ </beans> As you can see, the listenerContainer bean references the components defined - in the hornetq-jms.xml file. The + in the activemq-jms.xml file. The SpringJmsBootstrap class extends the EmbeddedJMS class talked about in and the same defaults and diff --git a/docs/user-manual/en/thread-pooling.xml b/docs/user-manual/en/thread-pooling.xml index e78b1b01fe..59fede9b3a 100644 --- a/docs/user-manual/en/thread-pooling.xml +++ b/docs/user-manual/en/thread-pooling.xml @@ -18,22 +18,22 @@ + %BOOK_ENTITIES; ]> Thread management - This chapter describes how HornetQ uses and pools threads and how you can manage + This chapter describes how ActiveMQ uses and pools threads and how you can manage them. First we'll discuss how threads are managed and used on the server side, then we'll look at the client side.
Server-Side Thread Management - Each HornetQ Server maintains a single thread pool for general use, and a scheduled + Each ActiveMQ Server maintains a single thread pool for general use, and a scheduled thread pool for scheduled use. A Java scheduled thread pool cannot be configured to use a standard thread pool, otherwise we could use a single thread pool for both scheduled and non scheduled activity. - A separate thread pool is also used to service connections. HornetQ can use "old" + A separate thread pool is also used to service connections. ActiveMQ can use "old" (blocking) IO or "new" (non-blocking) IO also called NIO. Both of these options use a separate thread pool, but each of them behaves uniquely. Since old IO requires a thread per connection its thread pool is unbounded. The thread @@ -49,7 +49,7 @@ since it has no remaining threads to do anything else. However, even an unbounded thread pool can run into trouble if it becomes too large. If you require the server to handle many concurrent connections you should use NIO, not old IO. - When using new IO (NIO), HornetQ will, by default, cap its thread pool at three times + When using new IO (NIO), ActiveMQ will, by default, cap its thread pool at three times the number of cores (or hyper-threads) as reported by Runtime.getRuntime().availableProcessors() for processing incoming packets. To override this value, you can set the number of threads by specifying the parameter @@ -63,7 +63,7 @@ that require running periodically or with delays. It maps internally to a java.util.concurrent.ScheduledThreadPoolExecutor instance. The maximum number of thread used by this pool is configure in hornetq-configuration.xml with the activemq-configuration.xml with the scheduled-thread-pool-max-size parameter. The default value is 5 threads. A small number of threads is usually sufficient for this pool. @@ -74,7 +74,7 @@ server side. It maps internally to a java.util.concurrent.ThreadPoolExecutor instance. The maximum number of thread used by this pool is configure in hornetq-configuration.xml with the activemq-configuration.xml with the thread-pool-max-size parameter. If a value of -1 is used this signifies that the thread pool has no upper bound and new threads will be created on demand if there are not enough @@ -105,21 +105,21 @@ Asynchronous IO Asynchronous IO has a thread pool for receiving and dispatching events out of the native layer. You will find it on a thread dump with the prefix - HornetQ-AIO-poller-pool. HornetQ uses one thread per opened file on the journal + ActiveMQ-AIO-poller-pool. ActiveMQ uses one thread per opened file on the journal (there is usually one). There is also a single thread used to invoke writes on libaio. We do that to avoid context switching on libaio that would cause performance issues. You will find this - thread on a thread dump with the prefix HornetQ-AIO-writer-pool. + thread on a thread dump with the prefix ActiveMQ-AIO-writer-pool.
Client-Side Thread Management - On the client side, HornetQ maintains a single static scheduled thread pool and a + On the client side, ActiveMQ maintains a single static scheduled thread pool and a single static general thread pool for use by all clients using the same classloader in that JVM instance. The static scheduled thread pool has a maximum size of 5 threads, and the general purpose thread pool has an unbounded maximum size. - If required HornetQ can also be configured so that each If required ActiveMQ can also be configured so that each ClientSessionFactory instance does not use these static pools but instead maintains its own scheduled and general purpose pool. Any sessions created from that ClientSessionFactory will use those pools instead. @@ -127,7 +127,7 @@ simply use the appropriate setter methods immediately after creation, for example: -ServerLocator locator = HornetQClient.createServerLocatorWithoutHA(...) +ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(...) ClientSessionFactory myFactory = locator.createClientSessionFactory(); myFactory.setUseGlobalPools(false); myFactory.setScheduledThreadPoolMaxSize(10); @@ -136,9 +136,9 @@ myFactory.setThreadPoolMaxSize(-1); ClientSessionFactory and use it to create the ConnectionFactory instance, for example: -ConnectionFactory myConnectionFactory = HornetQJMSClient.createConnectionFactory(myFactory); - If you're using JNDI to instantiate HornetQConnectionFactory - instances, you can also set these parameters in the hornetq-jms.xml +ConnectionFactory myConnectionFactory = ActiveMQJMSClient.createConnectionFactory(myFactory); + If you're using JNDI to instantiate ActiveMQConnectionFactory + instances, you can also set these parameters in the activemq-jms.xml file where you describe your connection factory, for example: <connection-factory name="ConnectionFactory"> diff --git a/docs/user-manual/en/tools.xml b/docs/user-manual/en/tools.xml index 12bf70e5ce..372b59049d 100644 --- a/docs/user-manual/en/tools.xml +++ b/docs/user-manual/en/tools.xml @@ -18,14 +18,14 @@ + %BOOK_ENTITIES; ]> Tools - HornetQ ships with several helpful command line tools. All tools are available from the hornetq-tools-<version>-jar-with-dependencies.jar. - As the name suggests, this Java archive contains HornetQ along with all of its dependencies. This is done to + ActiveMQ ships with several helpful command line tools. All tools are available from the activemq-tools-<version>-jar-with-dependencies.jar. + As the name suggests, this Java archive contains ActiveMQ along with all of its dependencies. This is done to simplify the execution of the tools by eliminating the need so specify a classpath. These tools are: @@ -34,7 +34,7 @@ are the paths to the directories where the bindings and message journals are stored, respectively. For example: - java -jar hornetq-tools-<version>-jar-with-dependencies.jar print-data /home/user/hornetq/data/bindings /home/user/hornetq/data/journal + java -jar activemq-tools-<version>-jar-with-dependencies.jar print-data /home/user/activemq/data/bindings /home/user/activemq/data/journal print-pages. Used for low-level inspection of paged message data. It takes two @@ -42,7 +42,7 @@ paths to the directories where paged messages and the message journals are stored, respectively. For example: - java -jar hornetq-tools-<version>-jar-with-dependencies.jar print-pages /home/user/hornetq/data/paging-directory /home/user/hornetq/data/journal + java -jar activemq-tools-<version>-jar-with-dependencies.jar print-pages /home/user/activemq/data/paging-directory /home/user/activemq/data/journal export. Used for exporting all binding and message data (including paged and large @@ -65,7 +65,7 @@ Here's an example: - java -jar hornetq-tools-<version>-jar-with-dependencies.jar export /home/user/hornetq/data/bindings-directory /home/user/hornetq/data/journal-directory /home/user/hornetq/data/paging-directory /home/user/hornetq/data/large-messages + java -jar activemq-tools-<version>-jar-with-dependencies.jar export /home/user/activemq/data/bindings-directory /home/user/activemq/data/journal-directory /home/user/activemq/data/paging-directory /home/user/activemq/data/large-messages This tool will export directly to standard out so if the data needs to be stored in a file please redirect as appropriate for the operation system in use. Also, please note that the export tool is single threaded so depending on the size of the journal it could take awhile to complete. @@ -74,7 +74,7 @@ import. Used for importing data from an XML document generated by the export tool. The import tool reads the XML document and connects - to a HornetQ server via Netty to import all the data. It takes 5 parameters: + to a ActiveMQ server via Netty to import all the data. It takes 5 parameters: @@ -88,7 +88,7 @@ - port - the port where HornetQ is listening. + port - the port where ActiveMQ is listening. transactional - a boolean flag to indicate whether or not to @@ -108,7 +108,7 @@ Here's an example: - java -jar hornetq-tools-<version>-jar-with-dependencies.jar import /home/user/exportData.xml 127.0.0.1 5445 false false + java -jar activemq-tools-<version>-jar-with-dependencies.jar import /home/user/exportData.xml 127.0.0.1 5445 false false Like the export tool the import tool is single threaded so depending on the size of the XML file it may take awhile for the process to complete. diff --git a/docs/user-manual/en/transaction-config.xml b/docs/user-manual/en/transaction-config.xml index 4f0905e3a8..df77172e88 100644 --- a/docs/user-manual/en/transaction-config.xml +++ b/docs/user-manual/en/transaction-config.xml @@ -18,22 +18,22 @@ + %BOOK_ENTITIES; ]> Resource Manager Configuration - HornetQ has its own Resource Manager for handling the lifespan of JTA transactions. When a + ActiveMQ has its own Resource Manager for handling the lifespan of JTA transactions. When a transaction is started the resource manager is notified and keeps a record of the transaction and its current state. It is possible in some cases for a transaction to be started but then forgotten about. Maybe the client died and never came back. If this happens then the transaction will just sit there indefinitely. - To cope with this HornetQ can, if configured, scan for old transactions and rollback any + To cope with this ActiveMQ can, if configured, scan for old transactions and rollback any it finds. The default for this is 3000000 milliseconds (5 minutes), i.e. any transactions older than 5 minutes are removed. This timeout can be changed by editing the transaction-timeout property in hornetq-configuration.xml (value must be in milliseconds). + >transaction-timeout property in activemq-configuration.xml (value must be in milliseconds). The property transaction-timeout-scan-period configures how often, in milliseconds, to scan for old transactions. - Please note that HornetQ will not unilaterally rollback any XA transactions in a prepared state - this must be heuristically rolled + Please note that ActiveMQ will not unilaterally rollback any XA transactions in a prepared state - this must be heuristically rolled back via the management API if you are sure they will never be resolved by the transaction manager. diff --git a/docs/user-manual/en/undelivered-messages.xml b/docs/user-manual/en/undelivered-messages.xml index ec76c5d30f..c429fec9f5 100644 --- a/docs/user-manual/en/undelivered-messages.xml +++ b/docs/user-manual/en/undelivered-messages.xml @@ -18,7 +18,7 @@ + %BOOK_ENTITIES; ]> @@ -62,7 +62,7 @@ <max-redelivery-delay>50000</max-redelivery-delay> </address-setting> - If a redelivery-delay is specified, HornetQ will wait this delay + If a redelivery-delay is specified, ActiveMQ will wait this delay before redelivering the messages. By default, there is no redelivery delay (redelivery-delayis set to 0). @@ -89,7 +89,7 @@ attempts, the message is removed from the queue and send instead to a dead letter address. Any such messages can then be diverted to queue(s) where they can later be perused by the system administrator for action to be taken. - HornetQ's addresses can be assigned a dead letter address. Once the messages have been + ActiveMQ's addresses can be assigned a dead letter address. Once the messages have been unsuccessfully delivered for a given number of attempts, they are removed from the queue and sent to the dead letter address. These dead letter messages can later be consumed for further inspection. @@ -138,7 +138,7 @@
Delivery Count Persistence - In normal use, HornetQ does not update delivery count persistently + In normal use, ActiveMQ does not update delivery count persistently until a message is rolled back (i.e. the delivery count is not updated before the message is delivered to the consumer). In most messaging use cases, the messages are consumed, acknowledged and forgotten as soon as they are @@ -150,10 +150,10 @@ not have been reflected in the delivery count. During the recovery phase, the server will not have knowledge of that and will deliver the message with redelivered set to false while it should be true. - As this behavior breaks strict JMS semantics, HornetQ allows to persist delivery count + As this behavior breaks strict JMS semantics, ActiveMQ allows to persist delivery count before message delivery but disabled it by default for performance implications. To enable it, set persist-delivery-count-before-delivery to true in hornetq-configuration.xml: + >true in activemq-configuration.xml: <persist-delivery-count-before-delivery>true</persist-delivery-count-before-delivery>
diff --git a/docs/user-manual/en/using-core.xml b/docs/user-manual/en/using-core.xml index 38f3d3ab41..2065a4bafe 100644 --- a/docs/user-manual/en/using-core.xml +++ b/docs/user-manual/en/using-core.xml @@ -18,7 +18,7 @@ Using Core - HornetQ core is a completely JMS-agnostic messaging system with its own non-JMS API. We + ActiveMQ core is a completely JMS-agnostic messaging system with its own non-JMS API. We call this the core API. If you don't want to use JMS you can use the core API directly. The core API provides all the functionality of JMS but without much of the complexity. It also provides features that @@ -62,12 +62,12 @@ Messages can be specified with a priority value between 0 and 9. 0 - represents the lowest priority and 9 represents the highest. HornetQ will + represents the lowest priority and 9 represents the highest. ActiveMQ will attempt to deliver higher priority messages before lower priority ones. - Messages can be specified with an optional expiry time. HornetQ will not + Messages can be specified with an optional expiry time. ActiveMQ will not deliver messages after its expiry time has been exceeded. @@ -75,7 +75,7 @@ message was sent. - HornetQ also supports the sending/consuming of very large messages - much + ActiveMQ also supports the sending/consuming of very large messages - much larger than can fit in available RAM at any one time. @@ -122,7 +122,7 @@ In JMS terms think of a ServerLocator in the same way you would a JMS Connection Factory. ServerLocator instances are created using the HornetQClient factory class. + >ActiveMQClient factory class.
ClientSessionFactory @@ -145,7 +145,7 @@ ClientSession instances can be registered with an optional SendAcknowledgementHandler. This allows your client code to be notified asynchronously when sent messages have successfully reached the server. - This unique HornetQ feature, allows you to have full guarantees that sent messages + This unique ActiveMQ feature, allows you to have full guarantees that sent messages have reached the server without having to block on each message sent until a response is received. Blocking on each messages sent is costly since it requires a network round trip for each message sent. By not blocking and receiving send @@ -186,7 +186,7 @@ queue for the consumer, creating the consumer and starting it. -ServerLocator locator = HornetQClient.createServerLocatorWithoutHA(new TransportConfiguration( +ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(new TransportConfiguration( InVMConnectorFactory.class.getName())); // In this simple example, we just use one session for both producing and receiving diff --git a/docs/user-manual/en/using-jms.xml b/docs/user-manual/en/using-jms.xml index 6845db4cef..2c2dce7736 100644 --- a/docs/user-manual/en/using-jms.xml +++ b/docs/user-manual/en/using-jms.xml @@ -18,24 +18,24 @@ + %BOOK_ENTITIES; ]> Using JMS - Although HornetQ provides a JMS agnostic messaging API, many users will be more + Although ActiveMQ provides a JMS agnostic messaging API, many users will be more comfortable using JMS. JMS is a very popular API standard for messaging, and most messaging systems provide a JMS API. If you are completely new to JMS we suggest you follow the Sun JMS tutorial - a full JMS tutorial is out of scope for this guide. - HornetQ also ships with a wide range of examples, many of which demonstrate JMS API usage. + ActiveMQ also ships with a wide range of examples, many of which demonstrate JMS API usage. A good place to start would be to play around with the simple JMS Queue and Topic example, but we also provide examples for many other parts of the JMS API. A full description of the examples is available in . In this section we'll go through the main steps in configuring the server for JMS and creating a simple JMS program. We'll also show how to configure and use JNDI, and also how - to use JMS with HornetQ without using any JNDI. + to use JMS with ActiveMQ without using any JNDI.
A simple ordering system For this chapter we're going to use a very simple ordering system as our example. It is @@ -52,7 +52,7 @@
JMS Server Configuration - The file hornetq-jms.xml on the server classpath contains any JMS + The file activemq-jms.xml on the server classpath contains any JMS Queue, Topic and ConnectionFactory instances that we wish to create and make available to lookup via the JNDI. A JMS ConnectionFactory object is used by the client to make connections to the @@ -65,7 +65,7 @@ <configuration xmlns="urn:activemq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="urn:hornetq ../schemas/activemq-jms.xsd "> + xsi:schemaLocation="urn:activemq ../schemas/activemq-jms.xsd "> <connection-factory name="ConnectionFactory"> <connectors> @@ -86,13 +86,13 @@ The JMS connection factory references a connector called netty. This is a reference to a connector object deployed in - the main core configuration file hornetq-configuration.xml which + the main core configuration file activemq-configuration.xml which defines the transport and parameters used to actually connect to the server.
Connection Factory Types - The JMS API doc provides several connection factories for applications. HornetQ JMS users + The JMS API doc provides several connection factories for applications. ActiveMQ JMS users can choose to configure the types for their connection factories. Each connection factory has a signature attribute and a xa parameter, the combination of which determines the type of the factory. Attribute signature @@ -151,7 +151,11 @@ <configuration xmlns="urn:activemq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" +<<<<<<< HEAD xsi:schemaLocation="urn:hornetq ../schemas/activemq-jms.xsd "> +======= + xsi:schemaLocation="urn:activemq ../schemas/activemq-jms.xsd "> +>>>>>>> 198a239... ACTIVEMQ6-9 Clean up docs <connection-factory name="ConnectionFactory" signature="queue"> <xa>true</xa> @@ -184,13 +188,13 @@ java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces In the default standalone configuration, JNDI server ports are configured in the file - hornetq-beans.xml by setting properties on the activemq-beans.xml by setting properties on the JNDIServer bean: <bean name="StandaloneServer" class="org.apache.activemq.jms.server.impl.StandaloneNamingServer"> <constructor> <parameter> - <inject bean="HornetQServer"/> + <inject bean="ActiveMQServer"/> </parameter> </constructor> <property name="port">${jnp.port:1099}</property> @@ -204,8 +208,8 @@ java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaceslocalhost! - The JNDIServer bean must be defined only when HornetQ is running in - stand-alone mode. When HornetQ is integrated to JBoss Application + The JNDIServer bean must be defined only when ActiveMQ is running in + stand-alone mode. When ActiveMQ is integrated to JBoss Application Server, JBoss AS will provide a ready-to-use JNDI server without any additional configuration. @@ -254,21 +258,21 @@ System.out.println("Got order: " + receivedMessage.getText()); JNDI, in some cases a JNDI server is not available and you still want to use JMS, or you just think "Why do I need JNDI? Why can't I just instantiate these objects directly?" - With HornetQ you can do exactly that. HornetQ supports the direct instantiation of JMS + With ActiveMQ you can do exactly that. ActiveMQ supports the direct instantiation of JMS Queue, Topic and ConnectionFactory instances, so you don't have to use JNDI at all. For a full working example of direct instantiation please see the JMS examples in . Here's our simple example, rewritten to not use JNDI at all: - We create the JMS ConnectionFactory object via the HornetQJMSClient Utility class, + We create the JMS ConnectionFactory object via the ActiveMQJMSClient Utility class, note we need to provide connection parameters and specify which transport we are using, for more information on connectors please see . TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName()); -ConnectionFactory cf = HornetQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF,transportConfiguration); - We also create the JMS Queue object via the HornetQJMSClient Utility class: - Queue orderQueue = HornetQJMSClient.createQueue("OrderQueue"); +ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactoryWithoutHA(JMSFactoryType.CF,transportConfiguration); + We also create the JMS Queue object via the ActiveMQJMSClient Utility class: + Queue orderQueue = ActiveMQJMSClient.createQueue("OrderQueue"); Next we create a JMS connection using the connection factory: Connection connection = cf.createConnection(); And we create a non transacted JMS Session, with AUTO_ACKNOWLEDGE acknowledge diff --git a/docs/user-manual/en/using-server.xml b/docs/user-manual/en/using-server.xml index 4f202bc05c..d6edac9d93 100644 --- a/docs/user-manual/en/using-server.xml +++ b/docs/user-manual/en/using-server.xml @@ -18,16 +18,16 @@ + %BOOK_ENTITIES; ]> Using the Server - This chapter will familiarise you with how to use the HornetQ server. + This chapter will familiarise you with how to use the ActiveMQ server. We'll show where it is, how to start and stop it, and we'll describe the directory layout and what all the files are and what they do. - For the remainder of this chapter when we talk about the HornetQ server we mean the - HornetQ standalone server, in its default configuration with a JMS Service and JNDI service + For the remainder of this chapter when we talk about the ActiveMQ server we mean the + ActiveMQ standalone server, in its default configuration with a JMS Service and JNDI service enabled. When running embedded in JBoss Application Server the layout may be slightly different but by-and-large will be the same. @@ -35,19 +35,19 @@ Starting and Stopping the standalone server In the distribution you will find a directory called bin. cd into that directory and you will find a Unix/Linux script called - hornetq and a Windows script called hornetq.cmd. - To start the HornetQ instance on Unix/Linux type ./hornetq run - To start the HornetQ instance on Windows type hornetq.cmd run + activemq and a Windows script called activemq.cmd. + To start the ActiveMQ instance on Unix/Linux type ./activemq run + To start the ActiveMQ instance on Windows type activemq.cmd run These scripts are very simple and basically just set-up the classpath and some JVM parameters and bootstrap the server using Airline. - To stop the HornetQ instance you will use the same hornetq script. - To run on Unix/Linux type ./hornetq stop - To run on Windows type hornetq.cmd stop - Please note that HornetQ requires a Java 6 or later runtime to run. + To stop the ActiveMQ instance you will use the same activemq script. + To run on Unix/Linux type ./activemq stop + To run on Windows type activemq.cmd stop + Please note that ActiveMQ requires a Java 6 or later runtime to run. By default the config/non-clustered/bootstrap.xml configuration is used. The configuration can be changed e.g. by running - ./hornetq run -- xml:../config/clustered/bootstrap.xml or another config of + ./activemq run -- xml:../config/clustered/bootstrap.xml or another config of your choosing.
@@ -55,7 +55,7 @@ The run scripts set some JVM settings for tuning the garbage collection policy and heap size. We recommend using a parallel garbage collection algorithm to smooth out latency and minimise large GC pauses. - By default HornetQ runs in a maximum of 1GiB of RAM. To increase the memory settings + By default ActiveMQ runs in a maximum of 1GiB of RAM. To increase the memory settings change the -Xms and -Xmx memory settings as you would for any Java program. If you wish to add any more JVM arguments or tune the existing ones, the run scripts @@ -91,7 +91,7 @@
System properties - HornetQ can take a system property on the command line for configuring logging. + ActiveMQ can take a system property on the command line for configuring logging. For more information on configuring logging, please see .
@@ -101,31 +101,31 @@ by default) references the specific broker configuration files. - hornetq-configuration.xml. This is the main HornetQ + activemq-configuration.xml. This is the main ActiveMQ configuration file. All the parameters in this file are described in . Please see for more information on this file. - hornetq-queues.xml. This file contains predefined queues, + activemq-queues.xml. This file contains predefined queues, queue settings and security settings. The file is optional - all this - configuration can also live in hornetq-configuration.xml. In + configuration can also live in activemq-configuration.xml. In fact, the default configuration sets do not have a hornetq-queues.xml file. The purpose of allowing queues to be + >activemq-queues.xml file. The purpose of allowing queues to be configured in these files is to allow you to manage your queue configuration over many files instead of being forced to maintain it in a single file. There - can be many hornetq-queues.xml files on the classpath. All + can be many activemq-queues.xml files on the classpath. All will be loaded if found. - hornetq-users.xml HornetQ ships with a basic security + activemq-users.xml ActiveMQ ships with a basic security manager implementation which obtains user credentials from the hornetq-users.xml file. This file contains user, password and + >activemq-users.xml file. This file contains user, password and role information. For more information on security, please see . - hornetq-jms.xml The distro configuration by default + activemq-jms.xml The distro configuration by default includes a server side JMS service which mainly deploys JMS Queues, Topics and ConnectionFactorys from this file into JNDI. If you're not using JMS, or you don't need to deploy JMS objects on the server side, then you don't need this @@ -135,7 +135,7 @@ The property file-deployment-enabled in the hornetq-configuration.xml configuration when set to false means that + >activemq-configuration.xml configuration when set to false means that the other configuration files are not loaded. This is true by default. It is also possible to use system property substitution in all the configuration @@ -144,15 +144,15 @@ <connector name="netty"> <factory-class>org.apache.activemq.core.remoting.impl.netty.NettyConnectorFactory</factory-class> - <param key="host" value="${hornetq.remoting.netty.host:localhost}"/> - <param key="port" value="${hornetq.remoting.netty.port:5445}"/> + <param key="host" value="${activemq.remoting.netty.host:localhost}"/> + <param key="port" value="${activemq.remoting.netty.port:5445}"/> </connector> Here you can see we have replaced 2 values with system properties hornetq.remoting.netty.host and hornetq.remoting.netty.port. These values will be replaced by the value + >activemq.remoting.netty.host and activemq.remoting.netty.port. These values will be replaced by the value found in the system property if there is one, if not they default back to localhost or 5445 respectively. It is also possible to not supply a default. i.e. ${hornetq.remoting.netty.host}, however the system property + >${activemq.remoting.netty.host}, however the system property must be supplied in that case.
@@ -161,10 +161,10 @@ The bootstrap file is very simple. Let's take a look at an example: -<broker xmlns="http://hornetq.org/schema"> +<broker xmlns="http://activemq.org/schema"> - <file:core configuration="${hornetq.home}/config/stand-alone/non-clustered/hornetq-configuration.xml"></core> - <file:jms configuration="${hornetq.home}/config/stand-alone/non-clustered/hornetq-jms.xml"></jms> + <file:core configuration="${activemq.home}/config/stand-alone/non-clustered/activemq-configuration.xml"></core> + <file:jms configuration="${activemq.home}/config/stand-alone/non-clustered/activemq-jms.xml"></jms> <basic-security/> @@ -182,7 +182,7 @@ jms This deploys any JMS Objects such as JMS Queues, Topics and ConnectionFactory - instances from the hornetq-jms.xml file specified. It also + instances from the activemq-jms.xml file specified. It also provides a simple management API for manipulating JMS Objects. On the whole it just translates and delegates its work to the core server. If you don't need to deploy JMS Queues, Topics and ConnectionFactories from server side configuration @@ -197,10 +197,10 @@
The main configuration file. - The configuration for the HornetQ core server is contained in hornetq-configuration.xml. This is what the FileConfiguration bean uses + The configuration for the ActiveMQ core server is contained in activemq-configuration.xml. This is what the FileConfiguration bean uses to configure the messaging server. - There are many attributes which you can configure HornetQ. In most cases the defaults + There are many attributes which you can configure ActiveMQ. In most cases the defaults will do fine, in fact every attribute can be defaulted which means a file with a single empty configuration element is a valid configuration file. The different configuration will be explained throughout the manual or you can refer to the diff --git a/docs/user-manual/en/vertx-integration.xml b/docs/user-manual/en/vertx-integration.xml index 5a9ef9acf6..f9d8efc5d9 100644 --- a/docs/user-manual/en/vertx-integration.xml +++ b/docs/user-manual/en/vertx-integration.xml @@ -18,7 +18,7 @@ + %BOOK_ENTITIES; ]> @@ -26,13 +26,13 @@ Vert.x is a lightweight, high performance application platform for the JVM that's designed for modern mobile, web, and enterprise applications. Vert.x provides a distributed event bus that allows messages to be sent across vert.x instances and clients. You can now redirect and persist any vert.x messages - to HornetQ and route those messages to a specified vertx address by configuring HornetQ vertx incoming and outgoing + to ActiveMQ and route those messages to a specified vertx address by configuring ActiveMQ vertx incoming and outgoing vertx connector services.
Configuring a Vertx Incoming Connector Service - Vertx Incoming Connector services receive messages from vertx event bus and route them to a HornetQ queue. + Vertx Incoming Connector services receive messages from vertx event bus and route them to a ActiveMQ queue. Such a service can be configured as follows: <connector-service name="vertx-incoming-connector"> @@ -46,7 +46,7 @@ Shown are the required params for the connector service: - queue. The name of the HornetQ queue to send message to. + queue. The name of the ActiveMQ queue to send message to. As well as these required paramaters there are the following optional parameters @@ -61,7 +61,7 @@ quorum-size. The quorum size of the target vertx instance. - ha-group. The name of the ha-group of target vertx instance. Default is hornetq. + ha-group. The name of the ha-group of target vertx instance. Default is activemq. vertx-address. The vertx address to listen to. default is org.apache.activemq. @@ -71,7 +71,7 @@
Configuring a Vertx Outgoing Connector Service - Vertx Outgoing Connector services fetch vertx messages from a HornetQ queue and put them to vertx event bus. + Vertx Outgoing Connector services fetch vertx messages from a ActiveMQ queue and put them to vertx event bus. Such a service can be configured as follows: <connector-service name="vertx-outgoing-connector"> @@ -86,7 +86,7 @@ Shown are the required params for the connector service: - queue. The name of the HornetQ queue to fetch message from. + queue. The name of the ActiveMQ queue to fetch message from. As well as these required paramaters there are the following optional parameters @@ -101,7 +101,7 @@ quorum-size. The quorum size of the target vertx instance. - ha-group. The name of the ha-group of target vertx instance. Default is hornetq. + ha-group. The name of the ha-group of target vertx instance. Default is activemq. vertx-address. The vertx address to put messages to. default is org.apache.activemq. diff --git a/docs/user-manual/en/wildcard-routing.xml b/docs/user-manual/en/wildcard-routing.xml index 44f0f75953..9e5ff70be7 100644 --- a/docs/user-manual/en/wildcard-routing.xml +++ b/docs/user-manual/en/wildcard-routing.xml @@ -19,13 +19,13 @@ + %BOOK_ENTITIES; ]> Routing Messages With Wild Cards - HornetQ allows the routing of messages via wildcard addresses. + ActiveMQ allows the routing of messages via wildcard addresses. If a queue is created with an address of say queue.news.# then it will receive any messages sent to addresses that match this, for instance queue.news.europe or queue.news.usa or In JMS terminology this allows "topic hierarchies" to be created. To enable this functionality set the property wild-card-routing-enabled - in the hornetq-configuration.xml file to true. This is + in the activemq-configuration.xml file to true. This is true by default. For more information on the wild card syntax take a look at chapter, also see + %BOOK_ENTITIES; ]> - Understanding the HornetQ Wildcard Syntax - HornetQ uses a specific syntax for representing wildcards in security settings, + Understanding the ActiveMQ Wildcard Syntax + ActiveMQ uses a specific syntax for representing wildcards in security settings, address settings and when creating consumers. The syntax is similar to that used by AMQP. - A HornetQ wildcard expression contains words delimited by the character 'A ActiveMQ wildcard expression contains words delimited by the character '.' (full stop). The special characters '#' and '*' also have special meaning and can take the place of a word. diff --git a/docs/user-manual/pom.xml b/docs/user-manual/pom.xml index 1ba86e81c9..dfe1df01db 100644 --- a/docs/user-manual/pom.xml +++ b/docs/user-manual/pom.xml @@ -32,8 +32,8 @@ en - HornetQ_User_Manual - HornetQ User Manual + ActiveMQ_User_Manual + ActiveMQ User Manual diff --git a/examples/jms/activemq-jms-examples-common/common.css b/examples/jms/activemq-jms-examples-common/common.css index 333ea01bfd..453e0c92b8 100644 --- a/examples/jms/activemq-jms-examples-common/common.css +++ b/examples/jms/activemq-jms-examples-common/common.css @@ -1,5 +1,4 @@ body { - background: url(images/hornetQ-banner_final.png) top left no-repeat; } h1 { diff --git a/examples/jms/activemq-jms-examples-common/images/hornetQ-banner_final.png b/examples/jms/activemq-jms-examples-common/images/hornetQ-banner_final.png deleted file mode 100644 index 6388dff1f5..0000000000 Binary files a/examples/jms/activemq-jms-examples-common/images/hornetQ-banner_final.png and /dev/null differ diff --git a/tests/integration-tests/src/test/java/org/apache/activemq/tests/integration/management/SecurityManagementWithConfiguredAdminUserTest.java b/tests/integration-tests/src/test/java/org/apache/activemq/tests/integration/management/SecurityManagementWithConfiguredAdminUserTest.java index 49a8de5674..a1a2f6c573 100644 --- a/tests/integration-tests/src/test/java/org/apache/activemq/tests/integration/management/SecurityManagementWithConfiguredAdminUserTest.java +++ b/tests/integration-tests/src/test/java/org/apache/activemq/tests/integration/management/SecurityManagementWithConfiguredAdminUserTest.java @@ -16,7 +16,6 @@ import org.apache.activemq.api.config.ActiveMQDefaultConfiguration; import org.junit.Test; import java.util.Set; - import org.apache.activemq.api.core.TransportConfiguration; import org.apache.activemq.core.config.Configuration; import org.apache.activemq.core.remoting.impl.invm.InVMAcceptorFactory;