Chapter 4. Intra-JVM Connections
Abstract
Red Hat JBoss A-MQ uses a VM transport to allow clients to connect to each other inside the Java Virtual Machine (JVM) without the overhead of network communication.
Overview
Red Hat JBoss A-MQ's VM transport enables Java clients running inside the same JVM to communicate with each other without having to resort to a using a network connection. The VM transport does this be implicitly creating an embedded broker the first time it is accessed. Figure 4.1, “Clients Connected through the VM Transport” shows the basic architecture of the VM protocol.
Figure 4.1. Clients Connected through the VM Transport
Embedded brokers
The VM transport uses a broker embedded in the same JVM as the clients to facilitate communication between the clients. The embedded broker can be created in several ways:
- explicitly defining the broker in the application's configuration
- explicitly creating the broker using the Java APIs
- automatically when the first client attempts to connect to it using the VM transport
The VM transport uses the broker name to determine if an embedded broker needs to be created. When a client uses the VM transport to connect to a broker, the transport checks to see if an embedded broker by that name already exists. If it does exist, the client is connected to the broker. If it does not exist, the broker is created and then the client is connected to it.
Important
When using explicitly created brokers there is a danger that your clients will attempt to connect to the embedded broker before it is started. If this happens, the VM transport will auto-create an instance of the broker for you. To avoid this conflict you can set the
waitForStart option or the create=false option to manage how the VM transport determines when to create a new embedded broker.
Using the VM transport
The URI used to specify the VM transport comes in two flavors to provide maximum control over how the embedded broker is configured:
- simpleThe simple VM URI is used in most situations. It allows you to specify the name of the embedded broker to which the client will connect. It also allows for some basic broker configuration.Example 4.1, “Simple VM URI Syntax” shows the syntax for a simple VM URI.
Example 4.1. Simple VM URI Syntax
vm://BrokerName?TransportOptions
- BrokerName specifies the name of the embedded broker to which the client connects.
- TransportOptions specifies the configuration for the transport. They are specified in the form of a query list. For details about the available options see the Connection Reference.ImportantThe broker configuration options specified on the VM URI are only meaningful if the client is responsible for instantiating the embedded broker. If the embedded broker is already started, the transport will ignore the broker configuration properties.
- advancedThe advanced VM URI provides you full control over how the embedded broker is configured. It uses a broker configuration URI similar to the one used by the administration tool to configure the embedded broker.Example 4.2, “Advanced VM URI Syntax” shows the syntax for an advanced VM URI.
Example 4.2. Advanced VM URI Syntax
vm://(BrokerConfigURI)?TransportOptions
- BrokerConfigURI is a broker configuration URI.
- TransportOptions specifies the configuration for the transport. They are specified in the form of a query list. For details about the available options see the Connection Reference.
Examples
Example 4.3, “Basic VM URI” shows a basic VM URI that connects to an embedded broker named
broker1.
Example 4.3. Basic VM URI
vm://broker1
Example 4.4, “Simple URI with broker options” creates and connects to an embedded broker that uses a non-persistent message store.
Example 4.4. Simple URI with broker options
vm://broker1?broker.persistent=false
Example 4.5, “Advanced VM URI” creates and connects to an embedded broker configured using a broker configuration URI.
Example 4.5. Advanced VM URI
vm:(broker:(tcp://localhost:6000)?persistent=false)?marshal=false
