This closes #135 - updating manual to Apache ActiveMQ
This commit is contained in:
commit
7720928c0b
|
@ -1,7 +1,7 @@
|
|||
![ActiveMQ logo](images/activemq-logo.jpg)
|
||||
|
||||
ActiveMQ User Manual
|
||||
Apache ActiveMQ User Manual
|
||||
====================
|
||||
|
||||
The User manual is an in depth manual on all aspects of ActiveMQ
|
||||
The User manual is an in depth manual on all aspects of Apache ActiveMQ
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@
|
|||
* [The Client Classpath](client-classpath.md)
|
||||
* [Examples](examples.md)
|
||||
* [Routing Messages With Wild Cards](wildcard-routing.md)
|
||||
* [Understanding the ActiveMQ Wildcard Syntax](wildcard-syntax.md)
|
||||
* [Understanding the Apache ActiveMQ Wildcard Syntax](wildcard-syntax.md)
|
||||
* [Filter Expressions](filter-expressions.md)
|
||||
* [Persistence](persistence.md)
|
||||
* [Configuring Transports](configuring-transports.md)
|
||||
|
@ -45,7 +45,7 @@
|
|||
* [Thread management](thread-pooling.md)
|
||||
* [Logging](logging.md)
|
||||
* [REST Interface](rest.md)
|
||||
* [Embedding ActiveMQ](embedding-activemq.md)
|
||||
* [Embedding Apache ActiveMQ](embedding-activemq.md)
|
||||
* [Spring Integration](spring-integration.md)
|
||||
* [AeroGear Integration](aerogear-integration.md)
|
||||
* [VertX Integration](vertx-integration.md)
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
AeroGears push technology provides support for different push
|
||||
notification technologies like Google Cloud Messaging, Apple's APNs or
|
||||
Mozilla's SimplePush. ActiveMQ allows you to configure a Connector
|
||||
Mozilla's SimplePush. Apache 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.
|
||||
|
|
|
@ -1,31 +1,31 @@
|
|||
# Architecture
|
||||
|
||||
In this section we will give an overview of the ActiveMQ high level
|
||||
In this section we will give an overview of the Apache ActiveMQ high level
|
||||
architecture.
|
||||
|
||||
## Core Architecture
|
||||
|
||||
ActiveMQ core is designed simply as set of Plain Old Java Objects
|
||||
Apache 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, ActiveMQ core has only one jar dependency, netty.jar,
|
||||
possible. In fact, Apache 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 ActiveMQ to be easily embedded in your own project, or
|
||||
This allows Apache ActiveMQ to be easily embedded in your own project, or
|
||||
instantiated in any dependency injection framework such as Spring or
|
||||
Google Guice.
|
||||
|
||||
Each ActiveMQ server has its own ultra high performance persistent
|
||||
Each Apache 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.
|
||||
|
||||
ActiveMQ clients, potentially on different physical machines interact
|
||||
with the ActiveMQ server. ActiveMQ currently provides two APIs for
|
||||
Apache ActiveMQ clients, potentially on different physical machines interact
|
||||
with the Apache ActiveMQ server. Apache ActiveMQ currently provides two APIs for
|
||||
messaging at the client side:
|
||||
|
||||
1. Core client API. This is a simple intuitive Java API that allows the
|
||||
|
@ -35,7 +35,7 @@ messaging at the client side:
|
|||
2. JMS client API. The standard JMS API is available at the client
|
||||
side.
|
||||
|
||||
ActiveMQ also provides different protocol implementations on the server so you can use respective clients for these protocols:
|
||||
Apache ActiveMQ also provides different protocol implementations on the server so you can use respective clients for these protocols:
|
||||
|
||||
1. Stomp
|
||||
2. OpenWire
|
||||
|
@ -45,13 +45,13 @@ ActiveMQ also provides different protocol implementations on the server so you c
|
|||
JMS semantics are implemented by a JMS facade layer on the client
|
||||
side.
|
||||
|
||||
The ActiveMQ server does not speak JMS and in fact does not know
|
||||
The Apache 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 ActiveMQ core client API before
|
||||
being transferred over the wire using the ActiveMQ wire format.
|
||||
are translated into operations on the Apache ActiveMQ core client API before
|
||||
being transferred over the wire using the Apache ActiveMQ wire format.
|
||||
|
||||
The server always just deals with core API interactions.
|
||||
|
||||
|
@ -59,25 +59,25 @@ A schematic illustrating this relationship is shown in figure 3.1 below:
|
|||
|
||||
![ActiveMQ architecture1](images/architecture1.jpg)
|
||||
|
||||
Figure 3.1 shows two user applications interacting with a ActiveMQ
|
||||
Figure 3.1 shows two user applications interacting with an Apache 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.
|
||||
|
||||
## ActiveMQ embedded in your own application
|
||||
## Apache ActiveMQ embedded in your own application
|
||||
|
||||
ActiveMQ core is designed as a set of simple POJOs so if you have an
|
||||
Apache 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 ActiveMQ server you can directly
|
||||
instantiate and embed ActiveMQ servers in your own application.
|
||||
don't want to expose that as an Apache ActiveMQ server you can directly
|
||||
instantiate and embed Apache ActiveMQ servers in your own application.
|
||||
|
||||
For more information on embedding ActiveMQ, see [Embedding ActiveMQ](embedding-activemq.md).
|
||||
For more information on embedding Apache ActiveMQ, see [Embedding Apache ActiveMQ](embedding-Apache activemq.md).
|
||||
|
||||
## ActiveMQ integrated with a JEE application server
|
||||
## Apache ActiveMQ integrated with a JEE application server
|
||||
|
||||
ActiveMQ provides its own fully functional Java Connector Architecture
|
||||
Apache 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.
|
||||
|
||||
|
@ -110,12 +110,12 @@ 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
|
||||
ActiveMQ server via the ActiveMQ JCA adaptor. Note that all
|
||||
Apache ActiveMQ server via the Apache 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 ActiveMQ.
|
||||
beans go through the adaptor and not directly to Apache ActiveMQ.
|
||||
|
||||
The large arrow with the prohibited sign shows an EJB session bean
|
||||
talking directly to the ActiveMQ server. This is not recommended as
|
||||
talking directly to the Apache 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.
|
||||
|
||||
|
@ -123,9 +123,9 @@ time you want to interact from the EJB, which is an anti-pattern.
|
|||
|
||||
For more information on using the JCA adaptor, please see [Application Server Integration and Java EE](appserver-integration.md).
|
||||
|
||||
## ActiveMQ stand-alone server
|
||||
## Apache ActiveMQ stand-alone server
|
||||
|
||||
ActiveMQ can also be deployed as a stand-alone server. This means a
|
||||
Apache ActiveMQ can also be deployed as a stand-alone server. This means a
|
||||
fully independent messaging server not dependent on a JEE application
|
||||
server.
|
||||
|
||||
|
|
|
@ -1,19 +1,19 @@
|
|||
# The Client Classpath
|
||||
|
||||
ActiveMQ requires several jars on the *Client Classpath* depending on
|
||||
whether the client uses ActiveMQ Core API, JMS, and JNDI.
|
||||
Apache ActiveMQ requires several jars on the *Client Classpath* depending on
|
||||
whether the client uses Apache ActiveMQ Core API, JMS, and JNDI.
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
> All the jars mentioned here can be found in the `lib` directory of the
|
||||
> ActiveMQ distribution. Be sure you only use the jars from the correct
|
||||
> Apache 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 ActiveMQ versions. Mixing and matching different jar
|
||||
> from different Apache ActiveMQ versions. Mixing and matching different jar
|
||||
> versions may cause subtle errors and failures to occur.
|
||||
|
||||
## ActiveMQ Core Client
|
||||
## Apache ActiveMQ Core Client
|
||||
|
||||
If you are using just a pure ActiveMQ Core client (i.e. no JMS) then you
|
||||
If you are using just a pure Apache ActiveMQ Core client (i.e. no JMS) then you
|
||||
need `activemq-core-client.jar`, `activemq-commons.jar`, and `netty.jar`
|
||||
on your client classpath.
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Client Reconnection and Session Reattachment
|
||||
|
||||
ActiveMQ clients can be configured to automatically reconnect or
|
||||
Apache 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.
|
||||
|
||||
|
@ -11,14 +11,14 @@ network failure, 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 [Detecting Dead Connections](connection-ttl.md)
|
||||
|
||||
In this scenario, ActiveMQ will automatically re-attach the client
|
||||
In this scenario, Apache 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 ActiveMQ clients send commands to their servers they store each sent
|
||||
As Apache 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
|
||||
|
@ -59,7 +59,7 @@ 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, ActiveMQ will automatically reconnect the connection and
|
||||
In this case, Apache 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.
|
||||
|
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
## Clusters Overview
|
||||
|
||||
ActiveMQ clusters allow groups of ActiveMQ servers to be grouped
|
||||
Apache ActiveMQ clusters allow groups of Apache 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
|
||||
the cluster is an active Apache ActiveMQ server which manages its own messages
|
||||
and handles its own connections.
|
||||
|
||||
The cluster is formed by each node declaring *cluster connections* to
|
||||
|
@ -22,7 +22,7 @@ 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 ActiveMQ will redistribute messages between
|
||||
message redistribution where Apache ActiveMQ will redistribute messages between
|
||||
nodes to avoid starvation.
|
||||
|
||||
Another important part of clustering is *server discovery* where servers
|
||||
|
@ -33,8 +33,8 @@ connect to them with the minimum of configuration.
|
|||
>
|
||||
> 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 ActiveMQ files. Do not
|
||||
> copy the ActiveMQ *data* (i.e. the `bindings`, `journal`, and
|
||||
> However, care must be taken when copying the Apache ActiveMQ files. Do not
|
||||
> copy the Apache 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` directory. This id
|
||||
|
@ -55,7 +55,7 @@ connection details to:
|
|||
all the other servers in the cluster.
|
||||
|
||||
This information, let's call it the Cluster Topology, is actually sent
|
||||
around normal ActiveMQ connections to clients and to other servers over
|
||||
around normal Apache 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
|
||||
|
@ -85,7 +85,7 @@ JGroups to broadcast connector pairs information.
|
|||
|
||||
Broadcast groups are defined in the server configuration file
|
||||
`activemq-configuration.xml`. There can be many broadcast groups per
|
||||
ActiveMQ server. All broadcast groups must be defined in a
|
||||
Apache ActiveMQ server. All broadcast groups must be defined in a
|
||||
`broadcast-groups` element.
|
||||
|
||||
Let's take a look at an example broadcast group from
|
||||
|
@ -159,7 +159,7 @@ following:
|
|||
|
||||
- `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 ActiveMQ can load it.
|
||||
file is in the java resource path so that Apache ActiveMQ can load it.
|
||||
|
||||
- `jgroups-channel` attribute. The name that JGroups channels connect
|
||||
to for broadcasting.
|
||||
|
@ -226,7 +226,7 @@ The following is an example of a JGroups file
|
|||
</config>
|
||||
|
||||
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
|
||||
want Apache 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 configuration is stored in a file named
|
||||
|
@ -249,7 +249,7 @@ 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 ActiveMQ:
|
||||
Discovery groups are used in two places in Apache ActiveMQ:
|
||||
|
||||
- By cluster connections so they know how to obtain an initial
|
||||
connection to download the topology
|
||||
|
@ -260,7 +260,7 @@ Discovery groups are used in two places in ActiveMQ:
|
|||
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 ActiveMQ connections.
|
||||
normal Apache ActiveMQ connections.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
|
@ -274,7 +274,7 @@ normal ActiveMQ connections.
|
|||
For cluster connections, discovery groups are defined in the server side
|
||||
configuration file `activemq-configuration.xml`. All discovery groups
|
||||
must be defined inside a `discovery-groups` element. There can be many
|
||||
discovery groups defined by ActiveMQ server. Let's look at an example:
|
||||
discovery groups defined by Apache ActiveMQ server. Let's look at an example:
|
||||
|
||||
<discovery-groups>
|
||||
<discovery-group name="my-discovery-group">
|
||||
|
@ -331,7 +331,7 @@ details as following:
|
|||
|
||||
- `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 ActiveMQ can load it.
|
||||
file is in the java resource path so that Apache ActiveMQ can load it.
|
||||
|
||||
- `jgroups-channel` attribute. The name that JGroups channels connect
|
||||
to for receiving broadcasts.
|
||||
|
@ -345,7 +345,7 @@ details as following:
|
|||
|
||||
#### Discovery Groups on the Client Side
|
||||
|
||||
Let's discuss how to configure a ActiveMQ client to use discovery to
|
||||
Let's discuss how to configure an Apache 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.
|
||||
|
||||
|
@ -511,7 +511,7 @@ ClientSession session = factory.createSession();
|
|||
## Server-Side Message Load Balancing
|
||||
|
||||
If cluster connections are defined between nodes of a cluster, then
|
||||
ActiveMQ will load balance messages arriving at a particular node from a
|
||||
Apache 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
|
||||
|
@ -537,7 +537,7 @@ 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.
|
||||
|
||||
ActiveMQ cluster connections can be configured to always blindly load
|
||||
Apache 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
|
||||
|
@ -551,7 +551,7 @@ 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
|
||||
`activemq-configuration.xml` inside a `cluster-connection` element.
|
||||
There can be zero or more cluster connections defined per ActiveMQ
|
||||
There can be zero or more cluster connections defined per Apache ActiveMQ
|
||||
server.
|
||||
|
||||
<cluster-connections>
|
||||
|
@ -598,7 +598,7 @@ specified. The following shows all the available configuration options
|
|||
connections 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 ActiveMQ Server can effectively take
|
||||
different addresses a single Apache ActiveMQ Server can effectively take
|
||||
part in multiple clusters simultaneously.
|
||||
|
||||
Be careful not to have multiple cluster connections with overlapping
|
||||
|
@ -704,11 +704,11 @@ specified. The following shows all the available configuration options
|
|||
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
|
||||
ActiveMQ will *not* forward messages to other nodes if there are no
|
||||
Apache 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 ActiveMQ will only forward messages
|
||||
If this is set to `false` then Apache 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
|
||||
|
@ -718,17 +718,17 @@ specified. The following shows all the available configuration options
|
|||
|
||||
- `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. ActiveMQ can be
|
||||
directly connected to it via a cluster connection. Apache ActiveMQ can be
|
||||
configured to also load balance messages to nodes which might be
|
||||
connected to it only indirectly with other ActiveMQ servers as
|
||||
connected to it only indirectly with other Apache ActiveMQ servers as
|
||||
intermediates in a chain.
|
||||
|
||||
This allows ActiveMQ to be configured in more complex topologies and
|
||||
This allows Apache 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 ActiveMQ serves which are directly
|
||||
are only load balanced to other Apache ActiveMQ serves which are directly
|
||||
connected to this server. This parameter is optional.
|
||||
|
||||
- `confirmation-window-size`. The size (in bytes) of the window used
|
||||
|
@ -770,7 +770,7 @@ connection has been made.
|
|||
### Cluster User Credentials
|
||||
|
||||
When creating connections between nodes of a cluster to form a cluster
|
||||
connection, ActiveMQ uses a cluster user and cluster password which is
|
||||
connection, Apache ActiveMQ uses a cluster user and cluster password which is
|
||||
defined in `activemq-configuration.xml`:
|
||||
|
||||
<cluster-user>ACTIVEMQ.CLUSTER.ADMIN.USER</cluster-user>
|
||||
|
@ -780,18 +780,18 @@ defined in `activemq-configuration.xml`:
|
|||
>
|
||||
> 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, ActiveMQ
|
||||
> the default values. If they are not changed from the default, Apache ActiveMQ
|
||||
> will detect this and pester you with a warning on every start-up.
|
||||
|
||||
## Client-Side Load balancing
|
||||
|
||||
With ActiveMQ client-side load balancing, subsequent sessions created
|
||||
With Apache 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. ActiveMQ provides four out-of-the-box load balancing
|
||||
configurable. Apache 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
|
||||
|
@ -908,7 +908,7 @@ consumers on the queue the message won't get consumed and we have a
|
|||
*starvation* situation.
|
||||
|
||||
This is where message redistribution comes in. With message
|
||||
redistribution ActiveMQ can be configured to automatically
|
||||
redistribution Apache 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.
|
||||
|
||||
|
@ -937,7 +937,7 @@ with "jms.", so the above would enable instant (no delay) redistribution
|
|||
for all JMS queues and topic subscriptions.
|
||||
|
||||
The attribute `match` can be an exact match or it can be a string that
|
||||
conforms to the ActiveMQ wildcard syntax (described in [Wildcard Syntax](wildcard-syntax.md)).
|
||||
conforms to the Apache ActiveMQ wildcard syntax (described in [Wildcard Syntax](wildcard-syntax.md)).
|
||||
|
||||
The element `redistribution-delay` defines the delay in milliseconds
|
||||
after the last consumer is closed on a queue before redistributing
|
||||
|
@ -953,7 +953,7 @@ redistribute immediately since the new consumer will arrive shortly.
|
|||
|
||||
## Cluster topologies
|
||||
|
||||
ActiveMQ clusters can be connected together in many different
|
||||
Apache ActiveMQ clusters can be connected together in many different
|
||||
topologies, let's consider the two most common ones here
|
||||
|
||||
### Symmetric cluster
|
||||
|
@ -1012,13 +1012,13 @@ which does have consumers.
|
|||
|
||||
### Scaling Down
|
||||
|
||||
ActiveMQ supports scaling down a cluster with no message loss (even for
|
||||
Apache 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. ActiveMQ can be configured to do
|
||||
them to another node in the cluster. Apache ActiveMQ can be configured to do
|
||||
just that.
|
||||
|
||||
The simplest way to enable this behavior is to set `scale-down` to
|
||||
|
|
|
@ -1800,21 +1800,21 @@ element is used by the server side JMS service to load JMS Queues, Topics
|
|||
Using Masked Passwords in Configuration Files
|
||||
---------------------------------------------
|
||||
|
||||
By default all passwords in ActiveMQ server's configuration files are in
|
||||
By default all passwords in Apache 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.
|
||||
|
||||
ActiveMQ can be configured to use 'masked' passwords in its
|
||||
Apache 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 ActiveMQ loads a masked
|
||||
files with the new masked password. When Apache ActiveMQ loads a masked
|
||||
password, it uses a suitable 'decoder' to decode it into real password.
|
||||
|
||||
ActiveMQ provides a default password encoder and decoder. Optionally
|
||||
Apache ActiveMQ provides a default password encoder and decoder. Optionally
|
||||
users can use or implement their own encoder and decoder for masking the
|
||||
passwords.
|
||||
|
||||
|
@ -1845,7 +1845,7 @@ 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, ActiveMQ will
|
||||
When a Connector or Acceptor configuration is initialised, Apache 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
|
||||
|
@ -1885,7 +1885,7 @@ example 2
|
|||
<mask-password>true</mask-password>
|
||||
<cluster-password>80cf731af62c290</cluster-password>
|
||||
|
||||
This indicates the cluster password is a masked value and ActiveMQ will
|
||||
This indicates the cluster password is a masked value and Apache 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.
|
||||
|
@ -1909,7 +1909,7 @@ followed by key/value pairs, separated by semi-colons. For example:
|
|||
\<property name="useMaskedPassword"\>true\</property\>
|
||||
\<property
|
||||
name="passwordCodec"\>com.foo.FooDecoder;key=value\</property\>
|
||||
ActiveMQ will load this property and initialize the class with a
|
||||
Apache 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.
|
||||
|
||||
|
@ -1944,7 +1944,7 @@ will have to be in masked form.
|
|||
|
||||
### Masking passwords in activemq-users.properties
|
||||
|
||||
ActiveMQ's built-in security manager uses plain properties files
|
||||
Apache ActiveMQ's built-in security manager uses plain properties files
|
||||
where the user passwords are specified in plaintext forms by default. To
|
||||
mask those parameters the following two properties need to be set
|
||||
in the 'bootstrap.xml' file.
|
||||
|
@ -1961,7 +1961,7 @@ Bridges. Example:
|
|||
<mask-password>true</mask-password>
|
||||
<password-codec>org.apache.activemq.utils.DefaultSensitiveStringCodec;key=hello world</password-codec>
|
||||
|
||||
When so configured, the ActiveMQ security manager will initialize a
|
||||
When so configured, the Apache 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.
|
||||
|
@ -1974,7 +1974,7 @@ 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 ActiveMQ provides a default built-in Decoder.
|
||||
For user's convenience Apache ActiveMQ provides a default built-in Decoder.
|
||||
However a user can if they so wish implement their own.
|
||||
|
||||
#### The built-in Decoder
|
||||
|
@ -1998,7 +1998,7 @@ Just copy "80cf731af62c290" and replace your plaintext password with it.
|
|||
#### 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 ActiveMQ's classpath and configure
|
||||
Simply make sure the decoder is in Apache ActiveMQ's classpath and configure
|
||||
the server to use it as follows:
|
||||
|
||||
<password-codec>com.foo.SomeDecoder;key1=value1;key2=value2</password-codec>
|
||||
|
@ -2014,7 +2014,7 @@ Then configure your cluster-password like this:
|
|||
<mask-password>true</mask-password>
|
||||
<cluster-password>masked_password</cluster-password>
|
||||
|
||||
When ActiveMQ reads the cluster-password it will initialize the
|
||||
When Apache 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.
|
||||
|
||||
|
@ -2050,4 +2050,4 @@ need String type. So a new decoder would be defined like
|
|||
}
|
||||
|
||||
Last but not least, once you get your own decoder, please add it to the
|
||||
classpath. Otherwise ActiveMQ will fail to load it!
|
||||
classpath. Otherwise Apache ActiveMQ will fail to load it!
|
||||
|
|
|
@ -1,11 +1,11 @@
|
|||
# Configuring the Transport
|
||||
|
||||
In this chapter we'll describe the concepts required for understanding
|
||||
ActiveMQ transports and where and how they're configured.
|
||||
Apache ActiveMQ transports and where and how they're configured.
|
||||
|
||||
## Understanding Acceptors
|
||||
|
||||
One of the most important concepts in ActiveMQ transports is the
|
||||
One of the most important concepts in Apache ActiveMQ transports is the
|
||||
*acceptor*. Let's dive straight in and take a look at an acceptor
|
||||
defined in xml in the configuration file `activemq-configuration.xml`.
|
||||
|
||||
|
@ -18,7 +18,7 @@ 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
|
||||
ActiveMQ server.
|
||||
Apache ActiveMQ server.
|
||||
|
||||
In the above example we're defining an acceptor that uses
|
||||
[Netty](http://netty.io/) to listen for connections at port
|
||||
|
@ -139,7 +139,7 @@ etc
|
|||
|
||||
## Configuring the Netty transport
|
||||
|
||||
Out of the box, ActiveMQ currently uses
|
||||
Out of the box, Apache ActiveMQ currently uses
|
||||
[Netty](http://netty.io/), a high performance low level
|
||||
network library.
|
||||
|
||||
|
@ -151,9 +151,9 @@ We believe this caters for the vast majority of transport requirements.
|
|||
|
||||
## Single Port Support
|
||||
|
||||
ActiveMQ 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
|
||||
Apache ActiveMQ supports using a single port for all
|
||||
protocols, Apache ActiveMQ will automatically detect which protocol is being
|
||||
used CORE, AMQP, STOMP or OPENWIRE and use the appropriate Apache ActiveMQ
|
||||
handler. It will also detect whether protocols such as HTTP or Web
|
||||
Sockets are being used and also use the appropriate decoders
|
||||
|
||||
|
@ -242,7 +242,7 @@ Netty for simple TCP:
|
|||
TCP receive buffer in bytes. The default value for this property is
|
||||
`32768` bytes (32KiB).
|
||||
|
||||
- `batchDelay`. Before writing packets to the transport, ActiveMQ can
|
||||
- `batchDelay`. Before writing packets to the transport, Apache ActiveMQ can
|
||||
be configured to batch up writes for a maximum of `batchDelay`
|
||||
milliseconds. This can increase overall throughput for very small
|
||||
messages. It does so at the expense of an increase in average
|
||||
|
@ -261,7 +261,7 @@ Netty for simple TCP:
|
|||
throughput set `directDeliver` to `false
|
||||
`.
|
||||
|
||||
- `nioRemotingThreads`. When configured to use NIO, ActiveMQ will,
|
||||
- `nioRemotingThreads`. When configured to use NIO, Apache 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
|
||||
|
@ -399,7 +399,7 @@ Netty HTTP uses the same properties as Netty TCP but adds the following
|
|||
additional properties:
|
||||
|
||||
- `httpEnabled`. This is now no longer needed as of version 2.4. With
|
||||
single port support ActiveMQ will now automatically detect if http
|
||||
single port support Apache ActiveMQ will now automatically detect if http
|
||||
is being used and configure itself.
|
||||
|
||||
- `httpClientIdleTime`. How long a client can be idle before
|
||||
|
|
|
@ -1,12 +1,12 @@
|
|||
# Detecting Dead Connections
|
||||
|
||||
In this section we will discuss connection time-to-live (TTL) and
|
||||
explain how ActiveMQ deals with crashed clients and clients which have
|
||||
explain how Apache 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 ActiveMQ client application exits it is considered good
|
||||
Before an Apache ActiveMQ client application exits it is considered good
|
||||
practice that it should close its resources in a controlled manner,
|
||||
using a `finally` block.
|
||||
|
||||
|
@ -81,12 +81,12 @@ 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.
|
||||
ActiveMQ supports client reconnection, so we don't want to clean up
|
||||
Apache 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.
|
||||
|
||||
ActiveMQ makes all of this configurable. For each `ClientSessionFactory`
|
||||
Apache 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" packets
|
||||
|
@ -120,7 +120,7 @@ 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, ActiveMQ will detect this at garbage collection
|
||||
If you fail to do so, Apache 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):
|
||||
|
@ -132,7 +132,7 @@ session):
|
|||
at org.apache.activemq.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:83)
|
||||
at org.acme.yourproject.YourClass (YourClass.java:666)
|
||||
|
||||
ActiveMQ will then close the connection / client session for you.
|
||||
Apache 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
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
# 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 ActiveMQ
|
||||
forward them to a target address, typically on a different Apache ActiveMQ
|
||||
server.
|
||||
|
||||
The source and target servers do not have to be in the same cluster
|
||||
|
@ -14,9 +14,9 @@ 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 ActiveMQ
|
||||
In summary, bridges are a way to reliably connect two separate Apache ActiveMQ
|
||||
servers together. With a core bridge both source and target servers must
|
||||
be ActiveMQ servers.
|
||||
be Apache 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
|
||||
|
@ -27,7 +27,7 @@ server. They do this by using duplicate detection (described in [Duplicate Detec
|
|||
> Although they have similar function, don't confuse core bridges with
|
||||
> JMS bridges!
|
||||
>
|
||||
> Core bridges are for linking a ActiveMQ node with another ActiveMQ
|
||||
> Core bridges are for linking an Apache ActiveMQ node with another Apache 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
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Diverting and Splitting Message Flows
|
||||
|
||||
ActiveMQ allows you to configure objects called *diverts* with some
|
||||
Apache ActiveMQ allows you to configure objects called *diverts* with some
|
||||
simple server configuration.
|
||||
|
||||
Diverts allow you to transparently divert messages routed to one address
|
||||
|
|
|
@ -1,9 +1,9 @@
|
|||
# Duplicate Message Detection
|
||||
|
||||
ActiveMQ includes powerful automatic duplicate message detection,
|
||||
Apache 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 ActiveMQ uses it and how
|
||||
will explain what duplicate detection is, how Apache ActiveMQ uses it and how
|
||||
and where to configure it.
|
||||
|
||||
When sending messages from a client to a server, or indeed from a server
|
||||
|
@ -34,7 +34,7 @@ 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 ActiveMQ provides automatic duplicate messages
|
||||
To solve these issues Apache ActiveMQ provides automatic duplicate messages
|
||||
detection for messages sent to addresses.
|
||||
|
||||
## Using Duplicate Detection for Message Sending
|
||||
|
|
|
@ -1,31 +1,31 @@
|
|||
# Embedding ActiveMQ
|
||||
# Embedding Apache ActiveMQ
|
||||
|
||||
ActiveMQ is designed as set of simple Plain Old Java Objects (POJOs).
|
||||
This means ActiveMQ can be instantiated and run in any dependency
|
||||
Apache ActiveMQ is designed as set of simple Plain Old Java Objects (POJOs).
|
||||
This means Apache ActiveMQ can be instantiated and run in any dependency
|
||||
injection framework such as Spring or Google Guice. It also means that if you have an application that could use
|
||||
messaging functionality internally, then it can *directly instantiate*
|
||||
ActiveMQ clients and servers in its own application code to perform that
|
||||
functionality. We call this *embedding* ActiveMQ.
|
||||
Apache ActiveMQ clients and servers in its own application code to perform that
|
||||
functionality. We call this *embedding* Apache 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 ActiveMQ can be done in very few easy steps. Instantiate the
|
||||
Embedding Apache ActiveMQ can be done in very few easy steps. Instantiate the
|
||||
configuration object, instantiate the server, start it, and you have a
|
||||
ActiveMQ running in your virtual machine. It's as simple and easy as
|
||||
Apache ActiveMQ running in your virtual machine. It's as simple and easy as
|
||||
that.
|
||||
|
||||
## Simple Config File Embedding
|
||||
|
||||
The simplest way to embed ActiveMQ is to use the embedded wrapper
|
||||
classes and configure ActiveMQ through its configuration files. There
|
||||
The simplest way to embed Apache ActiveMQ is to use the embedded wrapper
|
||||
classes and configure Apache ActiveMQ through its configuration files. There
|
||||
are two different helper classes for this depending on whether your
|
||||
using the ActiveMQ Core API or JMS.
|
||||
using the Apache ActiveMQ Core API or JMS.
|
||||
|
||||
## Core API Only
|
||||
|
||||
For instantiating a core ActiveMQ Server only, the steps are pretty
|
||||
For instantiating a core Apache ActiveMQ Server only, the steps are pretty
|
||||
simple. The example requires that you have defined a configuration file
|
||||
`activemq-configuration.xml` in your classpath:
|
||||
|
||||
|
@ -102,10 +102,10 @@ javadocs for this class for more details on other config options.
|
|||
## POJO instantiation - Embedding Programmatically
|
||||
|
||||
You can follow this step-by-step guide to programmatically embed the
|
||||
core, non-JMS ActiveMQ Server instance:
|
||||
core, non-JMS Apache ActiveMQ Server instance:
|
||||
|
||||
Create the configuration object - this contains configuration
|
||||
information for a ActiveMQ instance. The setter methods of this class
|
||||
information for an Apache ActiveMQ instance. The setter methods of this class
|
||||
allow you to programmatically set configuration options as describe in
|
||||
the [Server Configuration](configuration-index.md) section.
|
||||
|
||||
|
@ -158,7 +158,7 @@ then set the JmsConfiguration property of the EmbeddedJMS class. Here is
|
|||
an example of this:
|
||||
|
||||
``` java
|
||||
// Step 1. Create ActiveMQ core configuration, and set the properties accordingly
|
||||
// Step 1. Create Apache ActiveMQ core configuration, and set the properties accordingly
|
||||
Configuration configuration = new ConfigurationImpl();
|
||||
configuration.setPersistenceEnabled(false);
|
||||
configuration.setSecurityEnabled(false);
|
||||
|
@ -176,20 +176,20 @@ 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 ActiveMQ core server and the JMS configuration
|
||||
// Step 5. Start the JMS Server using the Apache ActiveMQ core server and the JMS configuration
|
||||
EmbeddedJMS jmsServer = new EmbeddedJMS();
|
||||
jmsServer.setConfiguration(configuration);
|
||||
jmsServer.setJmsConfiguration(jmsConfig);
|
||||
jmsServer.start();
|
||||
```
|
||||
|
||||
Please see the examples for an example which shows how to setup and run ActiveMQ
|
||||
Please see the examples for an example which shows how to setup and run Apache ActiveMQ
|
||||
embedded with JMS.
|
||||
|
||||
## Dependency Frameworks
|
||||
|
||||
You may also choose to use a dependency injection framework such as
|
||||
The Spring Framework. See [Spring Integration](spring-integration.md) for more details on
|
||||
Spring and ActiveMQ.
|
||||
Spring and Apache ActiveMQ.
|
||||
|
||||
ActiveMQ standalone uses [Airline](https://github.com/airlift/airline) to bootstrap.
|
||||
Apache ActiveMQ standalone uses [Airline](https://github.com/airlift/airline) to bootstrap.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
Examples
|
||||
========
|
||||
|
||||
The ActiveMQ distribution comes with over 70 run out-of-the-box examples
|
||||
The Apache ActiveMQ distribution comes with over 90 run out-of-the-box examples
|
||||
demonstrating many of the features.
|
||||
|
||||
The examples are available in the distribution, in the `examples`
|
||||
|
@ -39,11 +39,11 @@ Applet.
|
|||
Application-Layer Failover
|
||||
--------------------------
|
||||
|
||||
ActiveMQ also supports Application-Layer failover, useful in the case
|
||||
Apache 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 ActiveMQ which will be called by ActiveMQ
|
||||
a JMS `ExceptionListener` with Apache ActiveMQ which will be called by Apache ActiveMQ
|
||||
in the event that connection failure is detected.
|
||||
|
||||
The code in the `ExceptionListener` then recreates the JMS connection,
|
||||
|
@ -64,7 +64,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 ActiveMQ
|
||||
Core bridges are used to create message flows between any two Apache 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.
|
||||
|
@ -73,7 +73,7 @@ Browser
|
|||
-------
|
||||
|
||||
The `browser` example shows you how to use a JMS `QueueBrowser` with
|
||||
ActiveMQ.
|
||||
Apache ActiveMQ.
|
||||
|
||||
Queues are a standard part of JMS, please consult the JMS 1.1
|
||||
specification for full details.
|
||||
|
@ -99,7 +99,7 @@ Client-Side Load-Balancing
|
|||
|
||||
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 ActiveMQ does
|
||||
of the cluster. In other words it demonstrates how Apache ActiveMQ does
|
||||
client-side load-balancing of sessions across the cluster.
|
||||
|
||||
Clustered Durable Subscription
|
||||
|
@ -169,11 +169,11 @@ and we verify that both subscribers receive all the sent messages.
|
|||
Message Consumer Rate Limiting
|
||||
------------------------------
|
||||
|
||||
With ActiveMQ you can specify a maximum consume rate at which a JMS
|
||||
With Apache 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 ActiveMQ will ensure that messages are
|
||||
If this value is specified then Apache ActiveMQ will ensure that messages are
|
||||
never consumed at a rate higher than the specified rate. This is a form
|
||||
of consumer throttling.
|
||||
|
||||
|
@ -197,7 +197,7 @@ can be consumed for further investigation.
|
|||
Delayed Redelivery
|
||||
------------------
|
||||
|
||||
The `delayed-redelivery` example demonstrates how ActiveMQ can be
|
||||
The `delayed-redelivery` example demonstrates how Apache ActiveMQ can be
|
||||
configured to provide a delayed redelivery in the case a message needs
|
||||
to be redelivered.
|
||||
|
||||
|
@ -210,7 +210,7 @@ succession, using up valuable CPU and network resources.
|
|||
Divert
|
||||
------
|
||||
|
||||
ActiveMQ diverts allow messages to be transparently "diverted" or copied
|
||||
Apache 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.
|
||||
|
||||
|
@ -218,7 +218,7 @@ Durable Subscription
|
|||
--------------------
|
||||
|
||||
The `durable-subscription` example shows you how to use a durable
|
||||
subscription with ActiveMQ. Durable subscriptions are a standard part of
|
||||
subscription with Apache 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
|
||||
|
@ -239,7 +239,7 @@ Embedded Simple
|
|||
---------------
|
||||
|
||||
The `embedded` example shows how to embed JMS within your own code using
|
||||
regular ActiveMQ XML files.
|
||||
regular Apache ActiveMQ XML files.
|
||||
|
||||
Message Expiration
|
||||
------------------
|
||||
|
@ -250,12 +250,12 @@ limited 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).
|
||||
|
||||
ActiveMQ can assign an expiry address to a given queue so that when
|
||||
Apache 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.
|
||||
|
||||
ActiveMQ Resource Adapter example
|
||||
Apache ActiveMQ Resource Adapter example
|
||||
---------------------------------
|
||||
|
||||
This examples shows how to build the activemq resource adapters a rar
|
||||
|
@ -264,7 +264,7 @@ for deployment in other Application Server's
|
|||
HTTP Transport
|
||||
--------------
|
||||
|
||||
The `http-transport` example shows you how to configure ActiveMQ to use
|
||||
The `http-transport` example shows you how to configure Apache ActiveMQ to use
|
||||
the HTTP protocol as its transport layer.
|
||||
|
||||
Instantiate JMS Objects Directly
|
||||
|
@ -275,22 +275,22 @@ instances are looked up from JNDI 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 ActiveMQ also supports the direct instantiation of
|
||||
come to the rescue Apache 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
|
||||
-----------
|
||||
|
||||
ActiveMQ allows an application to use an interceptor to hook into the
|
||||
Apache ActiveMQ allows an application to use an interceptor to hook into the
|
||||
messaging system. Interceptors allow you to handle various message
|
||||
events in ActiveMQ.
|
||||
events in Apache ActiveMQ.
|
||||
|
||||
JAAS
|
||||
----
|
||||
|
||||
The `jaas` example shows you how to configure ActiveMQ to use JAAS for
|
||||
security. ActiveMQ can leverage JAAS to delegate user authentication and
|
||||
The `jaas` example shows you how to configure Apache ActiveMQ to use JAAS for
|
||||
security. Apache ActiveMQ can leverage JAAS to delegate user authentication and
|
||||
authorization to existing security infrastructure.
|
||||
|
||||
JMS Auto Closable
|
||||
|
@ -304,20 +304,20 @@ JMS Completion Listener
|
|||
-----------------------
|
||||
|
||||
The `jms-completion-listener` example shows how to send a message
|
||||
asynchronously to ActiveMQ and use a CompletionListener to be notified
|
||||
asynchronously to Apache 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 ActiveMQ servers.
|
||||
standalone Apache ActiveMQ servers.
|
||||
|
||||
JMS Context
|
||||
-----------
|
||||
|
||||
The `jms-context` example shows how to send and receive a message to a
|
||||
JMS Queue using ActiveMQ by using a JMS Context.
|
||||
JMS Queue using Apache 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.
|
||||
|
@ -333,19 +333,19 @@ so you can share the load across different threads and connections.
|
|||
JMX Management
|
||||
--------------
|
||||
|
||||
The `jmx` example shows how to manage ActiveMQ using JMX.
|
||||
The `jmx` example shows how to manage Apache ActiveMQ using JMX.
|
||||
|
||||
Large Message
|
||||
-------------
|
||||
|
||||
The `large-message` example shows you how to send and receive very large
|
||||
messages with ActiveMQ. ActiveMQ supports the sending and receiving of
|
||||
messages with Apache ActiveMQ. Apache 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 ActiveMQ doesn't just do a simple socket stream
|
||||
restart. In other words Apache ActiveMQ doesn't just do a simple socket stream
|
||||
from the sender to the consumer.
|
||||
|
||||
Last-Value Queue
|
||||
|
@ -363,14 +363,14 @@ are only interested by the latest price for a particular stock.
|
|||
Management
|
||||
----------
|
||||
|
||||
The `management` example shows how to manage ActiveMQ using JMS Messages
|
||||
The `management` example shows how to manage Apache ActiveMQ using JMS Messages
|
||||
to invoke management operations on the server.
|
||||
|
||||
Management Notification
|
||||
-----------------------
|
||||
|
||||
The `management-notification` example shows how to receive management
|
||||
notifications from ActiveMQ using JMS messages. ActiveMQ servers emit
|
||||
notifications from Apache ActiveMQ using JMS messages. Apache ActiveMQ servers emit
|
||||
management notifications when events of interest occur (consumers are
|
||||
created or closed, addresses are created or deleted, security
|
||||
authentication fails, etc.).
|
||||
|
@ -385,7 +385,7 @@ Message Group
|
|||
-------------
|
||||
|
||||
The `message-group` example shows you how to configure and use message
|
||||
groups with ActiveMQ. Message groups allow you to pin messages so they
|
||||
groups with Apache 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:
|
||||
|
||||
|
@ -399,7 +399,7 @@ Message Group
|
|||
-------------
|
||||
|
||||
The `message-group2` example shows you how to configure and use message
|
||||
groups with ActiveMQ via a connection factory.
|
||||
groups with Apache ActiveMQ via a connection factory.
|
||||
|
||||
Message Priority
|
||||
----------------
|
||||
|
@ -434,19 +434,19 @@ backups but forcing failover back to the original live server
|
|||
No Consumer Buffering
|
||||
---------------------
|
||||
|
||||
By default, ActiveMQ consumers buffer messages from the server in a
|
||||
By default, Apache 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 ActiveMQ client would have to
|
||||
`MessageListener onMessage()` method, the Apache 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, ActiveMQ pre-fetches messages into a
|
||||
performance. Therefore, by default, Apache ActiveMQ pre-fetches messages into a
|
||||
buffer on each consumer.
|
||||
|
||||
In some case buffering is not desirable, and ActiveMQ allows it to be
|
||||
In some case buffering is not desirable, and Apache ActiveMQ allows it to be
|
||||
switched off. This example demonstrates that.
|
||||
|
||||
Non-Transaction Failover With Server Data Replication
|
||||
|
@ -457,7 +457,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.
|
||||
|
||||
ActiveMQ implements failover of client connections between live and
|
||||
Apache 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
|
||||
|
@ -468,13 +468,13 @@ messages will be lost or delivered twice.
|
|||
OpenWire
|
||||
--------
|
||||
|
||||
The `Openwire` example shows how to configure a ActiveMQ server to
|
||||
communicate with an ActiveMQ JMS client that uses open-wire protocol.
|
||||
The `Openwire` example shows how to configure an Apache ActiveMQ server to
|
||||
communicate with an Apache ActiveMQ JMS client that uses open-wire protocol.
|
||||
|
||||
Paging
|
||||
------
|
||||
|
||||
The `paging` example shows how ActiveMQ can support huge queues even
|
||||
The `paging` example shows how Apache 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.
|
||||
|
||||
|
@ -490,27 +490,27 @@ 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 ActiveMQ allows this with an extra
|
||||
client. This example demonstrates how Apache ActiveMQ allows this with an extra
|
||||
acknowledgement mode.
|
||||
|
||||
Message Producer Rate Limiting
|
||||
------------------------------
|
||||
|
||||
The `producer-rte-limit` example demonstrates how, with ActiveMQ, you
|
||||
The `producer-rte-limit` example demonstrates how, with Apache ActiveMQ, you
|
||||
can specify a maximum send rate at which a JMS message producer will
|
||||
send messages.
|
||||
|
||||
Proton Qpid
|
||||
-----------
|
||||
|
||||
ActiveMQ can be configured to accept requests from any AMQP client that
|
||||
Apache 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
|
||||
-----------
|
||||
|
||||
ActiveMQ can be configured to accept requests from any AMQP client that
|
||||
Apache 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
|
||||
|
||||
|
@ -542,7 +542,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. ActiveMQ can be configured
|
||||
notifying any user ExceptionListener objects. Apache ActiveMQ can be configured
|
||||
to automatically retry the connection, and reattach to the server when
|
||||
it becomes available again across the network.
|
||||
|
||||
|
@ -581,25 +581,25 @@ A simple example showing the JMS request-response pattern.
|
|||
Rest example
|
||||
------------
|
||||
|
||||
An example showing how to use the ActiveMQ Rest API
|
||||
An example showing how to use the Apache ActiveMQ Rest API
|
||||
|
||||
Scheduled Message
|
||||
-----------------
|
||||
|
||||
The `scheduled-message` example shows you how to send a scheduled
|
||||
message to a JMS Queue with ActiveMQ. Scheduled messages won't get
|
||||
message to a JMS Queue with Apache 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 ActiveMQ.
|
||||
security with Apache ActiveMQ.
|
||||
|
||||
Send Acknowledgements
|
||||
---------------------
|
||||
|
||||
The `send-acknowledgements` example shows you how to use ActiveMQ's
|
||||
The `send-acknowledgements` example shows you how to use Apache 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.
|
||||
|
@ -607,49 +607,49 @@ processed in a separate stream to the sent messages.
|
|||
Spring Integration
|
||||
------------------
|
||||
|
||||
This example shows how to use embedded JMS using ActiveMQ's Spring
|
||||
This example shows how to use embedded JMS using Apache ActiveMQ's Spring
|
||||
integration.
|
||||
|
||||
SSL Transport
|
||||
-------------
|
||||
|
||||
The `ssl-enabled` shows you how to configure SSL with ActiveMQ to send
|
||||
The `ssl-enabled` shows you how to configure SSL with Apache ActiveMQ to send
|
||||
and receive message.
|
||||
|
||||
Static Message Selector
|
||||
-----------------------
|
||||
|
||||
The `static-selector` example shows you how to configure a ActiveMQ core
|
||||
The `static-selector` example shows you how to configure an Apache ActiveMQ core
|
||||
queue with static message selectors (filters).
|
||||
|
||||
Static Message Selector Using JMS
|
||||
---------------------------------
|
||||
|
||||
The `static-selector-jms` example shows you how to configure a ActiveMQ
|
||||
The `static-selector-jms` example shows you how to configure an Apache ActiveMQ
|
||||
queue with static message selectors (filters) using JMS.
|
||||
|
||||
Stomp
|
||||
-----
|
||||
|
||||
The `stomp` example shows you how to configure a ActiveMQ server to send
|
||||
The `stomp` example shows you how to configure an Apache ActiveMQ server to send
|
||||
and receive Stomp messages.
|
||||
|
||||
Stomp1.1
|
||||
--------
|
||||
|
||||
The `stomp` example shows you how to configure a ActiveMQ server to send
|
||||
The `stomp` example shows you how to configure an Apache 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 ActiveMQ server to send
|
||||
The `stomp` example shows you how to configure an Apache 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 ActiveMQ
|
||||
The `stomp-websockets` example shows you how to configure an Apache ActiveMQ
|
||||
server to send and receive Stomp messages directly from Web browsers
|
||||
(provided they support Web Sockets).
|
||||
|
||||
|
@ -657,9 +657,9 @@ Symmetric Cluster
|
|||
-----------------
|
||||
|
||||
The `symmetric-cluster` example demonstrates a symmetric cluster set-up
|
||||
with ActiveMQ.
|
||||
with Apache ActiveMQ.
|
||||
|
||||
ActiveMQ has extremely flexible clustering which allows you to set-up
|
||||
Apache 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.
|
||||
|
@ -681,7 +681,7 @@ A simple example demonstrating a JMS topic.
|
|||
Topic Hierarchy
|
||||
---------------
|
||||
|
||||
ActiveMQ supports topic hierarchies. With a topic hierarchy you can
|
||||
Apache 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.
|
||||
|
||||
|
@ -689,7 +689,7 @@ Topic Selector 1
|
|||
----------------
|
||||
|
||||
The `topic-selector-example1` example shows you how to send message to a
|
||||
JMS Topic, and subscribe them using selectors with ActiveMQ.
|
||||
JMS Topic, and subscribe them using selectors with Apache ActiveMQ.
|
||||
|
||||
Topic Selector 2
|
||||
----------------
|
||||
|
@ -705,7 +705,7 @@ 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.
|
||||
|
||||
ActiveMQ implements failover of client connections between live and
|
||||
Apache 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 sessions are
|
||||
|
@ -722,13 +722,13 @@ Transactional Session
|
|||
---------------------
|
||||
|
||||
The `transactional` example shows you how to use a transactional Session
|
||||
with ActiveMQ.
|
||||
with Apache ActiveMQ.
|
||||
|
||||
XA Heuristic
|
||||
------------
|
||||
|
||||
The `xa-heuristic` example shows you how to make an XA heuristic
|
||||
decision through ActiveMQ Management Interface. A heuristic decision is
|
||||
decision through Apache ActiveMQ Management Interface. A heuristic decision is
|
||||
a unilateral decision to commit or rollback an XA transaction branch
|
||||
after it has been prepared.
|
||||
|
||||
|
@ -736,13 +736,13 @@ XA Receive
|
|||
----------
|
||||
|
||||
The `xa-receive` example shows you how message receiving behaves in an
|
||||
XA transaction in ActiveMQ.
|
||||
XA transaction in Apache ActiveMQ.
|
||||
|
||||
XA Send
|
||||
-------
|
||||
|
||||
The `xa-send` example shows you how message sending behaves in an XA
|
||||
transaction in ActiveMQ.
|
||||
transaction in Apache ActiveMQ.
|
||||
Core API Examples
|
||||
=================
|
||||
|
||||
|
@ -752,5 +752,5 @@ directory and type `ant`
|
|||
Embedded
|
||||
--------
|
||||
|
||||
The `embedded` example shows how to embed the ActiveMQ server within
|
||||
The `embedded` example shows how to embed the Apache ActiveMQ server within
|
||||
your own code.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Filter Expressions
|
||||
|
||||
ActiveMQ provides a powerful filter language based on a subset of the
|
||||
Apache 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
|
||||
|
@ -8,7 +8,7 @@ identifiers are different. For documentation on JMS selector syntax
|
|||
please the JMS javadoc for
|
||||
[javax.jms.Message](http://docs.oracle.com/javaee/6/api/javax/jms/Message.html).
|
||||
|
||||
Filter expressions are used in several places in ActiveMQ
|
||||
Filter expressions are used in several places in Apache ActiveMQ
|
||||
|
||||
- Predefined Queues. When pre-defining a queue, in
|
||||
`activemq-configuration.xml` in either the core or jms configuration a filter
|
||||
|
@ -24,9 +24,9 @@ Filter expressions are used in several places in ActiveMQ
|
|||
- Filter are also used programmatically when creating consumers,
|
||||
queues and in several places as described in [management](management.md).
|
||||
|
||||
There are some differences between JMS selector expressions and ActiveMQ
|
||||
There are some differences between JMS selector expressions and Apache ActiveMQ
|
||||
core filter expressions. Whereas JMS selector expressions operate on a
|
||||
JMS message, ActiveMQ core filter expressions operate on a core message.
|
||||
JMS message, Apache 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:
|
||||
|
|
|
@ -17,17 +17,17 @@ they cannot be processed in time.
|
|||
|
||||
## Window-Based Flow Control
|
||||
|
||||
By default, ActiveMQ consumers buffer messages from the server in a
|
||||
By default, Apache 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,
|
||||
ActiveMQ would have to go the server to request the next message. In
|
||||
Apache 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, ActiveMQ pre-fetches messages into a buffer on each
|
||||
To prevent this, Apache 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 `consumerWindowSize`
|
||||
parameter.
|
||||
|
@ -89,7 +89,7 @@ of 1MiB is fine in most cases.
|
|||
|
||||
### Using Core API
|
||||
|
||||
If ActiveMQ Core API is used, the consumer window size is specified by
|
||||
If Apache ActiveMQ Core API is used, the consumer window size is specified by
|
||||
`ServerLocator.setConsumerWindowSize()` method and some of the
|
||||
`ClientSession.createConsumer()` methods.
|
||||
|
||||
|
@ -108,7 +108,7 @@ If the connection factory is directly instantiated, the consumer window
|
|||
size is specified by `ActiveMQConnectionFactory.setConsumerWindowSize()`
|
||||
method.
|
||||
|
||||
Please see the examples for an example which shows how to configure ActiveMQ to
|
||||
Please see the examples for an example which shows how to configure Apache ActiveMQ to
|
||||
prevent consumer buffering when dealing with slow consumers.
|
||||
|
||||
## Rate limited flow control
|
||||
|
@ -127,7 +127,7 @@ Please see ? for a working example of limiting consumer rate.
|
|||
|
||||
### Using Core API
|
||||
|
||||
If the ActiveMQ core API is being used the rate can be set via the
|
||||
If the Apache 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.
|
||||
|
||||
|
@ -158,12 +158,12 @@ prevent consumer buffering when dealing with slow consumers.
|
|||
|
||||
## Producer flow control
|
||||
|
||||
ActiveMQ also can limit the amount of data sent from a client to a
|
||||
Apache 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, ActiveMQ
|
||||
In a similar way to consumer window based flow control, Apache 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.
|
||||
|
@ -180,7 +180,7 @@ prevents the remoting connection from getting overloaded.
|
|||
|
||||
#### Using Core API
|
||||
|
||||
If the ActiveMQ core API is being used, window size can be set via the
|
||||
If the Apache ActiveMQ core API is being used, window size can be set via the
|
||||
`ServerLocator.setProducerWindowSize(int producerWindowSize)` method.
|
||||
|
||||
#### Using JMS
|
||||
|
@ -260,8 +260,8 @@ control.
|
|||
|
||||
### Rate limited flow control
|
||||
|
||||
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
|
||||
Apache ActiveMQ also allows the rate a producer can emit message to be limited,
|
||||
in units of messages per second. By specifying such a rate, Apache ActiveMQ
|
||||
will ensure that producer never produces messages at a rate higher than
|
||||
that specified.
|
||||
|
||||
|
@ -274,7 +274,7 @@ Please see the ? for a working example of limiting producer rate.
|
|||
|
||||
#### Using Core API
|
||||
|
||||
If the ActiveMQ core API is being used the rate can be set via the
|
||||
If the Apache ActiveMQ core API is being used the rate can be set via the
|
||||
`ServerLocator.setProducerMaxRate(int producerMaxRate)` method or
|
||||
alternatively via some of the `ClientSession.createProducer()` methods.
|
||||
|
||||
|
|
|
@ -9,14 +9,14 @@ event of server failure so client applications can continue to operate*.
|
|||
|
||||
## Live - Backup Groups
|
||||
|
||||
ActiveMQ allows servers to be linked together as *live - backup* groups
|
||||
Apache 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 ActiveMQ clients
|
||||
Before failover, only the live server is serving the Apache 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
|
||||
|
@ -28,7 +28,7 @@ live server coming back up and automatically stop.
|
|||
|
||||
### HA Policies
|
||||
|
||||
ActiveMQ supports two different strategies for backing up a server
|
||||
Apache ActiveMQ supports two different strategies for backing up a server
|
||||
*shared store* and *replication*. Which is configured via the
|
||||
`ha-policy` configuration element.
|
||||
|
||||
|
@ -789,13 +789,13 @@ be high enough to deal with the time needed to scale down.
|
|||
|
||||
## Failover Modes
|
||||
|
||||
ActiveMQ defines two types of client failover:
|
||||
Apache ActiveMQ defines two types of client failover:
|
||||
|
||||
- Automatic client failover
|
||||
|
||||
- Application-level client failover
|
||||
|
||||
ActiveMQ also provides 100% transparent automatic reattachment of
|
||||
Apache 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 [Client Reconnection and Session Reattachment](client-reconnection.md)
|
||||
|
@ -807,14 +807,14 @@ knowledge of non persistent queues.
|
|||
|
||||
### Automatic Client Failover
|
||||
|
||||
ActiveMQ clients can be configured to receive knowledge of all live and
|
||||
Apache 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.
|
||||
|
||||
ActiveMQ clients detect connection failure when it has not received
|
||||
Apache 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 [Detecting Dead Connections](connection-ttl.md). If the client
|
||||
does not receive data in good time, it will assume the connection has
|
||||
|
@ -822,7 +822,7 @@ 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.
|
||||
|
||||
ActiveMQ clients can be configured to discover the list of live-backup
|
||||
Apache 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.
|
||||
|
@ -857,7 +857,7 @@ JMS sessions, please see ? and ?.
|
|||
|
||||
#### A Note on Server Replication
|
||||
|
||||
ActiveMQ does not replicate full server state between live and backup
|
||||
Apache 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
|
||||
|
@ -898,14 +898,14 @@ 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, ActiveMQ will unblock any blocking calls that were in
|
||||
To prevent this, Apache 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 ActiveMQ will
|
||||
the transaction will be automatically rolled back and Apache ActiveMQ will
|
||||
throw a `javax.jms.TransactionRolledBackException` (if using JMS), or a
|
||||
`ActiveMQException` with error code
|
||||
`ActiveMQException.TRANSACTION_ROLLED_BACK` if using the core API.
|
||||
|
@ -940,7 +940,7 @@ local 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.
|
||||
|
||||
ActiveMQ ships with a fully functioning example demonstrating how to do
|
||||
Apache 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
|
||||
|
@ -990,7 +990,7 @@ connection failure: `java.jms.ExceptionListener`. Please consult the JMS
|
|||
javadoc or any good JMS tutorial for more information on how to use
|
||||
this.
|
||||
|
||||
The ActiveMQ core API also provides a similar feature in the form of the
|
||||
The Apache 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
|
||||
|
@ -1037,7 +1037,7 @@ 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 ActiveMQ in the event that
|
||||
`ExceptionListener` will be called by Apache 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.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Intercepting Operations
|
||||
|
||||
ActiveMQ supports *interceptors* to intercept packets entering and
|
||||
Apache 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
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
## Stomp
|
||||
|
||||
[Stomp](http://stomp.github.com/) is a text-orientated wire protocol
|
||||
that allows Stomp clients to communicate with Stomp Brokers. ActiveMQ
|
||||
that allows Stomp clients to communicate with Stomp Brokers. Apache ActiveMQ
|
||||
now supports Stomp 1.0, 1.1 and 1.2.
|
||||
|
||||
Stomp clients are available for several languages and platforms making
|
||||
|
@ -11,16 +11,16 @@ it a good choice for interoperability.
|
|||
|
||||
## Native Stomp support
|
||||
|
||||
ActiveMQ provides native support for Stomp. To be able to send and
|
||||
Apache 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`:
|
||||
|
||||
<acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP</acceptor>
|
||||
|
||||
With this configuration, ActiveMQ will accept Stomp connections on the
|
||||
With this configuration, Apache 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 ActiveMQ server
|
||||
See the `stomp` example which shows how to configure an Apache ActiveMQ server
|
||||
with Stomp.
|
||||
|
||||
### Limitations
|
||||
|
@ -33,30 +33,30 @@ set).
|
|||
|
||||
#### Virtual Hosting
|
||||
|
||||
ActiveMQ currently doesn't support virtual hosting, which means the
|
||||
Apache ActiveMQ currently doesn't support virtual hosting, which means the
|
||||
'host' header in CONNECT fram will be ignored.
|
||||
|
||||
#### Heart-beating
|
||||
|
||||
ActiveMQ specifies a minimum value for both client and server heart-beat
|
||||
Apache 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.
|
||||
|
||||
### Mapping Stomp destinations to ActiveMQ addresses and queues
|
||||
### Mapping Stomp destinations to Apache 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 ActiveMQ, these destinations are mapped to *addresses* and *queues*.
|
||||
In Apache 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 ActiveMQ queue.
|
||||
`UNSUBSCRIBE` frame), the destination is mapped to an Apache ActiveMQ queue.
|
||||
|
||||
### STOMP and connection-ttl
|
||||
|
||||
|
@ -96,7 +96,7 @@ seconds.
|
|||
#### Using JMS destinations
|
||||
|
||||
As explained in [Mapping JMS Concepts to the Core API](jms-core-mapping.md),
|
||||
JMS destinations are also mapped to ActiveMQ
|
||||
JMS destinations are also mapped to Apache ActiveMQ
|
||||
addresses and queues. If you want to use Stomp to send messages to JMS
|
||||
destinations, the Stomp destinations must follow the same convention:
|
||||
|
||||
|
@ -123,10 +123,10 @@ destinations, the Stomp destinations must follow the same convention:
|
|||
|
||||
^@
|
||||
|
||||
#### Sending and consuming Stomp message from JMS or ActiveMQ Core API
|
||||
#### Sending and consuming Stomp message from JMS or Apache 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
|
||||
interoperate with JMS and Apache 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.
|
||||
|
||||
|
@ -147,7 +147,7 @@ header to determine the type of the message body (String or bytes).
|
|||
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. ActiveMQ Stomp provides a parameter to enable message ID on
|
||||
purpose. Apache 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 `stompEnableMessageId` to true. For example:
|
||||
|
||||
|
@ -167,15 +167,15 @@ default is `false`.
|
|||
#### Handling of Large Messages with Stomp
|
||||
|
||||
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, ActiveMQ provides a stomp
|
||||
size of Apache ActiveMQ server's internal buffer, causing unexpected errors. To
|
||||
prevent this situation from happening, Apache ActiveMQ provides a stomp
|
||||
configuration attribute `stompMinLargeMessageSize`. This attribute
|
||||
can be configured inside a stomp acceptor, as a parameter. For example:
|
||||
|
||||
<acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP;stompMinLargeMessageSize=10240</acceptor>
|
||||
|
||||
The type of this attribute is integer. When this attributed is
|
||||
configured, ActiveMQ server will check the size of the body of each
|
||||
configured, Apache 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
|
||||
`stompMinLargeMessageSize`, the message will be persisted as a large
|
||||
|
@ -190,16 +190,16 @@ sending it to stomp clients. The default value of
|
|||
|
||||
### Stomp Over Web Sockets
|
||||
|
||||
ActiveMQ also support Stomp over [Web
|
||||
Apache ActiveMQ also support Stomp over [Web
|
||||
Sockets](http://dev.w3.org/html5/websockets/). Modern web browser which
|
||||
support Web Sockets can send and receive Stomp messages from ActiveMQ.
|
||||
support Web Sockets can send and receive Stomp messages from Apache ActiveMQ.
|
||||
|
||||
To enable Stomp over Web Sockets, you must configure a `NettyAcceptor`
|
||||
with a `protocol` parameter set to `stomp_ws`:
|
||||
|
||||
<acceptor name="stomp-ws-acceptor">tcp://localhost:61614?protocols=STOMP_WS</acceptor>
|
||||
|
||||
With this configuration, ActiveMQ will accept Stomp connections over Web
|
||||
With this configuration, Apache 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.
|
||||
|
@ -209,7 +209,7 @@ available from [GitHub](http://github.com/jmesnil/stomp-websocket)
|
|||
(please see its [documentation](http://jmesnil.net/stomp-websocket/doc/)
|
||||
for a complete description).
|
||||
|
||||
The `stomp-websockets` example shows how to configure ActiveMQ server to
|
||||
The `stomp-websockets` example shows how to configure Apache ActiveMQ server to
|
||||
have web browsers and Java applications exchanges messages on a JMS
|
||||
topic.
|
||||
|
||||
|
@ -218,10 +218,10 @@ topic.
|
|||
[StompConnect](http://stomp.codehaus.org/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
|
||||
ActiveMQ into a Stomp Broker and use any of the available stomp clients.
|
||||
Apache 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 ActiveMQ server and make sure that
|
||||
To run StompConnect first start the Apache ActiveMQ server and make sure that
|
||||
it is using JNDI.
|
||||
|
||||
Stomp requires the file `jndi.properties` to be available on the
|
||||
|
@ -233,7 +233,7 @@ Configure any required JNDI resources in this file according to the
|
|||
documentation.
|
||||
|
||||
Make sure this file is in the classpath along with the StompConnect jar
|
||||
and the ActiveMQ jars and simply run `java org.codehaus.stomp.jms.Main`.
|
||||
and the Apache ActiveMQ jars and simply run `java org.codehaus.stomp.jms.Main`.
|
||||
|
||||
## REST
|
||||
|
||||
|
@ -241,7 +241,7 @@ Please see [Rest Interface](rest.md)
|
|||
|
||||
## AMQP
|
||||
|
||||
ActiveMQ supports the [AMQP
|
||||
Apache ActiveMQ supports the [AMQP
|
||||
1.0](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=amqp)
|
||||
specification. To enable AMQP you must configure a Netty Acceptor to
|
||||
receive AMQP clients, like so:
|
||||
|
@ -249,7 +249,7 @@ receive AMQP clients, like so:
|
|||
<acceptor name="stomp-acceptor">tcp://localhost:5672?protocols=AMQP</acceptor>
|
||||
|
||||
|
||||
ActiveMQ will then accept AMQP 1.0 clients on port 5672 which is the
|
||||
Apache 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
|
||||
|
@ -257,18 +257,18 @@ use the qpid Java and Ruby clients respectively
|
|||
|
||||
### AMQP and security
|
||||
|
||||
The ActiveMQ Server accepts AMQP SASL Authentication and will use this
|
||||
The Apache 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.
|
||||
use the normal Apache 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 ActiveMQ Broker. A link will
|
||||
source and a target, i.e. a client and the Apache 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
|
||||
the Broker a Sender will have its messages converted into an Apache ActiveMQ
|
||||
Message and forwarded to its destination or target. A Receiver will map
|
||||
onto a ActiveMQ Server Consumer and convert ActiveMQ messages back into
|
||||
onto an Apache ActiveMQ Server Consumer and convert Apache ActiveMQ messages back into
|
||||
AMQP messages before being delivered.
|
||||
|
||||
### AMQP and destinations
|
||||
|
@ -294,27 +294,27 @@ or committed via the coordinator.
|
|||
> **Note**
|
||||
>
|
||||
> AMQP allows the use of multiple transactions per session,
|
||||
> `amqp:multi-txns-per-ssn`, however in this version ActiveMQ will only
|
||||
> `amqp:multi-txns-per-ssn`, however in this version Apache ActiveMQ will only
|
||||
> support single transactions per session
|
||||
|
||||
## OpenWire
|
||||
|
||||
ActiveMQ now supports the
|
||||
Apache ActiveMQ now supports the
|
||||
[OpenWire](http://activemq.apache.org/openwire.html) protocol so that an
|
||||
ActiveMQ JMS client can talk directly to a ActiveMQ server. To enable
|
||||
Apache ActiveMQ JMS client can talk directly to an Apache ActiveMQ server. To enable
|
||||
OpenWire support you must configure a Netty Acceptor, like so:
|
||||
|
||||
<acceptor name="openwire-acceptor">tcp://localhost:61616?protocols=OPENWIRE</acceptor>
|
||||
|
||||
|
||||
The ActiveMQ server will then listens on port 61616 for incoming
|
||||
The Apache 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.
|
||||
The openwire configuration conforms to Apache ActiveMQ's "Single Port" feature.
|
||||
Please refer to [Configuring Single
|
||||
Port](#configuring-transports.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 ActiveMQ.
|
||||
Currently we support Apache ActiveMQ clients that using standard JMS APIs. In
|
||||
the future we will get more supports for some advanced, Apache ActiveMQ
|
||||
specific features into Apache ActiveMQ.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# The JMS Bridge
|
||||
|
||||
ActiveMQ includes a fully functional JMS message bridge.
|
||||
Apache 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
|
||||
|
@ -8,18 +8,18 @@ different server.
|
|||
|
||||
> *Notice:*
|
||||
> The JMS Bridge is not intended as a replacement for transformation and more expert systems such as Camel.
|
||||
> The JMS Bridge may be useful for fast transfers as this chapter covers, but keep in mind that more complex scenarios requiring transformations will require you to use a more advanced transformation system that will play on use cases that will go beyond ActiveMQ.
|
||||
> The JMS Bridge may be useful for fast transfers as this chapter covers, but keep in mind that more complex scenarios requiring transformations will require you to use a more advanced transformation system that will play on use cases that will go beyond Apache ActiveMQ.
|
||||
|
||||
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 ActiveMQ
|
||||
A bridge can be deployed as a standalone application, with Apache 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 ActiveMQ
|
||||
The bridge can also be used to bridge messages from other non Apache ActiveMQ
|
||||
JMS servers, as long as they are JMS 1.1 compliant.
|
||||
|
||||
> **Note**
|
||||
|
@ -27,7 +27,7 @@ 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 [Core Bidges](core-bridges.md)) is used to bridge any two
|
||||
> ActiveMQ instances and uses the core API. Always use a core bridge if
|
||||
> Apache 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* delivery guarantees without using XA.
|
||||
|
@ -193,7 +193,7 @@ by the parameters passed to its constructor.
|
|||
|
||||
The "transactionManager" property points to a JTA transaction manager
|
||||
implementation and should be set if you need to use the 'ONCE_AND_ONCE_ONLY'
|
||||
Quality of Service. ActiveMQ doesn't ship with such an implementation, but
|
||||
Quality of Service. Apache ActiveMQ doesn't ship with such an implementation, but
|
||||
if you are running within an Application Server you can inject the Transaction
|
||||
Manager that is shipped.
|
||||
|
||||
|
@ -204,7 +204,7 @@ the connection factory used to create the connection for the source or
|
|||
target server.
|
||||
|
||||
The configuration example above uses the default implementation provided
|
||||
by ActiveMQ that looks up the connection factory using JNDI. For other
|
||||
by Apache 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`.
|
||||
|
@ -215,7 +215,7 @@ Again, similarly, these are used to create or lookup up the
|
|||
destinations.
|
||||
|
||||
In the configuration example above, we have used the default provided by
|
||||
ActiveMQ that looks up the destination using JNDI.
|
||||
Apache ActiveMQ that looks up the destination using JNDI.
|
||||
|
||||
A new implementation can be provided by implementing
|
||||
`org.apache.activemq.jms.bridge.DestinationFactory` interface.
|
||||
|
@ -251,7 +251,7 @@ This mode is available for both durable and non-durable messages.
|
|||
|
||||
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 ActiveMQ
|
||||
once"). If both the source and the destination are on the same Apache 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
|
||||
|
@ -307,4 +307,4 @@ you will have to bear in mind timeout issues.
|
|||
Please see [the examples chapter](examples.md) which shows how to configure and use a JMS Bridge with
|
||||
JBoss AS to send messages to the source destination and consume them
|
||||
from the target destination and how to configure and use a JMS Bridge between
|
||||
two standalone ActiveMQ servers.
|
||||
two standalone Apache ActiveMQ servers.
|
||||
|
|
|
@ -1,9 +1,9 @@
|
|||
# Mapping JMS Concepts to the Core API
|
||||
|
||||
This chapter describes how JMS destinations are mapped to ActiveMQ
|
||||
This chapter describes how JMS destinations are mapped to Apache ActiveMQ
|
||||
addresses.
|
||||
|
||||
ActiveMQ core is JMS-agnostic. It does not have any concept of a JMS
|
||||
Apache 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
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Large Messages
|
||||
|
||||
ActiveMQ supports sending and receiving of huge messages, even when the
|
||||
Apache 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
|
||||
|
@ -8,7 +8,7 @@ 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, ActiveMQ will read the
|
||||
body, and when that message is sent, Apache ActiveMQ will read the
|
||||
`InputStream`. A `FileInputStream` could be used for example to send a
|
||||
huge message from a huge file on disk.
|
||||
|
||||
|
@ -52,9 +52,9 @@ determined by the parameter `minLargeMessageSize`
|
|||
|
||||
> **Note**
|
||||
>
|
||||
> ActiveMQ messages are encoded using 2 bytes per character so if the
|
||||
> Apache 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
|
||||
> size of the resulting Apache 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 `minLargeMessageSize` before it is sent,
|
||||
> but it then turns into a "large" message once it is encoded.
|
||||
|
@ -63,7 +63,7 @@ The default value is 100KiB.
|
|||
|
||||
### Using Core API
|
||||
|
||||
If the ActiveMQ Core API is used, the minimal large message size is
|
||||
If the Apache ActiveMQ Core API is used, the minimal large message size is
|
||||
specified by `ServerLocator.setMinLargeMessageSize`.
|
||||
|
||||
``` java
|
||||
|
@ -125,7 +125,7 @@ by default:
|
|||
|
||||
## Streaming large messages
|
||||
|
||||
ActiveMQ supports setting the body of messages using input and output
|
||||
Apache 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
|
||||
|
@ -213,7 +213,7 @@ _HQ_LARGE_SIZE.
|
|||
|
||||
### Streaming over JMS
|
||||
|
||||
When using JMS, ActiveMQ maps the streaming methods on the core API (see
|
||||
When using JMS, Apache ActiveMQ maps the streaming methods on the core API (see
|
||||
ClientMessage API table above) 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 ActiveMQ You could still access the data directly in an alternative
|
||||
of Apache 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.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Libaio Native Libraries
|
||||
|
||||
ActiveMQ distributes a native library, used as a bridge between ActiveMQ
|
||||
Apache ActiveMQ distributes a native library, used as a bridge between Apache ActiveMQ
|
||||
and Linux libaio.
|
||||
|
||||
`libaio` is a library, developed as part of the Linux kernel project.
|
||||
|
@ -11,13 +11,13 @@ when they have been processed.
|
|||
We use this in our high performance journal if configured to do so,
|
||||
please see [Persistence](persistence.md).
|
||||
|
||||
These are the native libraries distributed by ActiveMQ:
|
||||
These are the native libraries distributed by Apache ActiveMQ:
|
||||
|
||||
- libActiveMQAIO32.so - x86 32 bits
|
||||
|
||||
- libActiveMQAIO64.so - x86 64 bits
|
||||
|
||||
When using libaio, ActiveMQ will always try loading these files as long
|
||||
When using libaio, Apache ActiveMQ will always try loading these files as long
|
||||
as they are on the [library path](#using-server.library.path).
|
||||
|
||||
## Compiling the native libraries
|
||||
|
@ -87,5 +87,5 @@ libactivemq-native-RELEASE.so`. Simply move that file over
|
|||
`bin` with the proper rename [library
|
||||
path](#using-server.library.path).
|
||||
|
||||
If you want to perform changes on the ActiveMQ libaio code, you could
|
||||
If you want to perform changes on the Apache ActiveMQ libaio code, you could
|
||||
just call make directly at the `native-src` directory.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Logging
|
||||
|
||||
ActiveMQ uses the JBoss Logging framework to do its logging and is
|
||||
Apache 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.
|
||||
|
@ -21,7 +21,7 @@ There are 6 loggers available which are as follows:
|
|||
<tbody>
|
||||
<tr>
|
||||
<td>org.jboss.logging</td>
|
||||
<td>Logs any calls not handled by the ActiveMQ loggers</td>
|
||||
<td>Logs any calls not handled by the Apache ActiveMQ loggers</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>org.apache.activemq.core.server</td>
|
||||
|
@ -85,7 +85,7 @@ The following is a typical `logging.properties for a client`
|
|||
|
||||
# Root logger level
|
||||
logger.level=INFO
|
||||
# ActiveMQ logger levels
|
||||
# Apache 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
|
||||
|
|
|
@ -1,23 +1,23 @@
|
|||
# Management
|
||||
|
||||
ActiveMQ has an extensive management API that allows a user to modify a
|
||||
Apache 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* ActiveMQ. It also allows
|
||||
the operations allows a client to *manage* Apache ActiveMQ. It also allows
|
||||
clients to subscribe to management notifications.
|
||||
|
||||
There are 3 ways to manage ActiveMQ:
|
||||
There are 3 ways to manage Apache ActiveMQ:
|
||||
|
||||
- Using JMX -- JMX is the standard way to manage Java applications
|
||||
|
||||
- Using the core API -- management operations are sent to ActiveMQ
|
||||
- Using the core API -- management operations are sent to Apache ActiveMQ
|
||||
server using *core messages*
|
||||
|
||||
- Using the JMS API -- management operations are sent to ActiveMQ
|
||||
- Using the JMS API -- management operations are sent to Apache ActiveMQ
|
||||
server using *JMS messages*
|
||||
|
||||
Although there are 3 different ways to manage ActiveMQ each API supports
|
||||
Although there are 3 different ways to manage Apache 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.
|
||||
|
@ -33,7 +33,7 @@ API is the same.
|
|||
For each *managed resource*, there exists a Java interface describing
|
||||
what can be invoked for this type of resource.
|
||||
|
||||
ActiveMQ exposes its managed resources in 2 packages:
|
||||
Apache ActiveMQ exposes its managed resources in 2 packages:
|
||||
|
||||
- *Core* resources are located in the
|
||||
`org.apache.activemq.api.core.management` package
|
||||
|
@ -53,7 +53,7 @@ messages, or JMS messages are used.
|
|||
|
||||
### Core Management API
|
||||
|
||||
ActiveMQ defines a core management API to manage core resources. For
|
||||
Apache 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
|
||||
|
@ -113,7 +113,7 @@ full details of the API please consult the javadoc. In summary:
|
|||
|
||||
- Retrieving the server configuration and attributes
|
||||
|
||||
The `ActiveMQServerControl` exposes ActiveMQ server configuration
|
||||
The `ActiveMQServerControl` exposes Apache ActiveMQ server configuration
|
||||
through all its attributes (e.g. `getVersion()` method to retrieve
|
||||
the server's version, etc.)
|
||||
|
||||
|
@ -235,7 +235,7 @@ messages with a given property.)
|
|||
|
||||
#### Other Core Resources Management
|
||||
|
||||
ActiveMQ allows to start and stop its remote resources (acceptors,
|
||||
Apache 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
|
||||
|
@ -303,7 +303,7 @@ transactions). These resources are:
|
|||
|
||||
### JMS Management API
|
||||
|
||||
ActiveMQ defines a JMS Management API to manage JMS *administrated
|
||||
Apache ActiveMQ defines a JMS Management API to manage JMS *administrated
|
||||
objects* (i.e. JMS queues, topics and connection factories).
|
||||
|
||||
#### JMS Server Management
|
||||
|
@ -483,11 +483,11 @@ ObjectName `org.apache.activemq:module=JMS,type=Topic,name="<the topic
|
|||
|
||||
## Using Management Via JMX
|
||||
|
||||
ActiveMQ can be managed using
|
||||
Apache ActiveMQ can be managed using
|
||||
[JMX](http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html).
|
||||
|
||||
The management API is exposed by ActiveMQ using MBeans interfaces.
|
||||
ActiveMQ registers its resources with the domain `org.apache.activemq`.
|
||||
The management API is exposed by Apache ActiveMQ using MBeans interfaces.
|
||||
Apache ActiveMQ registers its resources with the domain `org.apache.activemq`.
|
||||
|
||||
For example, the `ObjectName` to manage a JMS Queue `exampleQueue` is:
|
||||
|
||||
|
@ -502,20 +502,20 @@ The MBean's `ObjectName` are built using the helper class
|
|||
also use `jconsole` to find the `ObjectName` of the MBeans you want to
|
||||
manage.
|
||||
|
||||
Managing ActiveMQ using JMX is identical to management of any Java
|
||||
Managing Apache 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 ActiveMQ. It can be disabled by
|
||||
By default, JMX is enabled to manage Apache ActiveMQ. It can be disabled by
|
||||
setting `jmx-management-enabled` to `false` in
|
||||
`activemq-configuration.xml`:
|
||||
|
||||
<!-- false to disable JMX management for ActiveMQ -->
|
||||
<!-- false to disable JMX management for Apache ActiveMQ -->
|
||||
<jmx-management-enabled>false</jmx-management-enabled>
|
||||
|
||||
If JMX is enabled, ActiveMQ can be managed locally using `jconsole`.
|
||||
If JMX is enabled, Apache ActiveMQ can be managed locally using `jconsole`.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
|
@ -525,9 +525,9 @@ If JMX is enabled, ActiveMQ can be managed locally using `jconsole`.
|
|||
> to configure the server for remote management (system properties must
|
||||
> be set in `run.sh` or `run.bat` scripts).
|
||||
|
||||
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
|
||||
By default, Apache ActiveMQ server uses the JMX domain "org.apache.activemq".
|
||||
To manage several Apache ActiveMQ servers from the *same* MBeanServer, the JMX
|
||||
domain can be configured for each individual Apache ActiveMQ server by setting
|
||||
`jmx-domain` in `activemq-configuration.xml`:
|
||||
|
||||
<!-- use a specific JMX domain for ActiveMQ MBeans -->
|
||||
|
@ -535,14 +535,14 @@ domain can be configured for each individual ActiveMQ server by setting
|
|||
|
||||
#### MBeanServer configuration
|
||||
|
||||
When ActiveMQ is run in standalone, it uses the Java Virtual Machine's
|
||||
When Apache ActiveMQ is run in standalone, it uses the Java Virtual Machine's
|
||||
`Platform MBeanServer` to register its MBeans. By default [Jolokia](http://www.jolokia.org/)
|
||||
is also deployed to allow access to the mbean server via rest.
|
||||
|
||||
### Example
|
||||
|
||||
See the [chapters](examples.md) chapter for an example which shows how to use a remote connection to JMX
|
||||
and MBean proxies to manage ActiveMQ.
|
||||
and MBean proxies to manage Apache ActiveMQ.
|
||||
|
||||
### Exposing JMX using Jolokia
|
||||
|
||||
|
@ -573,7 +573,7 @@ management API:
|
|||
- The parameters of the management operation
|
||||
|
||||
When such a management message is sent to the management address,
|
||||
ActiveMQ server will handle it, extract the information, invoke the
|
||||
Apache 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`).
|
||||
|
@ -642,7 +642,7 @@ be able to receive and handle management messages. This is also
|
|||
configured in activemq-configuration.xml:
|
||||
|
||||
<!-- users with the admin role will be allowed to manage -->
|
||||
<!-- ActiveMQ using management messages -->
|
||||
<!-- Apache ActiveMQ using management messages -->
|
||||
<security-setting match="jms.queue.activemq.management">
|
||||
<permission type="manage" roles="admin" />
|
||||
</security-setting>
|
||||
|
@ -699,11 +699,11 @@ steps are the same (see Configuring Core Management section).
|
|||
### Example
|
||||
|
||||
See the [examples](examples.md) chapter for an example which shows
|
||||
how to use JMS messages to manage the ActiveMQ server.
|
||||
how to use JMS messages to manage the Apache ActiveMQ server.
|
||||
|
||||
## Management Notifications
|
||||
|
||||
ActiveMQ emits *notifications* to inform listeners of potentially
|
||||
Apache ActiveMQ emits *notifications* to inform listeners of potentially
|
||||
interesting events (creation of new resources, security violation,
|
||||
etc.).
|
||||
|
||||
|
@ -728,7 +728,7 @@ subscribing to 2 MBeans:
|
|||
|
||||
### Core Messages Notifications
|
||||
|
||||
ActiveMQ defines a special *management notification address*. Core
|
||||
Apache 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
|
||||
|
||||
|
@ -755,7 +755,7 @@ By default, the address is `activemq.notifications`.
|
|||
|
||||
### JMS Messages Notifications
|
||||
|
||||
ActiveMQ's notifications can also be received using JMS messages.
|
||||
Apache 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
|
||||
|
@ -900,7 +900,7 @@ header. The timestamp is the un-formatted result of a call to
|
|||
## Message Counters
|
||||
|
||||
Message counters can be used to obtain information on queues *over time*
|
||||
as ActiveMQ keeps a history on queue metrics.
|
||||
as Apache 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
|
||||
|
@ -973,7 +973,7 @@ Message counters can be retrieved using the Management API. For example,
|
|||
to retrieve message counters on a JMS Queue using JMX:
|
||||
|
||||
``` java
|
||||
// retrieve a connection to ActiveMQ's MBeanServer
|
||||
// retrieve a connection to Apache ActiveMQ's MBeanServer
|
||||
MBeanServerConnection mbsc = ...
|
||||
JMSQueueControlMBean queueControl = (JMSQueueControl)MBeanServerInvocationHandler.newProxyInstance(mbsc,
|
||||
on,
|
||||
|
|
|
@ -2,18 +2,18 @@
|
|||
|
||||
Messages can be set with an optional *time to live* when sending them.
|
||||
|
||||
ActiveMQ will not deliver a message to a consumer after it's time to
|
||||
Apache 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.
|
||||
|
||||
ActiveMQ's addresses can be assigned a expiry address so that, when
|
||||
Apache 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 ActiveMQ Core API, you can set an expiration time directly on the
|
||||
Using Apache ActiveMQ Core API, you can set an expiration time directly on the
|
||||
message:
|
||||
|
||||
// message will expire in 5000ms from now
|
||||
|
|
|
@ -5,7 +5,7 @@ characteristics:
|
|||
|
||||
- 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 ActiveMQ Core API).
|
||||
`_HQ_GROUP_ID` for Apache ActiveMQ Core API).
|
||||
|
||||
- Messages in a message group are always consumed by the same
|
||||
consumer, even if there are many consumers on a queue. They pin all
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Messaging Concepts
|
||||
|
||||
ActiveMQ is an asynchronous messaging system, an example of [Message
|
||||
Apache ActiveMQ is an asynchronous messaging system, an example of [Message
|
||||
Oriented
|
||||
Middleware](http://en.wikipedia.org/wiki/Message_oriented_middleware) ,
|
||||
we'll just call them messaging systems in the remainder of this book.
|
||||
|
@ -140,7 +140,7 @@ require.
|
|||
## Transactions
|
||||
|
||||
Messaging systems typically support the sending and acknowledgement of
|
||||
multiple messages in a single local transaction. ActiveMQ also supports
|
||||
multiple messages in a single local transaction. Apache ActiveMQ also supports
|
||||
the sending and acknowledgement of message as part of a large global
|
||||
transaction - using the Java mapping of XA: JTA.
|
||||
|
||||
|
@ -184,7 +184,7 @@ programmatic API so JMS clients and servers from different vendors
|
|||
cannot directly interoperate since each will use the vendor's own
|
||||
internal wire protocol.
|
||||
|
||||
ActiveMQ provides a fully compliant JMS 1.1 and JMS 2.0 API.
|
||||
Apache ActiveMQ provides a fully compliant JMS 1.1 and JMS 2.0 API.
|
||||
|
||||
### System specific APIs
|
||||
|
||||
|
@ -194,7 +194,7 @@ of system 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.
|
||||
|
||||
ActiveMQ provides its own core client API for clients to use if they
|
||||
Apache 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.
|
||||
|
||||
|
@ -216,7 +216,7 @@ use HTTP as their underlying 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 [Rest Interface](rest.md) for using ActiveMQ's RESTful interface.
|
||||
Please see [Rest Interface](rest.md) for using Apache ActiveMQ's RESTful interface.
|
||||
|
||||
### STOMP
|
||||
|
||||
|
@ -226,7 +226,7 @@ theoretically any Stomp client can work with any messaging system that
|
|||
supports Stomp. Stomp clients are available in many different
|
||||
programming languages.
|
||||
|
||||
Please see [Stomp](interoperability.md) for using STOMP with ActiveMQ.
|
||||
Please see [Stomp](interoperability.md) for using STOMP with Apache ActiveMQ.
|
||||
|
||||
### AMQP
|
||||
|
||||
|
@ -235,10 +235,10 @@ 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.
|
||||
|
||||
ActiveMQ implements the [AMQP
|
||||
Apache ActiveMQ implements the [AMQP
|
||||
1.0](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=amqp)
|
||||
specification. Any client that supports the 1.0 specification will be
|
||||
able to interact with ActiveMQ.
|
||||
able to interact with Apache ActiveMQ.
|
||||
|
||||
## High Availability
|
||||
|
||||
|
@ -246,7 +246,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.
|
||||
|
||||
ActiveMQ provides automatic failover where your sessions are
|
||||
Apache ActiveMQ provides automatic failover where your sessions are
|
||||
automatically reconnected to the backup server on event of live server
|
||||
failure.
|
||||
|
||||
|
@ -263,12 +263,12 @@ 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.
|
||||
|
||||
ActiveMQ provides very configurable state-of-the-art clustering model
|
||||
Apache 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.
|
||||
|
||||
ActiveMQ also has the ability to automatically redistribute messages
|
||||
Apache 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 [Clusters](clusters.md).
|
||||
|
@ -284,10 +284,10 @@ messages to another queue on a different server. Bridges cope with
|
|||
unreliable connections, automatically reconnecting when the connections
|
||||
becomes available again.
|
||||
|
||||
ActiveMQ bridges can be configured with filter expressions to only
|
||||
Apache ActiveMQ bridges can be configured with filter expressions to only
|
||||
forward certain messages, and transformation can also be hooked in.
|
||||
|
||||
ActiveMQ also allows routing between queues to be configured in server
|
||||
Apache 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.
|
||||
|
|
|
@ -1,17 +1,17 @@
|
|||
# Paging
|
||||
|
||||
ActiveMQ transparently supports huge queues containing millions of
|
||||
Apache 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 ActiveMQ transparently *pages* messages into
|
||||
memory at any one time, so Apache ActiveMQ transparently *pages* messages into
|
||||
and out of memory as they are needed, thus allowing massive queues with
|
||||
a low memory footprint.
|
||||
|
||||
ActiveMQ will start paging messages to disk, when the size of all
|
||||
Apache 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, ActiveMQ does not page messages - this must be explicitly
|
||||
By default, Apache ActiveMQ does not page messages - this must be explicitly
|
||||
configured to activate it.
|
||||
|
||||
## Page Files
|
||||
|
@ -52,7 +52,7 @@ Global paging parameters are specified on the main configuration file
|
|||
|
||||
Property Name Description Default
|
||||
-------------------- --------------------------------------------------------------------------------------------------------------------------- -------------
|
||||
`paging-directory` Where page files are stored. ActiveMQ will create one folder for each address being paged under this configured location. data/paging
|
||||
`paging-directory` Where page files are stored. Apache ActiveMQ will create one folder for each address being paged under this configured location. data/paging
|
||||
|
||||
: Paging Configuration Parameters
|
||||
|
||||
|
@ -183,4 +183,4 @@ undesirable state.
|
|||
|
||||
## Example
|
||||
|
||||
See the [examples](examples.md) chapter for an example which shows how to use paging with ActiveMQ.
|
||||
See the [examples](examples.md) chapter for an example which shows how to use paging with Apache ActiveMQ.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Performance Tuning
|
||||
|
||||
In this chapter we'll discuss how to tune ActiveMQ for optimum
|
||||
In this chapter we'll discuss how to tune Apache ActiveMQ for optimum
|
||||
performance.
|
||||
|
||||
## Tuning persistence
|
||||
|
@ -72,12 +72,12 @@ JMS API
|
|||
storage.
|
||||
|
||||
- Batch many sends or acknowledgements in a single transaction.
|
||||
ActiveMQ will only require a network round trip on the commit, not
|
||||
Apache ActiveMQ will only require a network round trip on the commit, not
|
||||
on every send or acknowledgement.
|
||||
|
||||
## Other Tunings
|
||||
|
||||
There are various other places in ActiveMQ where we can perform some
|
||||
There are various other places in Apache ActiveMQ where we can perform some
|
||||
tuning:
|
||||
|
||||
- Use Asynchronous Send Acknowledgements. If you need to send durable
|
||||
|
@ -125,7 +125,7 @@ tuning:
|
|||
consumer-window-size. This effectively disables consumer flow
|
||||
control.
|
||||
|
||||
- Socket NIO vs Socket Old IO. By default ActiveMQ uses old (blocking)
|
||||
- Socket NIO vs Socket Old IO. By default Apache ActiveMQ uses old (blocking)
|
||||
on the server and the client side (see the chapter on configuring
|
||||
transports for more information [Configuring the Transport](configuring-transports.md). NIO is much more scalable but
|
||||
can give you some latency hit compared to old blocking IO. If you
|
||||
|
@ -174,7 +174,7 @@ tuning:
|
|||
`serveruser`.
|
||||
|
||||
- Use `batch-delay` and set `direct-deliver` to false for the best
|
||||
throughput for very small messages. ActiveMQ comes with a
|
||||
throughput for very small messages. Apache ActiveMQ comes with a
|
||||
preconfigured connector/acceptor pair (`netty-throughput`) in
|
||||
`activemq-configuration.xml` and JMS connection factory
|
||||
(`ThroughputConnectionFactory`) in `activemq-jms.xml`which can be
|
||||
|
@ -193,7 +193,7 @@ tunings won't apply to JDKs from other providers (e.g. IBM or JRockit)
|
|||
`-XX:+UseParallelOldGC` on Sun JDKs.
|
||||
|
||||
- Memory settings. Give as much memory as you can to the server.
|
||||
ActiveMQ can run in low memory by using paging (described in [Paging](paging.md)) but
|
||||
Apache ActiveMQ can run in low memory by using paging (described in [Paging](paging.md)) 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 size and number of your messages. Use the JVM
|
||||
|
@ -223,7 +223,7 @@ tunings won't apply to JDKs from other providers (e.g. IBM or JRockit)
|
|||
> 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
|
||||
> ActiveMQ! The Spring JMS Template can only safely be used in an
|
||||
> Apache 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.
|
||||
|
|
|
@ -1,14 +1,14 @@
|
|||
# Persistence
|
||||
|
||||
In this chapter we will describe how persistence works with ActiveMQ and
|
||||
In this chapter we will describe how persistence works with Apache ActiveMQ and
|
||||
how to configure it.
|
||||
|
||||
ActiveMQ ships with a high performance journal. Since ActiveMQ handles
|
||||
Apache ActiveMQ ships with a high performance journal. Since Apache 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 ActiveMQ journal is an *append only* journal. It consists of a set of
|
||||
An Apache 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
|
||||
|
@ -27,12 +27,12 @@ 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, ActiveMQ has a sophisticated
|
||||
As delete records are added to the journal, Apache 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.
|
||||
|
||||
ActiveMQ also has a compaction algorithm which removes dead space from
|
||||
Apache 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.
|
||||
|
||||
|
@ -41,7 +41,7 @@ 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. ActiveMQ ships with two implementations:
|
||||
implementations. Apache ActiveMQ ships with two implementations:
|
||||
|
||||
- Java [NIO](http://en.wikipedia.org/wiki/New_I/O).
|
||||
|
||||
|
@ -52,7 +52,7 @@ implementations. ActiveMQ ships with two implementations:
|
|||
- Linux Asynchronous IO
|
||||
|
||||
The second implementation uses a thin native code wrapper to talk to
|
||||
the Linux asynchronous IO library (AIO). With AIO, ActiveMQ will be
|
||||
the Linux asynchronous IO library (AIO). With AIO, Apache 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.
|
||||
|
@ -73,7 +73,7 @@ implementations. ActiveMQ ships with two implementations:
|
|||
|
||||
libaio is part of the kernel project.
|
||||
|
||||
The standard ActiveMQ core server uses two instances of the journal:
|
||||
The standard Apache ActiveMQ core server uses two instances of the journal:
|
||||
|
||||
- Bindings journal.
|
||||
|
||||
|
@ -107,7 +107,7 @@ The standard ActiveMQ core server uses two instances of the journal:
|
|||
This journal instance stores all message related data, including the
|
||||
message themselves and also duplicate-id caches.
|
||||
|
||||
By default ActiveMQ will try and use an AIO journal. If AIO is not
|
||||
By default Apache 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.
|
||||
|
@ -116,13 +116,13 @@ The standard ActiveMQ core server uses two instances of the journal:
|
|||
has a `hq` extension. File size is by the default `10485760`
|
||||
(configurable), and it is located at the journal folder.
|
||||
|
||||
For large messages, ActiveMQ persists them outside the message journal.
|
||||
For large messages, Apache ActiveMQ persists them outside the message journal.
|
||||
This is discussed in [Large Messages](large-messages.md).
|
||||
|
||||
ActiveMQ can also be configured to page messages to disk in low memory
|
||||
Apache ActiveMQ can also be configured to page messages to disk in low memory
|
||||
situations. This is discussed in [Paging](paging.md).
|
||||
|
||||
If no persistence is required at all, ActiveMQ can also be configured
|
||||
If no persistence is required at all, Apache ActiveMQ can also be configured
|
||||
not to persist any data at all to storage as discussed in the Configuring
|
||||
HornetQ for Zero Persistence section.
|
||||
|
||||
|
@ -182,18 +182,18 @@ The message journal is configured using the following attributes in
|
|||
|
||||
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 ActiveMQ will
|
||||
running Linux or you do not have libaio installed then Apache ActiveMQ will
|
||||
detect this and automatically fall back to using `NIO`.
|
||||
|
||||
- `journal-sync-transactional`
|
||||
|
||||
If this is set to true then ActiveMQ will make sure all transaction
|
||||
If this is set to true then Apache 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 ActiveMQ will make sure non
|
||||
If this is set to true then Apache ActiveMQ will make sure non
|
||||
transactional message data (sends and acknowledgements) are flushed
|
||||
to disk each time. The default value for this is `true`.
|
||||
|
||||
|
@ -204,8 +204,8 @@ The message journal is configured using the following attributes in
|
|||
|
||||
- `journal-min-files`
|
||||
|
||||
The minimum number of files the journal will maintain. When ActiveMQ
|
||||
starts and there is no initial message data, ActiveMQ will
|
||||
The minimum number of files the journal will maintain. When Apache ActiveMQ
|
||||
starts and there is no initial message data, Apache ActiveMQ will
|
||||
pre-create `journal-min-files` number of files.
|
||||
|
||||
Creating journal files and filling them with padding is a fairly
|
||||
|
@ -322,7 +322,7 @@ The message journal is configured using the following attributes in
|
|||
## Installing AIO
|
||||
|
||||
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
|
||||
Apache 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
|
||||
|
@ -339,10 +339,10 @@ Using aptitude, (e.g. on Ubuntu or Debian system):
|
|||
|
||||
apt-get install libaio
|
||||
|
||||
## Configuring ActiveMQ for Zero Persistence
|
||||
## Configuring Apache ActiveMQ for Zero Persistence
|
||||
|
||||
In some situations, zero persistence is sometimes required for a
|
||||
messaging system. Configuring ActiveMQ to perform zero persistence is
|
||||
messaging system. Configuring Apache ActiveMQ to perform zero persistence is
|
||||
straightforward. Simply set the parameter `persistence-enabled` in
|
||||
`activemq-configuration.xml` to `false`.
|
||||
|
||||
|
@ -353,7 +353,7 @@ message data, duplicate id caches or paging data will be persisted.
|
|||
## Import/Export the Journal Data
|
||||
|
||||
You may want to inspect the existent records on each one of the journals
|
||||
used by ActiveMQ, and you can use the export/import tool for that
|
||||
used by Apache ActiveMQ, and you can use the export/import tool for that
|
||||
purpose.
|
||||
you can export the journal as a text file by using this command:
|
||||
|
||||
|
|
|
@ -8,14 +8,14 @@ JMS specifies 3 acknowledgement modes:
|
|||
|
||||
- `DUPS_OK_ACKNOWLEDGE`
|
||||
|
||||
ActiveMQ supports two additional modes: `PRE_ACKNOWLEDGE` and
|
||||
Apache 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 ActiveMQ and will call it
|
||||
This extra mode is supported by Apache ActiveMQ and will call it
|
||||
*pre-acknowledge* mode.
|
||||
|
||||
The disadvantage of acknowledging on the server before delivery is that
|
||||
|
|
|
@ -1,24 +1,24 @@
|
|||
# Preface
|
||||
|
||||
What is ActiveMQ?
|
||||
What is Apache ActiveMQ?
|
||||
|
||||
- ActiveMQ is an open source project to build a multi-protocol,
|
||||
- Apache ActiveMQ is an open source project to build a multi-protocol,
|
||||
embeddable, very high performance, clustered, asynchronous messaging
|
||||
system.
|
||||
|
||||
- ActiveMQ is an example of Message Oriented Middleware (MoM). For a
|
||||
- Apache ActiveMQ is an example of Message Oriented Middleware (MoM). For a
|
||||
description of MoMs and other messaging concepts please see the [Messaging Concepts](messaging-concepts.md).
|
||||
|
||||
- For answers to more questions about what ActiveMQ is and what it
|
||||
- For answers to more questions about what Apache ActiveMQ is and what it
|
||||
isn't please visit the [FAQs wiki
|
||||
page](todo).
|
||||
|
||||
Why use ActiveMQ? Here are just a few of the reasons:
|
||||
Why use Apache ActiveMQ? Here are just a few of the reasons:
|
||||
|
||||
- 100% open source software. ActiveMQ is licensed using the Apache
|
||||
- 100% open source software. Apache ActiveMQ is licensed using the Apache
|
||||
Software License v 2.0 to minimise barriers to adoption.
|
||||
|
||||
- ActiveMQ is designed with usability in mind.
|
||||
- Apache ActiveMQ is designed with usability in mind.
|
||||
|
||||
- Written in Java. Runs on any platform with a Java 8+ runtime, that's
|
||||
everything from Windows desktops to IBM mainframes.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Project Information
|
||||
|
||||
The official ActiveMQ project page is <http://activemq.apache.org//>.
|
||||
The official Apache ActiveMQ project page is <http://activemq.apache.org//>.
|
||||
|
||||
## Software Download
|
||||
|
||||
|
@ -20,11 +20,11 @@ page:<http://activemq.apache.org/download.html>
|
|||
|
||||
- Follow us on [twitter](https://twitter.com/activemq)
|
||||
|
||||
- ActiveMQ Git repository is <https://github.com/apache/activemq-6>
|
||||
- Apache ActiveMQ Git repository is <https://github.com/apache/activemq-6>
|
||||
|
||||
- All release tags are available from
|
||||
<https://github.com/apache/activemq-6/releases>
|
||||
|
||||
|
||||
And many thanks to all our contributors, both old and new who helped
|
||||
create ActiveMQ.
|
||||
create Apache ActiveMQ.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
# REST Interface
|
||||
|
||||
The ActiveMQ REST interface allows you to leverage the reliability and
|
||||
scalability features of ActiveMQ over a simple REST/HTTP interface.
|
||||
The Apache ActiveMQ REST interface allows you to leverage the reliability and
|
||||
scalability features of Apache 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
|
||||
|
@ -18,47 +18,47 @@ express as an HTTP message:
|
|||
</order>
|
||||
|
||||
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 ActiveMQ
|
||||
as a JMS message and distributed through core ActiveMQ. Simple and easy.
|
||||
When the XML is received on the server is it processed within Apache ActiveMQ
|
||||
as a JMS message and distributed through core Apache 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.
|
||||
|
||||
## Goals of REST Interface
|
||||
|
||||
Why would you want to use ActiveMQ's REST interface? What are the goals
|
||||
Why would you want to use Apache ActiveMQ's REST interface? What are the goals
|
||||
of the REST interface?
|
||||
|
||||
- Easily usable by machine-based (code) clients.
|
||||
|
||||
- Zero client footprint. We want ActiveMQ to be usable by any
|
||||
- Zero client footprint. We want Apache 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 ActiveMQ.
|
||||
special library to interact with Apache ActiveMQ.
|
||||
|
||||
- Lightweight interoperability. The HTTP protocol is strong enough to
|
||||
be our message exchange protocol. Since interactions are 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 ActiveMQ (i.e. the [REST-\*](http://rest-star.org)
|
||||
interface as Apache ActiveMQ (i.e. the [REST-\*](http://rest-star.org)
|
||||
effort.)
|
||||
|
||||
- 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 ActiveMQ's REST
|
||||
format in order to send and receive messages through Apache ActiveMQ's REST
|
||||
interface.
|
||||
|
||||
- Leverage the reliability, scalability, and clustering features of
|
||||
ActiveMQ on the back end without sacrificing the simplicity of a
|
||||
Apache ActiveMQ on the back end without sacrificing the simplicity of a
|
||||
REST interface.
|
||||
|
||||
## Installation and Configuration
|
||||
|
||||
ActiveMQ's REST interface is installed as a Web archive (WAR). It depends on the [RESTEasy](http://jboss.org/resteasy) project and can currently only run within a servlet container. Installing 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 Wildfly) or you want the ActiveMQ REST WAR to startup and manage the ActiveMQ server (e.g. you're deploying within something like Apache Tomcat).
|
||||
Apache ActiveMQ's REST interface is installed as a Web archive (WAR). It depends on the [RESTEasy](http://jboss.org/resteasy) project and can currently only run within a servlet container. Installing the Apache ActiveMQ REST interface is a little bit different depending whether Apache ActiveMQ is already installed and configured for your environment (e.g. you're deploying within Wildfly) or you want the ActiveMQ REST WAR to startup and manage the Apache 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 ActiveMQ REST interface in an environment that already has ActiveMQ installed and running, e.g. the Wildfly application server. You must create a Web archive (.WAR) file with the following web.xml settings:
|
||||
This section should be used when you want to use the Apache ActiveMQ REST interface in an environment that already has Apache ActiveMQ installed and running, e.g. the Wildfly application server. You must create a Web archive (.WAR) file with the following web.xml settings:
|
||||
|
||||
<web-app>
|
||||
<listener>
|
||||
|
@ -86,7 +86,7 @@ This section should be used when you want to use the ActiveMQ REST interface in
|
|||
</filter-mapping>
|
||||
</web-app>
|
||||
|
||||
Within your WEB-INF/lib directory you must have the 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 a WAR with the ActiveMQ REST library.
|
||||
Within your WEB-INF/lib directory you must have the Apache 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 a WAR with the Apache ActiveMQ REST library.
|
||||
|
||||
<project xmlns="http://maven.apache.org/POM/4.0.0"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
|
@ -128,7 +128,7 @@ It is worth noting that when deploying a WAR in a Java EE application server lik
|
|||
|
||||
### Bootstrapping ActiveMQ Along with REST
|
||||
|
||||
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 config file 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:
|
||||
You can bootstrap Apache ActiveMQ within your WAR as well. To do this, you must have the Apache ActiveMQ core and JMS jars along with Netty, RESTEasy, and the Apache ActiveMQ REST jar within your WEB-INF/lib. You must also have an Apache ActiveMQ-configuration.xml config file within WEB-INF/classes. The examples that come with the Apache ActiveMQ REST distribution show how to do this. You must also add an additional listener to your web.xml file. Here's an example:
|
||||
|
||||
<web-app>
|
||||
<listener>
|
||||
|
@ -162,7 +162,7 @@ You can bootstrap ActiveMQ within your WAR as well. To do this, you must have th
|
|||
</filter-mapping>
|
||||
</web-app>
|
||||
|
||||
Here's a Maven pom.xml file for creating a WAR for this environment. Make sure your ActiveMQ configuration file(s) are within the src/main/resources directory so that they are stuffed within the WAR's WEB-INF/classes directory!
|
||||
Here's a Maven pom.xml file for creating a WAR for this environment. Make sure your Apache ActiveMQ configuration file(s) are within the src/main/resources directory so that they are stuffed within the WAR's WEB-INF/classes directory!
|
||||
|
||||
<project xmlns="http://maven.apache.org/POM/4.0.0"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
|
@ -197,7 +197,7 @@ The project structure should look this like:
|
|||
|
||||
### REST Configuration
|
||||
|
||||
The ActiveMQ REST implementation does have some configuration options.
|
||||
The Apache 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 configuration
|
||||
|
@ -220,12 +220,12 @@ values for each.
|
|||
|
||||
Let's give an explanation of each config option.
|
||||
|
||||
- `server-in-vm-id`. The ActiveMQ REST impl uses the IN-VM transport
|
||||
to communicate with ActiveMQ. It uses the default server id, which
|
||||
- `server-in-vm-id`. The Apache ActiveMQ REST impl uses the IN-VM transport
|
||||
to communicate with Apache 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 ActiveMQ REST
|
||||
custom headers. You can instead have the Apache ActiveMQ REST
|
||||
implementation publish links using the [Link Header
|
||||
specification](http://tools.ietf.org/html/draft-nottingham-http-link-header-10)
|
||||
instead if you desire.
|
||||
|
@ -244,7 +244,7 @@ Let's give an explanation of each config option.
|
|||
system path. This is a directory where push registrations for queues
|
||||
are stored. See [Pushing Messages](#message-push).
|
||||
|
||||
- `producer-session-pool-size`. The REST implementation pools ActiveMQ
|
||||
- `producer-session-pool-size`. The REST implementation pools Apache ActiveMQ
|
||||
sessions for sending messages. This is the size of the pool. That
|
||||
number of sessions will be created at startup time.
|
||||
|
||||
|
@ -260,12 +260,12 @@ Let's give an explanation of each config option.
|
|||
consumers/subscriptions that remain idle for that amount of time.
|
||||
|
||||
- `consumer-window-size`. For consumers, this config option is the
|
||||
same as the ActiveMQ one of the same name. It will be used by
|
||||
sessions created by the ActiveMQ REST implementation.
|
||||
same as the Apache ActiveMQ one of the same name. It will be used by
|
||||
sessions created by the Apache ActiveMQ REST implementation.
|
||||
|
||||
## ActiveMQ REST Interface Basics
|
||||
## Apache ActiveMQ REST Interface Basics
|
||||
|
||||
The ActiveMQ REST interface publishes a variety of REST resources to
|
||||
The Apache 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.
|
||||
|
@ -280,7 +280,7 @@ following relative URI pattern:
|
|||
/queues/{name}
|
||||
/topics/{name}
|
||||
|
||||
The base of the URI is the base URL of the WAR you deployed the ActiveMQ
|
||||
The base of the URI is the base URL of the WAR you deployed the Apache ActiveMQ
|
||||
REST server within as defined in the [Installation and
|
||||
Configuration](#install) section of this document. Replace the `{name}`
|
||||
string within the above URI pattern with the name of the queue or topic
|
||||
|
@ -288,7 +288,7 @@ you are interested in interacting with. For example if you have
|
|||
configured a JMS topic named "foo" within your `activemq-jms.xml` file,
|
||||
the URI name should be "jms.topic.foo". If you have configured a JMS
|
||||
queue name "bar" within your `activemq-jms.xml` file, the URI name
|
||||
should be "jms.queue.bar". Internally, ActiveMQ prepends the "jms.topic"
|
||||
should be "jms.queue.bar". Internally, Apache 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.
|
||||
|
@ -317,7 +317,7 @@ on the scheme of the URLs returned within these headers as they 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 ActiveMQ REST interface evolves over time.
|
||||
changes as the Apache ActiveMQ REST interface evolves over time.
|
||||
|
||||
### Queue Resource Response Headers
|
||||
|
||||
|
@ -336,7 +336,7 @@ with a Queue resource.
|
|||
[Consuming Messages via Pull](#message-pull).
|
||||
|
||||
- `msg-push-consumers`. This is a URL for registering other URLs you
|
||||
want the ActiveMQ REST server to push messages to. The semantics of
|
||||
want the Apache ActiveMQ REST server to push messages to. The semantics of
|
||||
this link are described in [Pushing Messages](#message-push).
|
||||
|
||||
### Topic Resource Response Headers
|
||||
|
@ -356,19 +356,19 @@ with a Topic resource.
|
|||
described in [Consuming Messages via Pull](#message-pull).
|
||||
|
||||
- `msg-push-subscriptions`. This is a URL for registering other URLs
|
||||
you want the ActiveMQ REST server to push messages to. The semantics
|
||||
you want the Apache ActiveMQ REST server to push messages to. The semantics
|
||||
of this link are described in [Pushing Messages](#message-push).
|
||||
|
||||
## Posting Messages
|
||||
|
||||
This chapter discusses the protocol for posting messages to a queue or a
|
||||
topic. In [ActiveMQ REST Interface Basics](#basics), you saw that a
|
||||
topic. In [Apache ActiveMQ REST Interface Basics](#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
|
||||
ActiveMQ destination. Here's an example scenario:
|
||||
Apache ActiveMQ destination. Here's an example scenario:
|
||||
|
||||
> **Note**
|
||||
>
|
||||
|
@ -450,10 +450,10 @@ Sometimes you might have network problems when posting new 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 ActiveMQ REST interface is
|
||||
posted to the queue or topic. By default, the Apache 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 [ActiveMQ REST Interface
|
||||
option to `false` as described in [Apache ActiveMQ REST Interface
|
||||
Basics](#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
|
||||
|
@ -531,17 +531,17 @@ discussed earlier. Here's an example:
|
|||
in the `msg-create-next` header.
|
||||
|
||||
How can this work? As you can see, with each successful response, the
|
||||
ActiveMQ REST server returns a uniquely generated URL within the
|
||||
Apache 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 ActiveMQ's duplicate detection mechanism by setting the
|
||||
the URL and uses Apache ActiveMQ's duplicate detection mechanism by setting the
|
||||
`DUPLICATE_DETECTION_ID` property of the JMS message that is actually
|
||||
posted to the system.
|
||||
|
||||
If you happen to use the same ID more than once you'll see a message
|
||||
like this on the server:
|
||||
|
||||
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:
|
||||
WARN [org.apache.activemq.core.server] (Thread-3 (Apache 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`
|
||||
|
@ -568,7 +568,7 @@ repost the message. It also only has to come up with a unique
|
|||
### Persistent Messages
|
||||
|
||||
By default, posted messages are not durable and will not be persisted in
|
||||
ActiveMQ's journal. You can create durable messages by modifying the
|
||||
Apache 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 your messages to the URLs
|
||||
|
@ -615,14 +615,14 @@ almost identically for queues and topics with some minor, but 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 ActiveMQ through a REST
|
||||
best way to work most effectively with Apache ActiveMQ through a REST
|
||||
interface.
|
||||
|
||||
You create consumer resources by doing a simple POST to the URL
|
||||
published by the `msg-pull-consumers` 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 [ActiveMQ REST Interface
|
||||
queue or topic resource discussed in [Apache ActiveMQ REST Interface
|
||||
Basics](#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 subscription to the
|
||||
|
@ -642,7 +642,7 @@ parameters (`application/x-www-form-urlencoded`) described below.
|
|||
provide this parameter, the name will be automatically generated by
|
||||
the server. Only usable on topics.
|
||||
|
||||
- `selector`. This is an optional JMS selector string. The ActiveMQ
|
||||
- `selector`. This is an optional JMS selector string. The Apache 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 '\$'.
|
||||
|
@ -810,7 +810,7 @@ resource.
|
|||
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 ActiveMQ REST might be redirecting you or adding
|
||||
future versions of Apache ActiveMQ REST might be redirecting you or adding
|
||||
additional data to the URL after timeouts like this.
|
||||
|
||||
3. POST to the URL within the last `msg-consume-next` to get the next
|
||||
|
@ -1063,7 +1063,7 @@ request on the consumer resource.
|
|||
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 ActiveMQ REST interface provides the
|
||||
alleviate this problem, the Apache 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 is the time in
|
||||
|
@ -1098,9 +1098,9 @@ server-side consumer resource (and underlying JMS session).
|
|||
|
||||
## Pushing Messages
|
||||
|
||||
You can configure the ActiveMQ REST server to push messages to a
|
||||
You can configure the Apache 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 ActiveMQ REST server to load
|
||||
creating a pre-configured XML file for the Apache ActiveMQ REST server to load
|
||||
at boot time.
|
||||
|
||||
### The Queue Push Subscription XML
|
||||
|
@ -1145,7 +1145,7 @@ performing a retry.
|
|||
The `disableOnFailure` element, if set to true, 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 ActiveMQ will
|
||||
instance). In these cases, the dead letter queue logic of Apache ActiveMQ will
|
||||
take over.
|
||||
|
||||
The `link` element specifies the basis of the interaction. The `href`
|
||||
|
@ -1158,10 +1158,10 @@ important and the value of it triggers different behavior. Here's the
|
|||
values a rel attribute can have:
|
||||
|
||||
- `destination`. The href URL is assumed to be a queue or topic
|
||||
resource of another ActiveMQ REST server. The push registration will
|
||||
resource of another Apache 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 ActiveMQ REST endpoint reliably. Here's an example:
|
||||
messages to the Apache ActiveMQ REST endpoint reliably. Here's an example:
|
||||
|
||||
<push-registration>
|
||||
<link rel="destination" href="http://somewhere.com/queues/jms.queue.foo"/>
|
||||
|
@ -1368,19 +1368,19 @@ Here's what creating a topic would look like:
|
|||
HTTP/1.1 201 Created
|
||||
Location: http://example.com/topics/jms.topic.testTopic
|
||||
|
||||
## Securing the ActiveMQ REST Interface
|
||||
## Securing the Apache ActiveMQ REST Interface
|
||||
|
||||
### Within Wildfly Application server
|
||||
|
||||
Securing the ActiveMQ REST interface is very simple with the Wildfly
|
||||
Securing the Apache ActiveMQ REST interface is very simple with the Wildfly
|
||||
Application Server. You turn on authentication for all URLs within your
|
||||
WAR's web.xml, and let the user Principal to propagate to ActiveMQ. This
|
||||
only works if you are using the JAASSecurityManager with ActiveMQ. See
|
||||
the ActiveMQ documentation for more details.
|
||||
WAR's web.xml, and let the user Principal to propagate to Apache ActiveMQ. This
|
||||
only works if you are using the JAASSecurityManager with Apache ActiveMQ. See
|
||||
the Apache ActiveMQ documentation for more details.
|
||||
|
||||
### Security in other environments
|
||||
|
||||
To secure the ActiveMQ REST interface in other environments you must
|
||||
To secure the Apache 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:
|
||||
|
@ -1430,7 +1430,7 @@ is a list of URI patterns:
|
|||
|
||||
## Mixing JMS and REST
|
||||
|
||||
The ActiveMQ REST interface supports mixing JMS and REST producers and
|
||||
The Apache 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
|
||||
|
@ -1439,10 +1439,10 @@ installed.
|
|||
|
||||
### JMS Producers - REST Consumers
|
||||
|
||||
If you have a JMS producer, the ActiveMQ REST interface only supports
|
||||
If you have a JMS producer, the Apache 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 ActiveMQ REST
|
||||
Java object should be translated into by REST clients. The Apache 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.
|
||||
|
@ -1460,7 +1460,7 @@ push registration should be set to the desired type.
|
|||
### REST Producers - JMS Consumers
|
||||
|
||||
If you have a REST client producing messages and a JMS consumer,
|
||||
ActiveMQ REST has a simple helper class for you to transform the HTTP
|
||||
Apache ActiveMQ REST has a simple helper class for you to transform the HTTP
|
||||
body to a Java object. Here's some example code:
|
||||
|
||||
public void onMessage(Message message)
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Security
|
||||
|
||||
This chapter describes how security works with ActiveMQ and how you can
|
||||
This chapter describes how security works with Apache ActiveMQ and how you can
|
||||
configure it. To disable security completely simply set the
|
||||
`security-enabled` property to false in the `activemq-configuration.xml`
|
||||
file.
|
||||
|
@ -12,15 +12,15 @@ is `10000` ms.
|
|||
|
||||
## Role based security for addresses
|
||||
|
||||
ActiveMQ contains a flexible role-based security model for applying
|
||||
Apache ActiveMQ contains a flexible role-based security model for applying
|
||||
security to queues, based on their addresses.
|
||||
|
||||
As explained in [Using Core](using-core.md), ActiveMQ core consists mainly of sets of queues bound
|
||||
As explained in [Using Core](using-core.md), Apache 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.
|
||||
|
||||
ActiveMQ allows sets of permissions to be defined against the queues
|
||||
Apache 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
|
||||
'`*`'.
|
||||
|
@ -83,7 +83,7 @@ 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. ActiveMQ ships with a user manager that reads user
|
||||
security manager. Apache 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.
|
||||
|
||||
|
@ -124,14 +124,14 @@ in sub-groups of addresses.
|
|||
|
||||
When messaging clients are connected to servers, or servers are
|
||||
connected to other servers (e.g. via bridges) over an untrusted network
|
||||
then ActiveMQ allows that traffic to be encrypted using the Secure
|
||||
then Apache ActiveMQ allows that traffic to be encrypted using the Secure
|
||||
Sockets Layer (SSL) transport.
|
||||
|
||||
For more information on configuring the SSL transport, please see [Configuring the Transport](configuring-transports.md).
|
||||
|
||||
## Basic user credentials
|
||||
|
||||
ActiveMQ ships with a security manager implementation that reads user
|
||||
Apache ActiveMQ ships with a security manager implementation that reads user
|
||||
credentials, i.e. user names, passwords and role information from properties
|
||||
files on the classpath called `activemq-users.properties` and `activemq-roles.properties`. This is the default security manager.
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## Guarantees of Transaction Completion
|
||||
|
||||
When committing or rolling back a transaction with ActiveMQ, the request
|
||||
When committing or rolling back a transaction with Apache 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.
|
||||
|
@ -27,7 +27,7 @@ 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,
|
||||
ActiveMQ can be configured to block the call to send until the message
|
||||
Apache 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 following two parameters:
|
||||
|
@ -49,7 +49,7 @@ network round trip time (RTT) of 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
|
||||
ActiveMQ's advanced *asynchronous send acknowledgements feature*
|
||||
Apache ActiveMQ's advanced *asynchronous send acknowledgements feature*
|
||||
described in Asynchronous Send Acknowledgements.
|
||||
|
||||
If you are using JMS and JNDI then using the elements
|
||||
|
@ -73,7 +73,7 @@ The default value for this parameter is `true`.
|
|||
## Guarantees of Non Transactional Acknowledgements
|
||||
|
||||
If you are acknowledging the delivery of a message at the client side
|
||||
using a non transacted session, ActiveMQ can be configured to block the
|
||||
using a non transacted session, Apache 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
|
||||
|
@ -87,7 +87,7 @@ implement a strict *at most once* delivery policy. The default value is
|
|||
|
||||
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
|
||||
Guarantees of Non Transactional Message Sends, you can configure ActiveMQ to block the call to send until the server
|
||||
Guarantees of Non Transactional Message Sends, you can configure Apache 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
|
||||
|
@ -108,8 +108,8 @@ 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, ActiveMQ provides an advanced new feature called
|
||||
*asynchronous send acknowledgements*. With this feature, ActiveMQ can be
|
||||
To remedy this, Apache ActiveMQ provides an advanced new feature called
|
||||
*asynchronous send acknowledgements*. With this feature, Apache 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
|
||||
|
@ -132,7 +132,7 @@ a handler instance on your `ClientSession`.
|
|||
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 ActiveMQ calling your handler's
|
||||
informed at the client side by Apache ActiveMQ calling your handler's
|
||||
`sendAcknowledged(ClientMessage message)` method, passing in a reference
|
||||
to the message that was sent.
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
#Detecting Slow Consumers
|
||||
|
||||
In this section we will discuss how ActiveMQ can be configured to deal
|
||||
In this section we will discuss how Apache 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
|
||||
|
|
|
@ -1,11 +1,11 @@
|
|||
# Spring Integration
|
||||
|
||||
ActiveMQ provides a simple bootstrap class,
|
||||
Apache ActiveMQ provides a simple bootstrap class,
|
||||
`org.apache.activemq.integration.spring.SpringJmsBootstrap`, for
|
||||
integration with Spring. To use it, you configure ActiveMQ as you always
|
||||
integration with Spring. To use it, you configure Apache ActiveMQ as you always
|
||||
would, through its various configuration files like
|
||||
`activemq-configuration.xml`, `activemq-jms.xml`, and
|
||||
`activemq-users.xml`. The Spring helper class starts the ActiveMQ server
|
||||
`activemq-users.xml`. The Spring helper class starts the Apache 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:
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Thread management
|
||||
|
||||
This chapter describes how ActiveMQ uses and pools threads and how you
|
||||
This chapter describes how Apache 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,
|
||||
|
@ -8,12 +8,12 @@ then we'll look at the client side.
|
|||
|
||||
## Server-Side Thread Management
|
||||
|
||||
Each ActiveMQ Server maintains a single thread pool for general use, and
|
||||
Each Apache 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. ActiveMQ can
|
||||
A separate thread pool is also used to service connections. Apache 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.
|
||||
|
@ -33,7 +33,7 @@ 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), ActiveMQ will, by default, cap its thread pool
|
||||
When using new IO (NIO), Apache 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
|
||||
|
@ -96,7 +96,7 @@ For more information on configuring the reaper, please see ?.
|
|||
|
||||
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 ActiveMQ-AIO-poller-pool. ActiveMQ uses one thread per opened
|
||||
prefix ActiveMQ-AIO-poller-pool. Apache 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
|
||||
|
@ -106,14 +106,14 @@ ActiveMQ-AIO-writer-pool.
|
|||
|
||||
## Client-Side Thread Management
|
||||
|
||||
On the client side, ActiveMQ maintains a single static scheduled thread
|
||||
On the client side, Apache 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 ActiveMQ can also be configured so that each
|
||||
If required Apache 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
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Tools
|
||||
|
||||
ActiveMQ ships with several helpful command line tools. All tools are
|
||||
Apache 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
|
||||
|
@ -50,7 +50,7 @@ by eliminating the need so specify a classpath. These tools are:
|
|||
|
||||
- **`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 ActiveMQ server via Netty to import all the data. It
|
||||
connects to an Apache ActiveMQ server via Netty to import all the data. It
|
||||
takes 5 parameters:
|
||||
|
||||
- `input-file` - the path to the XML file generated by the
|
||||
|
|
|
@ -1,13 +1,13 @@
|
|||
# Resource Manager Configuration
|
||||
|
||||
ActiveMQ has its own Resource Manager for handling the lifespan of JTA
|
||||
Apache 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 ActiveMQ can, if configured, scan for old transactions
|
||||
To cope with this Apache 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`
|
||||
|
@ -15,7 +15,7 @@ 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 ActiveMQ will not unilaterally rollback any XA
|
||||
Please note that Apache 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.
|
||||
|
|
|
@ -46,7 +46,7 @@ Delayed redelivery is defined in the address-setting configuration:
|
|||
|
||||
</address-setting>
|
||||
|
||||
If a `redelivery-delay` is specified, ActiveMQ will wait this delay
|
||||
If a `redelivery-delay` is specified, Apache ActiveMQ will wait this delay
|
||||
before redelivering the messages.
|
||||
|
||||
By default, there is no redelivery delay (`redelivery-delay`is set to
|
||||
|
@ -92,7 +92,7 @@ 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.
|
||||
|
||||
ActiveMQ's addresses can be assigned a dead letter address. Once the
|
||||
Apache 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 their queue and sent to the relevant
|
||||
dead letter address. These *dead letter* messages can later be consumed
|
||||
|
@ -144,7 +144,7 @@ that shows how dead letter is configured and used with JMS.
|
|||
|
||||
## Delivery Count Persistence
|
||||
|
||||
In normal use, ActiveMQ does not update delivery count *persistently*
|
||||
In normal use, Apache 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
|
||||
|
@ -160,7 +160,7 @@ 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, ActiveMQ allows to persist
|
||||
As this behavior breaks strict JMS semantics, Apache ActiveMQ allows to persist
|
||||
delivery count before message delivery but this feature is disabled by default
|
||||
due to performance implications.
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Using Core
|
||||
|
||||
ActiveMQ core is a completely JMS-agnostic messaging system with its own
|
||||
Apache 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
|
||||
|
@ -41,16 +41,16 @@ please consult the Javadoc.
|
|||
|
||||
- Messages can be specified with a priority value between 0 and 9. 0
|
||||
represents the lowest priority and 9 represents the highest.
|
||||
ActiveMQ will attempt to deliver higher priority messages before
|
||||
Apache ActiveMQ will attempt to deliver higher priority messages before
|
||||
lower priority ones.
|
||||
|
||||
- Messages can be specified with an optional expiry time. ActiveMQ
|
||||
- Messages can be specified with an optional expiry time. Apache ActiveMQ
|
||||
will not deliver messages after its expiry time has been exceeded.
|
||||
|
||||
- Messages also have an optional timestamp which represents the time
|
||||
the message was sent.
|
||||
|
||||
- ActiveMQ also supports the sending/consuming of very large messages
|
||||
- Apache ActiveMQ also supports the sending/consuming of very large messages
|
||||
much larger than can fit in available RAM at any one time.
|
||||
|
||||
### Address
|
||||
|
@ -132,7 +132,7 @@ ClientSession instances group ClientConsumers and ClientProducers.
|
|||
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 ActiveMQ feature, allows you to have full guarantees
|
||||
server. This unique Apache 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
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Using JMS
|
||||
|
||||
Although ActiveMQ provides a JMS agnostic messaging API, many users will
|
||||
Although Apache 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
|
||||
|
@ -8,7 +8,7 @@ systems provide a JMS API. If you are completely new to JMS we suggest
|
|||
you follow the [Oracle JMS tutorial](http://docs.oracle.com/javaee/7/tutorial/partmessaging.htm) -
|
||||
a full JMS tutorial is out of scope for this guide.
|
||||
|
||||
ActiveMQ also ships with a wide range of examples, many of which
|
||||
Apache 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
|
||||
|
@ -16,7 +16,7 @@ examples is available in [Examples](examples.md).
|
|||
|
||||
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 ActiveMQ without
|
||||
configure and use JNDI, and also how to use JMS with Apache ActiveMQ without
|
||||
using any JNDI.
|
||||
|
||||
A simple ordering system
|
||||
|
@ -42,18 +42,18 @@ JNDI Configuration
|
|||
The JMS specification establishes the convention that *administered
|
||||
objects* (i.e. JMS queue, topic and connection factory instances) are
|
||||
made available via the JNDI API. Brokers are free to implement JNDI as
|
||||
they see fit assuming the implementation fits the API. ActiveMQ does not
|
||||
they see fit assuming the implementation fits the API. Apache ActiveMQ does not
|
||||
have a JNDI server. Rather, it uses a client-side JNDI implementation
|
||||
that relies on special properties set in the environment to construct
|
||||
the appropriate JMS objects. In other words, no objects are stored in
|
||||
JNDI on the ActiveMQ server, instead they are simply instantiated on the
|
||||
JNDI on the Apache ActiveMQ server, instead they are simply instantiated on the
|
||||
client based on the provided configuration. Let's look at the different
|
||||
kinds of administered objects and how to configure them.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The following configuration properties *are strictly required when
|
||||
> ActiveMQ is running in stand-alone mode*. When ActiveMQ is integrated
|
||||
> Apache ActiveMQ is running in stand-alone mode*. When Apache ActiveMQ is integrated
|
||||
> to an application server (e.g. Wildfly) the application server itself
|
||||
> will almost certainly provide a JNDI client with its own properties.
|
||||
|
||||
|
@ -66,7 +66,7 @@ well as many other configuration parameters.
|
|||
|
||||
Here's a simple example of the JNDI context environment for a client
|
||||
looking up a connection factory to access an *embedded* instance of
|
||||
ActiveMQ:
|
||||
Apache ActiveMQ:
|
||||
|
||||
java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory
|
||||
connectionFactory.invmConnectionFactory=vm://0
|
||||
|
@ -224,7 +224,7 @@ connection factories, destinations can be configured using special
|
|||
properties in the JNDI context environment. The property *name* should
|
||||
follow the pattern: `queue.<jndi-binding>` or `topic.<jndi-binding>`.
|
||||
The property *value* should be the name of the queue hosted by the
|
||||
ActiveMQ server. For example, if the server had a JMS queue configured
|
||||
Apache ActiveMQ server. For example, if the server had a JMS queue configured
|
||||
like so:
|
||||
|
||||
<queue name="OrderQueue"/>
|
||||
|
@ -317,7 +317,7 @@ Although it is a very common JMS usage pattern to lookup JMS
|
|||
instances) from JNDI, in some cases you just think "Why do I need JNDI?
|
||||
Why can't I just instantiate these objects directly?"
|
||||
|
||||
With ActiveMQ you can do exactly that. ActiveMQ supports the direct
|
||||
With Apache ActiveMQ you can do exactly that. Apache ActiveMQ supports the direct
|
||||
instantiation of JMS Queue, Topic and ConnectionFactory instances, so
|
||||
you don't have to use JNDI at all.
|
||||
|
||||
|
|
|
@ -1,12 +1,12 @@
|
|||
# Using the Server
|
||||
|
||||
This chapter will familiarise you with how to use the ActiveMQ server.
|
||||
This chapter will familiarise you with how to use the Apache 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 ActiveMQ server
|
||||
we mean the ActiveMQ standalone server, in its default configuration
|
||||
For the remainder of this chapter when we talk about the Apache ActiveMQ server
|
||||
we mean the Apache ActiveMQ standalone server, in its default configuration
|
||||
with a JMS Service enabled.
|
||||
|
||||
## Starting and Stopping the standalone server
|
||||
|
@ -16,21 +16,21 @@ In the distribution you will find a directory called `bin`.
|
|||
`cd` into that directory and you will find a Unix/Linux script called
|
||||
`activemq` and a Windows script called `activemq.cmd`.
|
||||
|
||||
To start the ActiveMQ instance on Unix/Linux type `./activemq run`
|
||||
To start the Apache ActiveMQ instance on Unix/Linux type `./activemq run`
|
||||
|
||||
To start the ActiveMQ instance on Windows type `activemq.cmd run`
|
||||
To start the Apache 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](https://github.com/airlift/airline).
|
||||
|
||||
To stop the ActiveMQ instance you will use the same `activemq` script.
|
||||
To stop the Apache 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.
|
||||
Please note that Apache 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
|
||||
|
@ -43,7 +43,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 ActiveMQ runs in a maximum of 1GiB of RAM. To increase the
|
||||
By default Apache 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.
|
||||
|
||||
|
@ -77,7 +77,7 @@ JVM will use the environment variable `LD_LIBRARY_PATH`.
|
|||
|
||||
## System properties
|
||||
|
||||
ActiveMQ can take a system property on the command line for configuring
|
||||
Apache ActiveMQ can take a system property on the command line for configuring
|
||||
logging.
|
||||
|
||||
For more information on configuring logging, please see the section on
|
||||
|
@ -129,11 +129,11 @@ The bootstrap file is very simple. Let's take a look at an example:
|
|||
|
||||
## The main configuration file.
|
||||
|
||||
The configuration for the ActiveMQ core server is contained in
|
||||
The configuration for the Apache 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 ActiveMQ. In most
|
||||
There are many attributes which you can configure Apache 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
|
||||
|
|
|
@ -4,14 +4,14 @@
|
|||
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 ActiveMQ and route
|
||||
those messages to a specified vertx address by configuring ActiveMQ
|
||||
can now redirect and persist any vert.x messages to Apache ActiveMQ and route
|
||||
those messages to a specified vertx address by configuring Apache 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 ActiveMQ queue. Such a service can be configured as
|
||||
and route them to an Apache ActiveMQ queue. Such a service can be configured as
|
||||
follows:
|
||||
|
||||
<connector-service name="vertx-incoming-connector">
|
||||
|
@ -25,7 +25,7 @@ follows:
|
|||
|
||||
Shown are the required params for the connector service:
|
||||
|
||||
- `queue`. The name of the ActiveMQ queue to send message to.
|
||||
- `queue`. The name of the Apache ActiveMQ queue to send message to.
|
||||
|
||||
As well as these required parameters there are the following optional
|
||||
parameters
|
||||
|
@ -62,7 +62,7 @@ as follows:
|
|||
|
||||
Shown are the required params for the connector service:
|
||||
|
||||
- `queue`. The name of the ActiveMQ queue to fetch message from.
|
||||
- `queue`. The name of the Apache ActiveMQ queue to fetch message from.
|
||||
|
||||
As well as these required paramaters there are the following optional
|
||||
parameters
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Routing Messages With Wild Cards
|
||||
|
||||
ActiveMQ allows the routing of messages via wildcard addresses.
|
||||
Apache 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
|
||||
|
|
|
@ -1,11 +1,11 @@
|
|||
# Understanding the ActiveMQ Wildcard Syntax
|
||||
# Understanding the Apache ActiveMQ Wildcard Syntax
|
||||
|
||||
ActiveMQ uses a specific syntax for representing wildcards in security
|
||||
Apache 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](http://www.amqp.org).
|
||||
|
||||
An ActiveMQ wildcard expression contains words delimited by the character
|
||||
An Apache ActiveMQ wildcard expression contains words delimited by the character
|
||||
'`.`' (full stop).
|
||||
|
||||
The special characters '`#`' and '`*`' also have special meaning and can
|
||||
|
|
|
@ -25,7 +25,7 @@ under the License.
|
|||
<parent>
|
||||
<groupId>org.apache.activemq.examples.jms</groupId>
|
||||
<artifactId>jms-examples</artifactId>
|
||||
<version>6.0.0-SNAPSHOT</version>
|
||||
<version>${project.version}</version>
|
||||
</parent>
|
||||
|
||||
<artifactId>activemq-jms-queue-example</artifactId>
|
||||
|
|
Loading…
Reference in New Issue