In This Section

Overview

The platform's loopback binding can be used to send to other applications running in the same process, not across different processes. This binding is often used for unit testing in which several applications may be launched in the same process for easy debugging.

When you configure a bus binding to use a loopback bus, a LoopbackBus instance is statically created on demand using the address provided by the binding. Two applications that connect to a loopback bus with the same name may exchange messages with one another.

Bus Descriptor Format

A loopback message bus can be configured via a descriptor string as follows which uses the address to indicate the loopback bus instance to which to connect followed by a list of provider properties.

loopback://<busname>&prop1=val1&propN=valN

An example bus descriptor for solace would like like:

loopback://<busname>&topic_starts_with_channel=false&set_bus_and_channel_on_receipt=true

DDL

In a DDL config file a solace bus can equivalently be configured in one of two ways

<buses>
  <bus name="my-bus">
    <provider>loopback</provider>
    <address>my-bus</address>
    <properties>
	   <topic_starts_with_channel>false<topic_starts_with_channel>
       <set_bus_and_channel_on_receipt>true<set_bus_and_channel_on_receipt>
    </properties>
    <channels>
      ...
    </channels>
  </bus>
</buses>

The descriptor form is useful in cases where the descriptor name may be supplied as an external configuration property that is substituted at runtime, but defaults to loopback for testing:

<buses>
  <bus name="my-bus" descriptor="${myBusDescriptor::solace://somehost:55555&amp;topic_starts_with_channel=false">
    <channels>
      ...
    </channels>
  </bus>
</buses>

Working with Loopback Buses

Loopback Bus Naming

When working with loopback buses it is sometimes useful to be able to look up a loopback by name. Loopback buses are named using their address (and optionally their port). If you have configured a loopback bus via loopback://my-bus, you can look up the bus as follows:

LoopbackBus bus = LoopbackBus.getInstance("my-bus");
StringBuilder dump = new StringBuilder();
bus.dumpPendingAck(dump);
System.out.println(dump.toString());

A loopback bus does not require a port to be specified in its configuration. If you do configure a Loopback bus with a port, the name of the loopback bus will include the port name. If you specify "loopback://my-bus:80" the name of the bus will be "my-bus:80". One consequence of this is that "loopback://my-bus:80" and "loopback://my-bus:90" represent 2 separate buses which cannot communicate with one another.

Other than contributing to the name of the bus the port has no functional significance.

Loopback Bus Topic Format

Loopback bus topics can be specified hierarchically with each level in the topic separated by a '/' character. A valid loopback topic may start with a '/', but it is not required.

Wildcard Topics

The loopback bus supports 2 wildcard character sequences that can be used in Channel Filters to match multiple sending topics. Wildcard characters are not applied to sent topics and are treated as character literals. The loopback binding implementation is sensitive to the following wildcards when nv.sma.cleanchannelfilter=true and will preserve these characters rather than replace them with an '_':

Wildcard

Description

*

Matches 0 or more characters within a topic level

For example orders/*gin*

would match sends to

orders/gin
orders/begin
orders/ginseng
orders/beginning

But not

orders
orders/in

...

Matches multiple topic levels and may only be used as the last leve in a topic filter strings

For example orders/...

would match sends to

orders/events/MSFT
orders/updates/APPL
orders/cancels/US/IBM

But not

orders
order-updates