#onenote# activemq



ActiveMQ is an open source, Java Message Service (JMS) 1.1–compliant, message-oriented middleware (MOM) from the Apache Software Foundation that provides high availability, performance, scalability, reliability, and security for enterprise messaging.


the job of a MOM is to mediate events and messages among distributed applications, guaranteeing that they reach their intended recipients. So it’s vital that a MOM be highly available, performant, and scalable.


  • JMS compliance A good starting point for understanding the features in ActiveMQ is that ActiveMQ is an implementation of the JMS 1.1 spec.  Adhering to the JMS spec for such features means that no matter what JMS provider is used, the same base set of features will be made available.


  • Connectivity ActiveMQ  provides a wide range of connectivity options, including support for protocols such as HTTP/S, IP multicast, SSL, STOMP, TCP, UDP, XMPP, and more


  • Pluggable persistence and security ActiveMQ provides multiple flavors of persistence and you can choose between them. Also, security in ActiveMQ can becompletely customized for the type of authentication and authorization that’s best for your needs. For example, ActiveMQ offers its own style of ultra-fast message persistence via KahaDB, but also supports standard JDBC-accessible databases. ActiveMQ also supports its own simple style of authentication and authorization using properties files as well as standard JAAS login module


  • Broker clustering Many ActiveMQ brokers can work together as a federated network of brokers for scalability purposes. This is known as a network of brokers and can support many different topologies



Summary of network protocols used for client-broker communication





Default network protocol for most use cases.



Consider NIO protocol if you need to provide better scalability for connections from producers and consumers to the broker.



Consider UDP protocol when you need to deal with the firewall between clients and the broker.



Consider SSL when you want to secure communication between clients and the broker.



Consider HTTP(S) when you need to deal with the firewall between clients and the broker.



Although not a network protocol per se, consider VM protocol when your broker and clients communicate with a broker that is embedded in the same Java Virtual Machine (JVM).



A note about the default keystores and truststores in ActiveMQ

The default keystores and truststores that are distributed with ActiveMQ are located in the ${ACTIVEMQ_HOME}/conf/directory. In that directory, you’ll find a keystore containing a default broker certificate (broker.ks) as well as a truststore used by the broker to hold trusted client certificates (broker.ts). By default, ActiveMQ will use broker.ks and broker.ts for the SSL transport connector. Please note that the default key-store and truststore are for demonstration purposes only and shouldn’t be used for the production deployment of ActiveMQ. For production use, it’s highly recommended that you create your own keystore and truststore.


Network connectors are channels that are configured between brokers so that those brokers can communicate with one another. A network connector is a unidirectional channel by default.


Static networks

The first approach to configuring and connecting to a network of brokers is through the use of statically configured URIs—configuring a list of broker URIs available for connection. The only prerequisite is that you know the addresses of all the brokers you want to use.


Failover Protocol

there are two ways to provide a list of suitable brokers to which the client can connect. In the first case, you provide a static list of available brokers. This is the approach used by the failover transport connector. In the second case,

dynamic discovery of the available brokers is used




The following URI will try to reestablish a connection to the same broker in the event that the broker shuts down for any reason:



ActiveMQ message storage

The JMS specification supports two types of message delivery: persistent and nonpersistent. A message delivered with the persistent delivery property must be logged to stable storage. For nonpersistent messages, a JMS provider must make best efforts to deliver the message, but it won’t be logged to stable storage


Persistent messages are used if you want messages to always be available to a message consumer after they’ve been delivered to the broker, even if that consumer isn’t running when the message was sent. Once a message has been consumed and acknowledged by a message consumer, it’s typically deleted from the broker’s message store.

Nonpersistent messages are typically used for sending notifications or real-time data. You should use nonpersistent messages when performance is critical and guaranteed delivery of the message isn’t required


Securing ActiveMQ

Authentication is the process used to verify the integrity of an entity or a user that’s requesting access to a secured resource. Some common forms of authentication include plain-text passwords, one-time password devices, smart cards, or Kerberos, just to name a few. ActiveMQ provides simple authentication and JAAS (Java Authentication and Authorization Service) authentication, as well as an API for writing custom authentication plug-ins. Upon successful authentication, access to the system is granted, but access to perform operations using the system resources may require specific authorization.

Authorization is the process used to determine the access rights of a user or an entity to a secured resource. Authorization depends upon authentication to prevent unauthorized users from entering the system, but authorization determines whether a user has the privileges to perform certain actions. For example, does user X have the necessary permissions to execute program Y on system Z? Such privileges are often referred to as access control lists (ACLs) and determine who or what can access a given resource to perform a given operation. In ActiveMQ, authentication involves restricting access to various operations including the ability to publish to a destination, to consume from a destination, to create a destination, or to delete a destination.


Configuring ActiveMQ for high availability

ActiveMQ currently supports two different types of master/slave configurations: shared nothing, where each ActiveMQ broker has its own unique message storage, and shared storage, where multiple ActiveMQ brokers can connect to the shared message store (a relational database or a shared file system) but only one broker will be active at a time. We’ll discuss these deployment scenarios in this section.


If the slave broker takes over the role of the master broker, all clients using the failover transport will fail over to the new master. For JMS clients to ActiveMQ, the default transport used by the client’s connection is the failover transport and is typically configured to be able to connect to both the master and the slave, as shown:



When to Use Shared Nothing Master/Slave

You should use a shared nothing master/slave configuration in production environments when some down time on failure is acceptable. Manual intervention by an administrator will be necessary after a master fails, as it would be advisable to set up and configure a new slave for the new master after the old master has failed.


When to Use Shared Database Master/Slave

Shared database master/slave is an ideal configuration if you’re already using an enterprise relational database. Although generally slower than a shared nothing configuration, it requires no additional configuration, and there are no limitations on the number of slave brokers that can be run or when they can be run.


When to Use Shared File System Master/Slave

Using a shared file system is probably the best solution for providing high availability for ActiveMQ to date. It combines the high throughput of KahaDB and the simplicity that you get from using a shared resource. KahaDB is only limited by the performance of the underlying shared file system. The only caveat is that you’re restricted to environments that support distributed locking on a shared file system.



Vertical scaling

Vertical scaling is a technique used to increase the number of connections (and therefore load) that a single ActiveMQ broker can handle. By default, the ActiveMQ broker is designed to move messages as efficiently as possible to ensure low latency and good performance. But you can make some configuration decisions to ensure that the ActiveMQ broker can handle both a large number of concurrent connections and a large number of queues.

By default, ActiveMQ will use blocking I/O to handle transport connections. This results in a thread being used per connection. You can use nonblocking I/O on the ActiveMQ broker (and still use the default transport on the client) to reduce the number of threads used. Nonblocking I/O can be configured via the transport connector in the ActiveMQ configuration file


Horizontal scaling

In addition to scaling a single broker, you can use networks to increase the number of ActiveMQ brokers available for your applications. As networks automatically pass messages to connected brokers that have interested consumers, you can configure your clients to connect to a cluster of brokers, selecting one at random to connect to. This can be configured using a URI parameter as shown:




Traffic partitioning

Client-side traffic partitioning is a hybrid of vertical and horizontal partitioning. Networks are typically not used, as the client application decides what traffic should go to which broker(s). The client application has to maintain multiple JMS connections, and decide which JMS connection should be used for which destinations.

The advantages of not directly using network connections is that you reduce the overhead of forwarding messages between brokers. You do need to balance that with the additional complexity that results in a typical application.


Tuning ActiveMQ for performance

The performance of ActiveMQ is highly dependent on a number of different factors, including the broker network topology, the transport, the quality of service and speed of the underlying network, hardware, operating system, and the Java Virtual Machine.


Definitely the first thing to consider if performance is going to be critical.

General techniques

  • Persistent versus nonpersistent messages
  • Transactions
  • Embedding brokers
  • Tuning the OpenWire protocol

It’s worth covering some of the options available on the OpenWire protocol. The OpenWire protocol is the binary format used for transporting commands over a transport (such as TCP) to the broker

  • Tuning the TCP transport

The most commonly used transport for ActiveMQ is the TCP transport. Two parameters directly affect performance for this transport:

  • socketBufferSize—The size of the buffers used to send and receive data over the TCP transport. Usually the bigger the better (though this is operating system dependent, so it’s worth testing!). The default value is 65536, which is the size in bytes.
  • tcpNoDelay—The default is false. Normally a TCP socket buffers up small pieces of data before being sent. When you enable this option, messages will be sent as soon as possible. Again, it’s worth testing this out, as whether this boosts performance can be operating system dependent.


ActiveMQ streams

ActiveMQ streams are an advanced feature that allows you to use an ActiveMQ client as a Java IOStream. ActiveMQ will break an OutputStream into distinct chunks of data and send each chunk through ActiveMQ as a JMS message. A corresponding ActiveMQ JMS InputStream should be used on the consumer side to reassemble the data chunks.


ActiveMQ breaks the stream into manageable chunks of data and sends each chunk of data as a separate message. This means that you have to be careful when using them, because if the message consumer should fail partway through reading the InputStream, there’s currently no way to replay the messages already consumed by the failed message consumer.

ActiveMQ streams are useful for transferring large payloads, though you’ll need to think about how an application using ActiveMQ streams should handle failure scenarios. There’s an alternative and more robust method of sending large payloads: using blob messages

Blob messages

ActiveMQ introduced the concept of blob messages so that users can take advantage of ActiveMQ message delivery semantics (transactions, load balancing, and smart routing) in conjunction with very large messages. A blob message doesn’t contain the data being sent, but is a notification that a blob (binary large object) is available. The blob itself is transferred out of bounds, by either FTP or HTTP. In fact, an ActiveMQ BlobMessage only contains the URL to the data itself, with a helper method to grab an InputStream to the real data. Let’s work through an example.



MOM  – Message-Oriented Middleware



In JMS a Topic implements publish and subscribe semantics. When you publish a message it goes to all the subscribers who are interested – so zero to many subscribers will receive a copy of the message. Only subscribers who had an active subscription at the time the broker receives the message will get a copy of the message.


A JMS Queue implements load balancer semantics. A single message will be received by exactly one consumer. If there are no consumers available at the time the message is sent it will be kept until a consumer is available that can process the message. If a consumer receives a message and does not acknowledge it before closing then the message will be redelivered to another consumer. A queue can have many consumers with messages load balanced across the available consumers.

So Queues implement a reliable load balancer in JMS.



Guaranteed Delivery


Use Guaranteed Delivery to make messages persistent so that they are not lost even if the messaging system crashes.

With Guaranteed Delivery, the messaging system uses a built-in data store to persist messages. Each computer the messaging system is installed on has its own data store so that the messages can be stored locally. When the sender sends a message, the send operation does not complete successfully until the message is safely stored in the sender’s data store. Subsequently, the message is not deleted from one data store until it is successfully forwarded to and stored in the next data store. In this way, once the sender successfully sends the message, it is always stored on disk on at least one computer until is successfully delivered to and acknowledged by the receiver.

Pasted from <http://www.enterpriseintegrationpatterns.com/GuaranteedMessaging.html>




JMS Spec:

Most clients should use producers that produce PERSISTENT messages. This insures once-and-only-once message delivery for messages delivered from a queue or a durable subscription.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s