Chapter 6. Monitoring and managing the router network


6.1. Logging

Logging enables you to diagnose error and performance issues with AMQ Interconnect.

AMQ Interconnect consists of internal modules that provide important information about the router. For each module, you can specify logging levels, the format of the log file, and the location to which the logs should be written.

6.1.1. Logging Modules

AMQ Interconnect logs are broken into different categories called logging modules. Each module provides important information about a particular aspect of AMQ Interconnect.

6.1.1.1. The DEFAULT Logging Module

The default module. This module applies defaults to all of the other logging modules.

6.1.1.2. The ROUTER Logging Module

This module provides information and statistics about the local router. This includes how the router connects to other routers in the network, and information about the remote destinations that are directly reachable from the router (link routes, waypoints, autolinks, and so on).

Example 6.1. Using the ROUTER log to trace connections and links

In this example, ROUTER logs show the lifecycle of a connection and a link that is associated with it.

2019-04-05 14:54:38.037248 -0400 ROUTER (info) [C1] Connection Opened: dir=in host=127.0.0.1:55440 vhost= encrypted=no auth=no user=anonymous container_id=95e55424-6c0a-4a5c-8848-65a3ea5cc25a props= 1
2019-04-05 14:54:38.038137 -0400 ROUTER (info) [C1][L6] Link attached: dir=in source={<none> expire:sess} target={$management expire:sess} 2
2019-04-05 14:54:38.041103 -0400 ROUTER (info) [C1][L6] Link lost: del=1 presett=0 psdrop=0 acc=1 rej=0 rel=0 mod=0 delay1=0 delay10=0 3
2019-04-05 14:54:38.041154 -0400 ROUTER (info) [C1] Connection Closed 4
1
The connection is opened. Each connection has a unique ID (C1). The log also shows some information about the connection.
2
A link is attached over the connection. The link is identified with a unique ID (L6). The log also shows the direction of the link, and the source and target addresses.
3
The link is detached. The log shows the link’s terminal statistics.
4
The connection is closed.

6.1.1.3. The ROUTER_HELLO Logging Module

This module provides information about the Hello protocol used by interior routers to exchange Hello messages, which include information about the router’s ID and a list of its reachable neighbors (the other routers with which this router has bidirectional connectivity).

The logs for this module are helpful for monitoring or resolving issues in the network topology, and for determining to which other routers a router is connected, and the hop-cost for each of those connections.

In this example, on Router.A, the ROUTER_HELLO log shows that it is connected to Router.B, and that Router.B is connected to Router.A and Router.C:

Tue Jun  7 13:50:21 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C']) 1
Tue Jun  7 13:50:21 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B']) 2
Tue Jun  7 13:50:22 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C'])
Tue Jun  7 13:50:22 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B'])
1
Router.A received a Hello message from Router.B, which can see Router.A and Router.C.
2
Router.A sent a Hello message to Router.B, which is the only router it can see.

On Router.B, the ROUTER_HELLO log shows the same router topology from a different perspective:

Tue Jun  7 13:50:18 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C']) 1
Tue Jun  7 13:50:18 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B']) 2
Tue Jun  7 13:50:19 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.C area=0 inst=1465307411 seen=['Router.B']) 3
1
Router.B sent a Hello message to Router.A and Router.C.
2
Router.B received a Hello message from Router.A, which can only see Router.B.
3
Router.B received a Hello message from Router.C, which can only see Router.B.

6.1.1.4. The ROUTER_LS Logging Module

This module provides information about link-state data between routers, including Router Advertisement (RA), Link State Request (LSR), and Link State Update (LSU) messages.

Periodically, each router sends an LSR to the other routers and receives an LSU with the requested information. Exchanging the above information, each router can compute the next hops in the topology, and the related costs.

This example shows the RA, LSR, and LSU messages sent between three routers:

Tue Jun  7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.C
Tue Jun  7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.B
Tue Jun  7 14:10:02 2016 ROUTER_LS (trace) SENT: RA(id=Router.A area=0 inst=1465308600 ls_seq=1 mobile_seq=1) 1
Tue Jun  7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSU(id=Router.B area=0 inst=1465308595 ls_seq=2 ls=LS(id=Router.B area=0 ls_seq=2 peers={'Router.A': 1L, 'Router.C': 1L})) 2
Tue Jun  7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSR(id=Router.B area=0)
Tue Jun  7 14:10:02 2016 ROUTER_LS (trace) SENT: LSU(id=Router.A area=0 inst=1465308600 ls_seq=1 ls=LS(id=Router.A area=0 ls_seq=1 peers={'Router.B': 1}))
Tue Jun  7 14:10:02 2016 ROUTER_LS (trace) RCVD: RA(id=Router.C area=0 inst=1465308592 ls_seq=1 mobile_seq=0)
Tue Jun  7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.C
Tue Jun  7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSR(id=Router.C area=0) 3
Tue Jun  7 14:10:02 2016 ROUTER_LS (trace) SENT: LSU(id=Router.A area=0 inst=1465308600 ls_seq=1 ls=LS(id=Router.A area=0 ls_seq=1 peers={'Router.B': 1}))
Tue Jun  7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSU(id=Router.C area=0 inst=1465308592 ls_seq=1 ls=LS(id=Router.C area=0 ls_seq=1 peers={'Router.B': 1L})) 4
Tue Jun  7 14:10:03 2016 ROUTER_LS (trace) Computed next hops: {'Router.C': 'Router.B', 'Router.B': 'Router.B'} 5
Tue Jun  7 14:10:03 2016 ROUTER_LS (trace) Computed costs: {'Router.C': 2L, 'Router.B': 1}
Tue Jun  7 14:10:03 2016 ROUTER_LS (trace) Computed valid origins: {'Router.C': [], 'Router.B': []}
1
Router.A sent LSR requests and an RA advertisement to the other routers on the network.
2
Router.A received an LSU from Router.B, which has two peers: Router.A, and Router.C (with a cost of 1).
3
Router.A received an LSR from both Router.B and Router.C, and replied with an LSU.
4
Router.A received an LSU from Router.C, which only has one peer: Router.B (with a cost of 1).
5
After the LSR and LSU messages are exchanged, Router.A computed the router topology with the related costs.

6.1.1.5. The ROUTER_MA Logging Module

This module provides information about the exchange of mobile address information between routers, including Mobile Address Request (MAR) and Mobile Address Update (MAU) messages exchanged between routers. You can use this log to monitor the state of mobile addresses attached to each router.

This example shows the MAR and MAU messages sent between three routers:

Tue Jun  7 14:27:20 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[]) 1
Tue Jun  7 14:27:21 2016 ROUTER_MA (trace) RCVD: MAR(id=Router.C area=0 have_seq=0) 2
Tue Jun  7 14:27:21 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[])
Tue Jun  7 14:27:22 2016 ROUTER_MA (trace) RCVD: MAR(id=Router.B area=0 have_seq=0) 3
Tue Jun  7 14:27:22 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[])
Tue Jun  7 14:27:39 2016 ROUTER_MA (trace) RCVD: MAU(id=Router.C area=0 mobile_seq=1 add=['M0my_test'] del=[]) 4
Tue Jun  7 14:27:51 2016 ROUTER_MA (trace) RCVD: MAU(id=Router.C area=0 mobile_seq=2 add=[] del=['M0my_test']) 5
1
Router.A sent MAU messages to the other routers in the network to notify them about the addresses added for my_queue and my_queue_wp.
2
Router.A received a MAR message in response from Router.C.
3
Router.A received another MAR message in response from Router.B.
4
Router.C sent a MAU message to notify the other routers that it added and address for my_test.
5
Router.C sent another MAU message to notify the other routers that it deleted the address for my_test (because the receiver is detached).

6.1.1.6. The MESSAGE Logging Module

This module provides information about AMQP messages sent and received by the router, including information about the address, body, and link. You can use this log to find high-level information about messages on a particular router.

In this example, Router.A has sent and received some messages related to the Hello protocol, and sent and received some other messages on a link for a mobile address:

Tue Jun  7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_topo/0/Router.B/qdrouter' body='\d1\00\00\00\1b\00\00\00\04\a1\02id\a1\08R'} on link qdlink.p9XmBm19uDqx50R
Tue Jun  7 14:36:54 2016 MESSAGE (trace) Received Message{to='amqp:/_topo/0/Router.A/qdrouter' body='\d1\00\00\00\8e\00\00\00
\a1\06ls_se'} on link qdlink.phMsJOq7YaFsGAG
Tue Jun  7 14:36:54 2016 MESSAGE (trace) Received Message{ body='\d1\00\00\00\10\00\00\00\02\a1\08seque'} on link qdlink.FYHqBX+TtwXZHfV
Tue Jun  7 14:36:54 2016 MESSAGE (trace) Sending Message{ body='\d1\00\00\00\10\00\00\00\02\a1\08seque'} on link qdlink.yU1tnPs5KbMlieM
Tue Jun  7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_local/qdhello' body='\d1\00\00\00G\00\00\00\08\a1\04seen\d0'} on link qdlink.p9XmBm19uDqx50R
Tue Jun  7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_topo/0/Router.C/qdrouter' body='\d1\00\00\00\1b\00\00\00\04\a1\02id\a1\08R'} on link qdlink.p9XmBm19uDqx50R

6.1.1.7. The SERVER Logging Module

This module provides information about how the router is listening for and connecting to other containers in the network (such as clients, routers, and brokers). This information includes the state of AMQP messages sent and received by the broker (open, begin, attach, transfer, flow, and so on), and the related content of those messages.

For example, this log shows details about how the router handled a link attachment:

Tue Jun  7 14:39:52 2016 SERVER (trace) [2]:  <- AMQP
Tue Jun  7 14:39:52 2016 SERVER (trace) [1]:  <- AMQP
Tue Jun  7 14:39:52 2016 SERVER (trace) [1]:0 <- @open(16) [container-id="Router.B", max-frame-size=16384, channel-max=32767, idle-time-out=8000, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router", :version="0.6.0"}]
Tue Jun  7 14:39:52 2016 SERVER (trace) [1]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=15, outgoing-window=2147483647]
Tue Jun  7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x1e\x02\x00\x00\x00\x00S\x11\xd0\x00\x00\x00\x0e\x00\x00\x00\x04@R\x00R\x0fp\x7f\xff\xff\xff"
Tue Jun  7 14:39:52 2016 SERVER (trace) [1]:1 -> @begin(17) [next-outgoing-id=0, incoming-window=15, outgoing-window=2147483647]
Tue Jun  7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x1e\x02\x00\x00\x01\x00S\x11\xd0\x00\x00\x00\x0e\x00\x00\x00\x04@R\x00R\x0fp\x7f\xff\xff\xff"
Tue Jun  7 14:39:52 2016 SERVER (trace) [1]:0 -> @attach(18) [name="qdlink.uSSeXPSfTHhxo8d", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, capabilities=:"qd.router"], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, capabilities=:"qd.router"], initial-delivery-count=0]
Tue Jun  7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x91\x02\x00\x00\x00\x00S\x12\xd0\x00\x00\x00\x81\x00\x00\x00\x0a\xa1\x16qdlink.uSSeXPSfTHhxo8dR\x00AP\x02P\x00\x00S(\xd0\x00\x00\x00'\x00\x00\x00\x0b@R\x00\xa3\x0blink-detachR\x00B@@@@@\xa3\x09qd.router\x00S)\xd0\x00\x00\x00#\x00\x00\x00\x07@R\x00\xa3\x0blink-detachR\x00B@\xa3\x09qd.router@@R\x00"

6.1.1.8. The AGENT Logging Module

This module provides information about configuration changes made to the router from either editing the router’s configuration file or using qdmanage.

In this example, on Router.A, address, linkRoute, and autoLink entities were added to the router’s configuration file. When the router was started, the AGENT module applied these changes, and they are now viewable in the log:

Tue Jun  7 15:07:32 2016 AGENT (debug) Add entity: ConnectorEntity(addr=127.0.0.1, allowRedirect=True, cost=1, host=127.0.0.1, identity=connector/127.0.0.1:5672:BROKER, idleTimeoutSeconds=16, maxFrameSize=65536, name=BROKER, port=5672, role=route-container, stripAnnotations=both, type=org.apache.qpid.dispatch.connector, verifyHostname=True)
Tue Jun  7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAddressEntity(distribution=closest, identity=router.config.address/0, name=router.config.address/0, prefix=my_address, type=org.apache.qpid.dispatch.router.config.address, waypoint=False)
Tue Jun  7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAddressEntity(distribution=balanced, identity=router.config.address/1, name=router.config.address/1, prefix=my_queue_wp, type=org.apache.qpid.dispatch.router.config.address, waypoint=True)
Tue Jun  7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigLinkrouteEntity(connection=BROKER, direction=in, distribution=linkBalanced, identity=router.config.linkRoute/0, name=router.config.linkRoute/0, prefix=my_queue, type=org.apache.qpid.dispatch.router.config.linkRoute)
Tue Jun  7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigLinkrouteEntity(connection=BROKER, direction=out, distribution=linkBalanced, identity=router.config.linkRoute/1, name=router.config.linkRoute/1, prefix=my_queue, type=org.apache.qpid.dispatch.router.config.linkRoute)
Tue Jun  7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAutolinkEntity(address=my_queue_wp, connection=BROKER, direction=in, identity=router.config.autoLink/0, name=router.config.autoLink/0, type=org.apache.qpid.dispatch.router.config.autoLink)
Tue Jun  7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAutolinkEntity(address=my_queue_wp, connection=BROKER, direction=out, identity=router.config.autoLink/1, name=router.config.autoLink/1, type=org.apache.qpid.dispatch.router.config.autoLink)

6.1.1.9. The CONTAINER Logging Module

This module provides information about the nodes related to the router. This includes only the AMQP relay node.

Tue Jun  7 14:46:18 2016 CONTAINER (trace) Container Initialized
Tue Jun  7 14:46:18 2016 CONTAINER (trace) Node Type Registered - router
Tue Jun  7 14:46:18 2016 CONTAINER (trace) Node of type 'router' installed as default node

6.1.1.10. The ERROR Logging Module

This module provides detailed information about error conditions encountered during execution.

In this example, Router.A failed to start when an incorrect path was specified for the router’s configuration file:

$ sudo qdrouterd --conf xxx
Wed Jun 15 09:53:28 2016 ERROR (error) Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
Wed Jun 15 09:53:28 2016 ERROR (error) Traceback (most recent call last):
  File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 155, in configure_dispatch
    config = Config(filename)
  File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 41, in __init__
    self.load(filename, raw_json)
  File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 123, in load
    with open(source) as f:
Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'

Wed Jun 15 09:53:28 2016 MAIN (critical) Router start-up failed: Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
qdrouterd: Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'

6.1.1.11. The POLICY Logging Module

This module provides information about policies that have been configured for the router.

In this example, Router.A has no limits on maximum connections, and the default application policy is disabled:

Tue Jun  7 15:07:32 2016 POLICY (info) Policy configured maximumConnections: 0, policyFolder: '', access rules enabled: 'false'
Tue Jun  7 15:07:32 2016 POLICY (info) Policy fallback defaultApplication is disabled

6.1.2. Configuring Logging

You can specify the types of events that should be logged, the format of the log entries, and where those entries should be sent.

Procedure

  1. In the router’s configuration file, add a log section to set the default logging properties:

    log {
        module: DEFAULT
        enable: LOGGING_LEVEL
        includeTimestamp: yes
        ...
    }
    module
    Specify DEFAULT.
    enable

    The logging level. You can specify any of the following levels (from lowest to highest):

    • trace - provides the most information, but significantly affects system performance
    • debug - useful for debugging, but affects system performance
    • info - provides general information without affecting system performance
    • notice - provides general information, but is less verbose than info
    • warning - provides information about issues you should be aware of, but which are not errors
    • error - error conditions that you should address
    • critical - critical system issues that you must address immediately

    To specify multiple levels, use a comma-separated list. You can also use + to specify a level and all levels above it. For example, trace,debug,warning+ enables trace, debug, warning, error, and critical levels. For default logging, you should typically use the info+ or notice+ level. These levels will provide general information, warnings, and errors for all modules without affecting the performance of AMQ Interconnect.

    includeTimestamp
    Set this to yes to include the timestamp in all logs.

    For information about additional log attributes, see log in the qdrouterd.conf man page.

  2. Add an additional log section for each logging module that should not follow the default logging configuration:

    log {
        module: MODULE_NAME
        enable: LOGGING_LEVEL
        ...
    }
    module
    The name of the module for which you are configuring logging. For a list of valid modules, see Section 6.1.1, “Logging Modules”.
    enable

    The logging level. You can specify any of the following levels (from lowest to highest):

    • trace - provides the most information, but significantly affects system performance
    • debug - useful for debugging, but affects system performance
    • info - provides general information without affecting system performance
    • notice - provides general information, but is less verbose than info
    • warning - provides information about issues you should be aware of, but which are not errors
    • error - error conditions that you should address
    • critical - critical system issues that you must address immediately

    To specify multiple levels, use a comma-separated list. You can also use + to specify a level and all levels above it. For example, trace,debug,warning+ enables trace, debug, warning, error, and critical levels. For default logging, you should typically use the info+ or notice+ level. These levels will provide general information, warnings, and errors for all modules without affecting the performance of AMQ Interconnect.

    For information about additional log attributes, see log in the qdrouterd.conf man page.

6.1.3. Viewing Log Entries

You may need to view log entries to diagnose errors, performance problems, and other important issues. A log entry consists of an optional timestamp, the logging module, the logging level, and the log message.

6.1.3.1. Viewing Log Entries on the Console

By default, log entries are logged to the console, and you can view them there. However, if the output attribute is set for a particular logging module, then you can find those log entries in the specified location (stderr, syslog, or a file).

6.1.3.2. Viewing Log Entries on the CLI

You can use the qdstat tool to view a list of recent log entries.

Procedure

  • Use the qdstat --log command to view recent log entries.

    You can use the --limit parameter to limit the number of log entries that are displayed. For more information about qdstat, see qdstat man page.

    This example displays the last three log entries for Router.A:

    $ qdstat --log --limit=3 -r ROUTER.A
    Wed Jun  7 17:49:32 2017 ROUTER (none) Core action 'link_deliver'
    Wed Jun  7 17:49:32 2017 ROUTER (none) Core action 'send_to'
    Wed Jun  7 17:49:32 2017 SERVER (none) [2]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1, link-credit=250, drain=false]

6.2. Using AMQ Console

AMQ Console is a web console for monitoring the status and performance of AMQ Interconnect router networks.

Prerequisites

6.2.1. Setting up access to the web console

Before you can access the web console, you must configure a listener to accept HTTP connections for the web console and serve the console files.

Procedure

  1. On the router from which you want to access the web console, open the /etc/qpid-dispatch/qdrouterd.conf configuration file.
  2. Add a listener to serve the console.

    This example creates a listener that clients can use to access the web console:

    listener {
        host: 0.0.0.0
        port: 8672
        role: normal
        http: true
        httpRootDir: /usr/share/qpid-dispatch/console
    }
    host
    The IP address (IPv4 or IPv6) or hostname on which the router will listen.
    port
    The port number or symbolic service name on which the router will listen.
    role
    The role of the connection. Specify normal to indicate that this connection is used for client traffic.
    http
    Set this attribute to true to specify that this listener should accept HTTP connections instead of plain AMQP connections.
    httpRootDir
    Specify the absolute path to the directory that contains the web console HTML files. The default directory is /usr/share/qpid-dispatch/console.
  3. If you want to secure access to the console, secure the listener.

    For more information, see Section 4.3.2, “Securing incoming client connections”. This example adds basic user name and password authentication using SASL PLAIN:

    listener {
        host: 0.0.0.0
        port: 8672
        role: normal
        http: true
        httpRootDir: /usr/share/qpid-dispatch/console
        authenticatePeer: yes
        saslMechanisms: PLAIN
    }
  4. If you want to set up access to the web console from any other router in the router network, repeat this procedure for each router.

6.2.2. Accessing the web console

You can access the web console from a web browser.

Procedure

  1. In a web browser, navigate to the web console URL.

    The web console URL is the <host>:<port> from the listener that you created to serve the web console. For example: localhost:8672.

    The AMQ Console opens. If you set up user name and password authentication, the Connect tab is displayed.

  2. If necessary, log in to the web console.

    If you set up user name and password authentication, enter your user name and password to access the web console.

    The syntax for the user name is <user>@<domain>. For example: admin@my-domain.

6.2.3. Monitoring the router network using the web console

In the web console, you use the tabs to monitor the router network.

This tab…​Provides…​

Overview

Aggregated information about routers, addresses, links, connections, and logs.

Entities

Detailed information about each AMQP management entity for each router in the router network. Some of the attributes have charts that you can add to the Charts tab.

Topology

A graphical view of the router network, including routers, clients, and brokers. The topology shows how the routers are connected, and how messages are flowing through the network.

Charts

Graphs of the information selected on the Entities tab.

Message Flow

A chord diagram showing the real-time message flow by address.

Schema

The management schema that controls each of the routers in the router network.

6.2.4. Closing a connection

If a consumer is processing messages too slowly, or has stopped processing messages without settling its deliveries, you can close the connection. When you close the connection, the "stuck" deliveries are released (meaning they are not delivered to any consumers).

Procedure

  1. Identify any connections with slow or stuck consumers.

    1. Navigate to Overview Connections.
    2. Click a connection, and then click Links.

      The Rate, Delayed 10 sec, and Delayed 1 sec columns indicate if there are any slow or stuck consumers on the connection.

  2. Click Close to close the connection.

6.3. Monitoring AMQ Interconnect Using qdstat

You can use qdstat to view the status of routers on your router network. For example, you can view information about the attached links and configured addresses, available connections, and nodes in the router network.

6.3.1. Syntax for Using qdstat

You can use qdstat with the following syntax:

$ qdstat OPTION [CONNECTION_OPTIONS] [SECURE_CONNECTION_OPTIONS]

This specifies:

  • An option for the type of information to view.
  • One or more optional connection_options to specify a router for which to view the information.

    If you do not specify a connection option, qdstat connects to the router listening on localhost and the default AMQP port (5672).

  • The secure_connection_options if the router for which you want to view information only accepts secure connections.

For more information about qdstat, see the qdstat man page.

6.3.2. Viewing General Statistics for a Router

You can view information about a router in the router network, such as its working mode and ID.

Procedure

  • Use the following command:

    $ qdstat -g [CONNECTION_OPTIONS]

    This example shows general statistics for the local router:

    $ qdstat -g
    Router Statistics
      attr                             value
      =============================================
      Version                          1.2.0
      Mode                             standalone
      Router Id                        Router.A
      Link Routes                      0
      Auto Links                       0
      Links                            2
      Nodes                            0
      Addresses                        4
      Connections                      1
      Presettled Count                 0
      Dropped Presettled Count         0
      Accepted Count                   2
      Rejected Count                   0
      Released Count                   0
      Modified Count                   0
      Ingress Count                    2
      Egress Count                     1
      Transit Count                    0
      Deliveries from Route Container  0
      Deliveries to Route Container    0

6.3.3. Viewing a List of Connections to a Router

You can view:

  • Connections from clients (sender/receiver)
  • Connections from and to other routers in the network
  • Connections to other containers (such as brokers)
  • Connections from the tool itself

Procedure

  • Use this command:

    $ qdstat -c [CONNECTION_OPTIONS]

    For more information about the fields displayed by this command, see the qdstat -c output columns.

    In this example, two clients are connected to Router.A. Router.A is connected to Router.B and a broker.

    Viewing the connections on Router.A displays the following:

    $ qdstat -c -r Router.A
    Connections
    id    host                        container                              role             dir  security     authentication  tenant
    ==================================================================================================================================
      2   127.0.0.1:5672                                                     route-container  out  no-security  anonymous-user   1
      10  127.0.0.1:5001               Router.B                              inter-router     out  no-security  anonymous-user   2
      12  localhost.localdomain:42972  161211fe-ba9e-4726-9996-52d6962d1276  normal           in   no-security  anonymous-user   3
      14  localhost.localdomain:42980  a35fcc78-63d9-4bed-b57c-053969c38fda  normal           in   no-security  anonymous-user   4
      15  localhost.localdomain:42982  0a03aa5b-7c45-4500-8b38-db81d01ce651  normal           in   no-security  anonymous-user   5
    1
    This connection shows that Router.A is connected to a broker, because the role is route-container, and the dir is out.
    2
    Router.A is also connected to another router on the network (the role is inter-router), establishing an output connection (the dir is out).
    3 4
    These connections show that two clients are connected to Router.A, because the role is normal, and the dir is in.
    5
    The connection from qdstat to Router.A. This is the connection that qdstat uses to query Router.A and display the command output.

    Router.A is connected to Router.B. Viewing the connections on Router.B displays the following:

    $ qdstat -c -r Router.B
    Connections
    id    host                         container  role          dir  security     authentication  tenant
    ====================================================================================================
      1   localhost.localdomain:51848  Router.A   inter-router  in   no-security  anonymous-user    1
    1
    This connection shows that Router.B is connected to Router.A through an incoming connection (the role is inter-router and the dir is in). There is not a connection from qdstat to Router.B, because the command was run from Router.A and forwarded to Router.B.

6.3.5. Viewing Known Routers on a Network

To see the topology of the router network, you can view known routers on the network.

Procedure

  • Use this command:

    $ qdstat -n [CONNECTION_OPTIONS]

    For more information about the fields displayed by this command, see the qdstat -n output columns.

    In this example, Router.A is connected to Router.B, which is connected to Router.C. Viewing the router topology on Router.A shows the following:

    $ qdstat -n -r Router.A
    Routers in the Network
      router-id  next-hop  link  cost  neighbors                 valid-origins
      ==========================================================================
      Router.A   (self)    -           ['Router.B']              [] 1
      Router.B   -         0     1     ['Router.A', 'Router.C']  [] 2
      Router.C   Router.B  -     2     ['Router.B']              [] 3
    1
    Router.A has one neighbor: Router.B.
    2
    Router.B is connected to Router.A and Router.C over link 0. The cost for Router.A to reach Router.B is 1, because the two routers are connected directly.
    3
    Router.C is connected to Router.B, but not to Router.A. The cost for Router.A to reach Router.C is 2, because messages would have to pass through Router.B as the next-hop.

    Router.B shows a different view of the router topology:

    $ qdstat -n -v -r Router.B
    Routers in the Network
      router-id  next-hop  link  cost  neighbors                 valid-origins
      ==========================================================================
      Router.A   -         0     1     ['Router.B']              ['Router.C']
      Router.B   (self)    -           ['Router.A', 'Router.C']  []
      Router.C   -         1     1     ['Router.B']              ['Router.A']

    The neighbors list is the same when viewed on Router.B. However, from the perspective of Router.B, the destinations on Router.A and Router.C both have a cost of 1. This is because Router.B is connected to Router.A and Router.C through links.

    The valid-origins column shows that starting from Router.C, Router.B has the best path to reach Router.A. Likewise, starting from Router.A, Router.B has the best path to reach Router.C.

    Finally, Router.C shows the following details about the router topology:

    $ qdstat -n -v -r Router.C
    Routers in the Network
      router-id  next-hop  link  cost  neighbors                 valid-origins
      ==========================================================================
      Router.A   Router.B  -     2     ['Router.B']              []
      Router.B   -         0     1     ['Router.A', 'Router.C']  []
      Router.C   (self)    -           ['Router.B']              []

    Due to a symmetric topology, the Router.C perspective of the topology is very similar to the Router.A perspective. The primary difference is the cost: the cost to reach Router.B is 1, because the two routers are connected. However, the cost to reach Router.A is 2, because the messages would have to pass through Router.B as the next-hop.

6.3.6. Viewing Addresses Known to a Router

You can view message-routed and link-routed addresses known to a router.

Procedure

  • Use the following command:

    $ qdstat -a [CONNECTION_OPTIONS]

    For more information about the fields displayed by this command, see the qdstat -a output columns.

    In this example, Router.A is connected to both Router.B and a broker. The broker has two queues:

    • my_queue (with a link route on Router.A)
    • my_queue_wp (with a waypoint and autolinks configured on Router.A)

    In addition, there are three receivers: one connected to my_address for message routing, another connected to my_queue, and the last one connected to my_queue_wp.

    Viewing the addresses displays the following information:

    $ qdstat -a
    Router Addresses
      class     addr                   phs  distrib       in-proc  local  remote  cntnr  in  out  thru  to-proc  from-proc
      ======================================================================================================================
      local     $_management_internal       closest       1        0      0       0      0   0    0     0        0
      local     $displayname                closest       1        0      0       0      0   0    0     0        0
      mobile    $management            0    closest       1        0      0       0      8   0    0     8        0
      local     $management                 closest       1        0      0       0      0   0    0     0        0
      router    Router.B                    closest       0        0      1       0      0   0    5     0        5 1
      mobile    my_address             0    closest       0        1      0       0      1   1    0     0        0 2
      link-in   my_queue                    linkBalanced  0        0      0       1      0   0    0     0        0 3
      link-out  my_queue                    linkBalanced  0        0      0       1      0   0    0     0        0
      mobile    my_queue_wp            1    balanced      0        1      0       0      1   1    0     0        0 4
      mobile    my_queue_wp            0    balanced      0        1      0       0      1   1    0     0        0
      local     qdhello                     flood         1        1      0       0      0   0    0     741      706 5
      local     qdrouter                    flood         1        0      0       0      0   0    0     4        0
      topo      qdrouter                    flood         1        0      1       0      0   0    27    28       28
      local     qdrouter.ma                 multicast     1        0      0       0      0   0    0     1        0
      topo      qdrouter.ma                 multicast     1        0      1       0      0   0    2     0        3
      local     temp.IJSoXoY_lX0TiDE        closest       0        1      0       0      0   0    0     0        0
    1
    An address related to Router.B with a remote at 1. This is the consumer from Router.B.
    2
    The my_address address has one local consumer, which is related to the single receiver attached on that address. The in and out fields are both 1, which means that one message has traveled through this address using the closest distribution method.
    3
    The incoming link route for the my_queue address. This address has one locally-attached container (cntnr) as a destination (in this case, the broker). The following entry is the outgoing link for the same address.
    4
    The incoming autolink for the my_queue_wp address and configured waypoint. There is one local consumer (local) for the attached receiver. The following entry is the outgoing autolink for the same address. A single message has traveled through the autolinks.
    5
    The qdhello, qdrouter, and qdrouter.ma addresses are used to periodically update the network topology and deliver router control messages. These updates are made automatically through the inter-router protocol, and are based on all of the messages the routers have exchanged. In this case, the distribution method (distrib) for each address is either flood or multicast to ensure the control messages reach all of the routers in the network.

6.3.9. Viewing Memory Consumption Information

If you need to perform debugging or tracing for a router, you can view information about its memory consumption.

Procedure

  • Use the following command:

    $ qdstat -m [CONNECTION_OPTIONS]

    This command displays information about allocated objects, their size, and their usage by application threads:

    $ qdstat -m
    Types
      type                     size   batch  thread-max  total  in-threads  rebal-in  rebal-out
      ===========================================================================================
      qd_bitmask_t             24     64     128         64     64          0         0
      qd_buffer_t              536    16     32          80     80          0         0
      qd_composed_field_t      64     64     128         256    256         0         0
      qd_composite_t           112    64     128         320    320         0         0
      ...

6.4. Managing AMQ Interconnect Using qdmanage

You can use qdmanage to view and modify the configuration of a running router at runtime. Specifically, qdmanage enables you to create, read, update, and delete the sections and attributes in the router’s configuration file without having to restart the router.

Note

The qdmanage tool implements the AMQP management specification, which means that you can use it with any standard AMQP-managed endpoint, not just with AMQ Interconnect.

6.4.1. Syntax for Using qdmanage

You can use qdmanage with the following syntax:

$ qdmanage [CONNECTION_OPTIONS] OPERATION [OPTIONS]

This specifies:

  • One or more optional connection_options to specify the router on which to perform the operation, or to supply security credentials if the router only accepts secure connections.

    If you do not specify any connection options, qdmanage connects to the router listening on localhost and the default AMQP port (5672).

  • The operation to perform on the router.
  • One or more optional options to specify a configuration entity on which to perform the operation or how to format the command output.

When you enter a qdmanage command, it is executed as an AMQP management operation request, and then the response is returned as command output in JSON format.

For example, the following command executes a query operation on a router, and then returns the response in JSON format:

$ qdmanage query --type listener
[
  {
    "stripAnnotations": "both",
    "addr": "127.0.0.1",
    "multiTenant": false,
    "requireSsl": false,
    "idleTimeoutSeconds": 16,
    "saslMechanisms": "ANONYMOUS",
    "maxFrameSize": 16384,
    "requireEncryption": false,
    "host": "0.0.0.0",
    "cost": 1,
    "role": "normal",
    "http": false,
    "maxSessions": 32768,
    "authenticatePeer": false,
    "type": "org.apache.qpid.dispatch.listener",
    "port": "amqp",
    "identity": "listener/0.0.0.0:amqp",
    "name": "listener/0.0.0.0:amqp"
  }
]

For more information about qdmanage, see the qdmanage man page.

6.4.2. Closing a connection

If a consumer is processing messages too slowly, or has stopped processing messages without settling its deliveries, you can close the connection. When you close the connection, the "stuck" deliveries are released.

Procedure

  1. Find the ID of the connection with the slow consumer.

    This command lists the connections for a router in the router network:

    $ qdstat -c -r Router.A
    Connections
    id    host                        container                              role             dir  security     authentication  tenant
    ==================================================================================================================================
      2   127.0.0.1:5672                                                     route-container  out  no-security  anonymous-user
      10  127.0.0.1:5001               Router.B                              inter-router     out  no-security  anonymous-user
      12  localhost.localdomain:42972  161211fe-ba9e-4726-9996-52d6962d1276  normal           in   no-security  anonymous-user
      14  localhost.localdomain:42980  a35fcc78-63d9-4bed-b57c-053969c38fda  normal           in   no-security  anonymous-user
      15  localhost.localdomain:42982  0a03aa5b-7c45-4500-8b38-db81d01ce651  normal           in   no-security  anonymous-user
  2. Close the connection by setting its adminStatus to deleted.

    $ qdmanage update --type=connection --id=12 adminStatus=deleted

6.4.3. Managing Network Connections

You can use qdmanage to view, create, update, and delete listeners and connectors for any router in your router network.

6.4.3.1. Managing Listeners

Listeners define how clients can connect to a router. The following table lists the qdmanage commands you can use to perform common operations on listeners.

For more information about the attributes you can use with these commands, see listener in the qdrouterd.conf man page.

Note

The commands in this table demonstrate operations on the local router listening on localhost and the default AMQP port (5672). If you want to perform an operation on a different router in the router network, you must specify the necessary connection options. For more information, see Connection Options in the qdmanage man page.

To…​Use this command…​

View the router’s listeners

qdmanage query --type=listener

View the roles and ports on which the router is listening

qdmanage query role port --type=listener

View the attributes configured for a listener

qdmanage read --name=LISTENER_NAME

Create a listener

qdmanage create --type=listener --ATTRIBUTE=VALUE ...

Create multiple listeners

  1. Enter this command:

    qdmanage create --stdin
  2. Configure the listeners using a JSON map:

    [{"type"="listener", "ATTRIBUTE":"VALUE"...}, {"type"="listener", "ATTRIBUTE":"VALUE"...}...]

These commands use a JSON map to create two listeners.

Update a listener

qdmanage update --type=listener --ATTRIBUTE=VALUE ...

Update multiple listeners

  1. Enter this command:

    qdmanage update --stdin
  2. Configure the listeners using a JSON map:

    [{"type"="listener", "ATTRIBUTE":"VALUE"...}, {"type"="listener", "ATTRIBUTE":"VALUE"...}...]

These commands use a JSON map to update two listeners.

Delete an attribute from a listener

qdmanage update --type=listener --ATTRIBUTE

Delete a listener

qdmanage delete --name=LISTENER_NAME

6.4.3.2. Managing Connectors

Connectors define how the router can connect to other endpoints in your messaging network, such as brokers and other routers. The following table lists the qdmanage commands you can use to perform common operations on connectors.

For more information about the attributes you can use with these commands, see connector in the qdrouterd.conf man page.

Note

The commands in this table demonstrate operations on the local router listening on localhost and the default AMQP port (5672). If you want to perform an operation on a different router in the router network, you must specify the necessary connection options. For more information, see Connection Options in the qdmanage man page.

To…​Use this command…​

View the router’s connectors

qdmanage query --type=connector

View the roles and ports on which the router can connect to other endpoints

qdmanage query role port --type=connector

If the router is connected to a broker, view the alternate URLs on which the router can connect to the broker if the primary connection fails

qdmanage query failoverUrls --type=connector --name=CONNECTOR_NAME

View the attributes configured for a connector

qdmanage read --name=CONNECTOR_NAME

Create a connector

qdmanage create --type=connector --ATTRIBUTE=VALUE ...

Create multiple connectors

  1. Enter this command:

    qdmanage create --stdin
  2. Configure the connectors using a JSON map:

    [{"type"="connector", "ATTRIBUTE":"VALUE"...}, {"type"="connector", "ATTRIBUTE":"VALUE"...}...]

These commands use a JSON map to create two connectors.

Update a connector

qdmanage update --type=connector --ATTRIBUTE=VALUE ...

Update multiple connectors

  1. Enter this command:

    qdmanage update --stdin
  2. Configure the connectors using a JSON map:

    [{"type"="connector", "ATTRIBUTE":"VALUE"...}, {"type"="connector", "ATTRIBUTE":"VALUE"...}...]

These commands use a JSON map to update two connectors.

Delete an attribute from a connector

qdmanage update --type=connector --ATTRIBUTE

Delete a connector

qdmanage delete --name=CONNECTOR_NAME

6.4.4. Managing Security

AMQ Interconnect supports both SSL/TLS and SASL security protocols for encrypting and authenticating incoming and outgoing connections for your routers. You can use qdmanage to view, create, update, and delete security policies for any router in your router network.

6.4.4.1. Managing SSL/TLS Encryption and Authentication

AMQ Interconnect supports SSL/TLS for certificate-level encryption and mutual authentication. The following table lists the common qdmanage commands you can use to secure incoming and outgoing connections for a router in your router network.

For more information about the attributes you can use with these commands, see sslProfile and listener in the qdrouterd.conf man page.

Note

The commands in this table demonstrate operations on the local router listening on localhost and the default AMQP port (5672). If you want to perform an operation on a different router in the router network, you must specify the necessary connection options. For more information, see Connection Options in the qdmanage man page.

To…​Use this command…​

View the router’s SSL/TLS configuration

qdmanage query --type=sslProfile

Set up SSL/TLS for the router

qdmanage create --type=sslProfile --name=NAME --ATTRIBUTE=VALUE ...

Add SSL/TLS encryption to an incoming connection

qdmanage update --name=LISTENER_NAME --sslProfile=NAME --requireSsl=yes

Change SSL/TLS encryption on an incoming connection

qdmanage update --name=LISTENER_NAME --ATTRIBUTE=VALUE ...

Add SSL/TLS client authentication to an incoming connection

qdmanage update --name=LISTENER_NAME --authenticatePeer=yes

Remove SSL/TLS client authentication from an incoming connection

qdmanage update --name=LISTENER_NAME --authenticatePeer=no

Add SSL/TLS client authentication to an outgoing connection

qdmanage update --name=CONNECTOR_NAME --sslProfile=NAME

Remove SSL/TLS client authentication from an outgoing connection

qdmanage update --name=CONNECTOR_NAME --sslProfile

Delete an SSL profile

qdmanage delete --name=SSL_PROFILE_NAME

6.4.4.2. Managing SASL Encryption and Authentication

AMQ Interconnect supports SASL for authentication and payload encryption. The following table lists the common qdmanage commands you can use to secure incoming and outgoing connections for a router in your router network.

For more information about the attributes you can use with these commands, see router and listener in the qdrouterd.conf man page.

Note

The commands in this table demonstrate operations on the local router listening on localhost and the default AMQP port (5672). If you want to perform an operation on a different router in the router network, you must specify the necessary connection options. For more information, see Connection Options in the qdmanage man page.

To…​Use this command…​

Set up SASL for the router

qdmanage update --type=router --saslConfigDir=PATH --saslConfigName=NAME

Add SASL authentication to an incoming connection

qdmanage update --name=LISTENER_NAME --authenticatePeer=yes --saslMechanisms=MECHANISMS

Change SASL mechanisms for an incoming connection

qdmanage update --name=LISTENER_NAME --saslMechanisms=MECHANISMS

Add SASL authentication to an outgoing connection

qdmanage update --name=CONNECTOR_NAME --saslMechanisms=MECHANISMS --saslUsername=USERNAME --saslPassword=PASSWORD

Change SASL mechanisms for an outgoing connection

qdmanage update --name=CONNECTOR_NAME --saslMechanisms=MECHANISMS

Add SASL payload encryption to an incoming connection

qdmanage update --name=LISTENER_NAME --requireEncryption=yes --saslMechanisms=MECHANISMS

Change SASL mechanisms for an incoming connection

qdmanage update --name=LISTENER_NAME --saslMechanisms=MECHANISMS

Remove SASL payload encryption from an incoming connection

qdmanage update --name=LISTENER_NAME --requireEncryption=no --saslMechanisms

Delete a SASL configuration

qdmanage update --type=router --saslConfigDir --saslConfigName

6.4.5. Managing Routing

AMQ Interconnect supports both message routing and link routing for distributing messages between senders and receivers. You can use qdmanage to view how addresses and link routes are configured in your environment, and define how a router should distribute messages.

6.4.5.1. Managing Message Routing

Message routing involves configuring addresses to define how AMQ Interconnect should distribute messages. The following table lists the common qdmanage commands you can use to configure addresses for a router in your router network.

For more information about the attributes you can use with these commands, see address and autolink in the qdrouterd.conf man page.

Note

The commands in this table demonstrate operations on the local router listening on localhost and the default AMQP port (5672). If you want to perform an operation on a different router in the router network, you must specify the necessary connection options. For more information, see Connection Options in the qdmanage man page.

To…​Use this command…​

View addresses

qdmanage query --type=address
qdmanage read --name=ADDRESS_NAME

View address distribution patterns

qdmanage query prefix distribution --type=address

View waypoints to broker queues

qdmanage query prefix --type=address --waypoint=yes

View autolinks

qdmanage query --type=autolink

Set a distribution pattern for an address

qdmanage create --type=address --prefix=ADDRESS_PREFIX --distribution=DISTRIBUTION_PATTERN ...

Set distribution patterns for multiple addresses

  1. Enter this command:

    qdmanage create --stdin
  2. Configure the addresses using a JSON map:

    [{"type":"address", "prefix":"ADDRESS_PREFIX", "distribution":"DISTRIBUTION_PATTERN", "ATTRIBUTE":"VALUE", ...}, {"type":"address", "prefix":"ADDRESS_PREFIX", "distribution":"DISTRIBUTION_PATTERN", "ATTRIBUTE":"VALUE", ...} ...]

These commands configure two addresses.

Connect an address to a broker queue

  1. Enter this command:

    qdmanage create --stdin
  2. Create an address waypoint, an incoming autolink, and an outgoing autolink:

    [{"type":"address", "prefix":"ADDRESS_PREFIX", "waypoint":"yes"}, {"type":"autolink", "addr":"ADDRESS_NAME", "connection":"CONNECTOR/LISTENER_NAME", "direction":"in"}, {"type":"autolink", "addr":"ADDRESS_NAME", "connection":"CONNECTOR/LISTENER_NAME", "direction":"out"}]

Update an address configuration

qdmanage update --name=ADDRESS_NAME --ATTRIBUTE=VALUE ...

Update an autolink

qdmanage update --name=AUTOLINK_NAME --ATTRIBUTE=VALUE ...

Delete an address configuration

qdmanage delete --name=ADDRESS_NAME

Delete an autolink

qdmanage delete --name=AUTOLINK_NAME

6.4.6. Managing Logging

AMQ Interconnect logs are broken into different categories called logging modules. Each module provides important information about a particular aspect of a router. The following table lists the common qdmanage commands you can use to view and change the configuration of a logging module.

For more information about the attributes you can use with these commands, see log in the qdrouterd.conf man page.

Note

The commands in this table demonstrate operations on the local router listening on localhost and the default AMQP port (5672). If you want to perform an operation on a different router in the router network, you must specify the necessary connection options. For more information, see Connection Options in the qdmanage man page.

To…​Use this command…​

View the logging configuration

qdmanage query --type=log

View the logging configuration for a logging module

qdmanage read --type=log --name=log/LOGGING_MODULE_NAME

Set the default logging configuration

qdmanage update --type=log --name=log/DEFAULT enable=LOGGING_LEVEL includeTimestamp=yes ATTRIBUTE=VALUE

Enable logging for a logging module

qdmanage update --type=log --name=log/LOGGING_MODULE_NAME enable=LOGGING_LEVEL ATTRIBUTE=VALUE ...

Change the logging configuration for a logging module

qdmanage update --type=log --name=log/LOGGING_MODULE_NAME ATTRIBUTE=VALUE ...

6.5. Upgrading AMQ Interconnect

You should upgrade AMQ Interconnect to the latest version to ensure that you have the latest enhancements and fixes. The upgrade process involves installing the new AMQ Interconnect packages and restarting your routers.

You can use these instructions to upgrade AMQ Interconnect to a new minor release or maintenance release.

Minor Release
AMQ Interconnect periodically provides point releases, which are minor updates that include new features, as well as bug and security fixes. If you plan to upgrade from one AMQ Interconnect point release to another, for example, from AMQ Interconnect 1.0 to AMQ Interconnect 1.1, code changes should not be required for applications that do not use private, unsupported, or technical preview components.
Maintenance Release
AMQ Interconnect also periodically provides maintenance releases that contain bug fixes. Maintenance releases increment the minor release version by the last digit, for example from 1.0.0 to 1.0.1. A maintenance release should not require code changes; however, some maintenance releases might require configuration changes.

Prerequisites

Before performing an upgrade, you should have reviewed the release notes for the target release to ensure that you understand the new features, enhancements, fixes, and issues. To find the release notes for the target release, see the Red Hat Customer Portal.

Procedure

  1. Upgrade the qpid-dispatch-router and qpid-dispatch-tools packages and their dependencies:

    $ sudo yum update qpid-dispatch-router qpid-dispatch-tools

    For more information, see Section 2.1, “Installing AMQ Interconnect”.

  2. Restart each router in your router network.

    To avoid disruption, you should restart each router one at a time.

    This example restarts a router in Red Hat Enterprise Linux 7:

    $ systemctl restart qdrouterd.service

    For more information about starting a router, see Section 2.3, “Starting the router”.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.