Language and Page Formatting Options
AMQ Interconnect 1.0 Release Notes
Release Notes for AMQ Interconnect
Chapter 1. Features
AMQ Interconnect 1.0 represents the initial offering of this component as part of a complete messaging solution. Deploying an interconnect router (or network of routers) provides the following benefits over using brokers alone:
- Operating modes
- The interconnect component can operate in stand-alone mode or interior mode.
- Brokerless messaging
- Direct, brokerless messaging when broker queueing is not needed. This feature is useful for request-response/RPC patterns.
- Anycast or Multicast
- Direct delivery can be configured as multicast (all subscribers receive a copy of each produced message) or anycast (one subscriber receives a copy of each produced message).
- Inexpensive HA and resiliency
- High availability and resiliency for the network does not require high-cost clustering; it is achieved through redundant topologies much like one would use in deploying an IP network.
- Scale up queues and topics
- A messaging system including interconnect can offer a greater number of queues and topics than can be offered by a single broker or a cluster of brokers.
- Queue/topic distribution
- A single queue or topic can be distributed across multiple brokers to provide increased user scale and throughput.
- Access to a broker can be secured, hardened, and limited. In addition, the broker does not need to be deployed in a client-facing DMZ (De-Militarized Zone in front of a firewall).
- Connections between clients and a broker or a broker and another broker can be secured by using SSLTLS (Secure Socket Layer Top Level Specification) or SASL (Simple Authentication and Security Layer) at the interconnect level to encrypt the connections.
- Brokers can be added and removed to handle changes in load or to accommodate broker maintenance.
- Queues, topics, and destinations can be partitioned by user/application/account such that multiple users can use the same messaging infrastructure without interfering with each other.
Refer to the Apache QPid Dispatch Router project for additional information: http://qpid.apache.org/components/dispatch-router/index.html
Chapter 2. Enhancements
ENTMQIC-1886 - Remove dependency on python-websockify websocket proxy
Previous releases of the product used
python-websockifyto allow a proxy connection between the
qdrouterddemon and a user’s web browser, necessary to access the HawtIO console
The distribution now contains the
libwebsocketspackage instead of
python-websockifyto establish this connection.
Chapter 3. Resolved Issues
ENTMQIC-1014 - CLI tools fail with no useful error in some SASL configurations
By default, even with
authenticatePeer: no, previous versions of the router were offering all available SASL mechanisms to clients (unless saslMechanisms was set explicitly) This meant that if GSS mechanisms were enabled on the host for other purposes, but not configured for the router, they would be preferred over the less secure ANONYMOUS mechanism and fail. In the current release, only ANONYMOUS is offered when setting
authenticatePeer: noand any client can connect anonymously.
Chapter 4. Known Issues
ENTMQIC-1966 - warning: %postun(qpid-dispatch-router-0.8.0-9.el6.i686) scriptlet failed, exit status 2
If you encounter an error
warning: %postun(qpid-dispatch-router-0.8.0-9.el6.i686) scriptlet failed, exit status 2after installing AMQ Interconnect 1.0.1, check the service
qdrouterdstatus and restart the service if it is running, as shown in the following example:
# service qdrouterd status qdrouterd (pid 3996) is running... # service qdrouterd restart Shutting down qdrouterd services: [ OK ] Starting qdrouterd services: [ OK ] # service qdrouterd status qdrouterd (pid 4384) is running...
ENTMQIC-61 - Memory pools are never returned to heap
Several heavily used data objects (deliveries, messages, links, buffers, etc.) are managed by Qpid Dispatch Router in pools for efficient allocation. In AMQ Interconnect 1.0, objects in these pools are not returned to the heap at any time. This means that the memory used in large bursts of activity will not be freed, but will remain available for use thereafter. This might be observed as an increase in memory usage that does not decrease after a burst of activity is completed. Subsequent bursts of activity will use the same memory that was used previously. Methods of returning large amounts of pooled objects back to the heap are being developed and a solution will be included in a future version of the Router.
Revised on 2017-11-22 09:42:38 EST