[ InAction Note ] Ch4. Connecting ActiveMQ - Connecting to ActiveMQ inside the virtual machine

Preface: 
The VM transport connector is used by Java applications to launch an embedded broker and connect to it. Use of the VM transport means that no network connections are created between clients and the embedded broker. Communication is performed through direct method invocations of the broker object. Because the network stack isn’t employed, performance improves significantly. The broker is started when the first connection is created using the VM protocol. All subsequent VM transport connections from the same virtual machine will connect to the same broker. 

A broker created using the VM protocol doesn’t lack any of the standard ActiveMQ features. So, for example, the broker can be configured with other transport connectors as well. When all clients that use the VM transport to the broker close their connections, the broker will automatically shut down. 

The URI syntax for the VM transport is as follows: 

vm://brokerName?key=value

The broker name plays an important role in the VM transport connector URI by uniquely identifying the broker. For example, you can create two different embedded brokers by specifying different broker names. This is the only required difference. 

Transport options are set using the query part of the URI, the same as the previously discussed transports. The complete reference for this connector can be found at the ActiveMQ website (http://mng.bz/716b). 

The important thing about options for the VM transport protocol is that you can use them to configure the broker to some extent. Options whose name begins with the prefix broker. are used to tune the broker. For example, the following URI starts up a broker with persistence disabled (message persistence is explained inchapter 5): 

vm://broker1?marshal=false&broker.persistent=false

There’s also an alternative URI syntax that can be used to configure an embedded broker: 

vm:broker:(transportURI,network:networkURI)/brokerName?key=value

The complete reference of the broker URI can be found at the ActiveMQ website (http://mng.bz/FNos). 

As you can see, this kind of URI can be used to configure additional transport connectors. Take a look at the following URI, for example: 

vm:broker:(tcp://localhost:6000)?brokerName=embeddedbroker&persistent=false

Here, we’ve defined an embedded broker named embeddedBroker and also configured a TCP transport connector that listens for connections on port 6000. Finally, persistence is also disabled in this broker. Figure 4.4 can help you better visualize this example configuration. This figure demonstrates that clients connecting to the broker from within the application that embeds the broker will use the VM transport, whereas external applications connect to that embedded broker using the TCP connector, just as they would in the case of any standalone broker. 
 

An embedded broker using an external configuration file can be achieved using the brokerConfig transport option and by specifying the URI for the activemq.xml file. Here’s an example: 

vm://localhost?brokerConfig=xbean:activemq.xml

The example will locate the activemq.xml file in the classpath using the xbean: protocol. Using this approach, an embedded broker can be configured just like a stand-alone broker using the XML configuration. 

Now the stock portfolio publisher can be started with an embedded broker using the following command: 

$ mvn exec:java -Dexec.mainClass=org.apache.activemq.book.ch4.Publisher -Dexec.args="vm://localhost CSCO ORCL"
...
Sending: {price=65.713356601409, stock=JAVA, offer=65.779069958011, up=true}
on destination: topic://STOCKS.JAVA

Note that the publisher works just fine without having to start an external broker. 

One obvious advantage of the VM transport is improved performance for client-to-broker communication. Also, you’ll have only one Java application to run (one JVM) instead of two, which can ease your deployment process. This also means that there’s one fewer Java process to manage. So, if you plan to use the broker mainly from one application, maybe you should consider using the embedded broker. Embedding ActiveMQ is covered in detail in chapter 8. 

On the other hand, if too many Java applications that use embedded brokers exist, maintenance problems may arise when trying to consistently configure each broker as well as back up the data. In such situations, it’s always easier to create a small cluster of standalone brokers instead of using embedded brokers. 

Having one ActiveMQ broker to serve all your application needs works well for most situations. But some environments need advanced features, such as high availability and larger scalability. This is typically achieved using what’s known as a network of brokers. In the following section you’ll learn about networks of brokers and network connectors used to configure those networks.