SwiftMQ Documentation

SwiftMQ Documentation

  • Client
  • CE
  • UR
  • HA
  • Javadocs
  • Release Notes

›Swiftlets

SwiftMQ Client

  • Getting Started
  • JNDI Client
  • JMS Client
  • AMQP 1.0 Client
  • Filetransfer Client

SwiftMQ CE

  • Getting Started
  • Installation
  • Upgrade
  • Software Architecture
  • Administration

    • Preconfig
    • CLI Command Line Interface
    • JMX Administration
    • CLI Message Interface
    • routerconfig.xml Watch Dog
    • System Properties

    Swiftlets

    • AMQP Swiftlet
    • Authentication Swiftlet
    • Deploy Swiftlet
    • JMS Swiftlet
    • JNDI Swiftlet
    • Log Swiftlet
    • Management Swiftlet
    • MQTT Swiftlet
    • Network Swiftlet
    • Queue Manager Swiftlet
    • Routing Swiftlet
    • Scheduler Swiftlet
    • Store Swiftlet
    • Streams Swiftlet
    • Threadpool Swiftlet
    • Timer Swiftlet
    • Topic Manager Swiftlet
    • Trace Swiftlet
    • XA Resource Manager Swiftlet

    APIs

    • CLI Admin API

    How To

    • TLS Configuration
    • HTTP Tunneling Configuration
    • Upgrade SwiftMQ Router and Clients

    In Depth

    • Versioning
    • File Store

SwiftMQ UR

  • Getting Started
  • License
  • Installation
  • Upgrade
  • Administration

    • SwiftMQ Explorer

    Swiftlets

    • JDBC Authentication Swiftlet
    • FileCache Swiftlet
    • JMS Application Container Swiftlet
    • JMS XA Swiftlet
    • JDBC Store Swiftlet
    • AMQP Bridge Extension Swiftlet
    • JMS Bridge Extension Swiftlet
    • JavaMail Bridge Extension Swiftlet
    • Replicator Extension Swiftlet

SwiftMQ HA

  • Getting Started
  • License
  • Installation
  • Upgrade
  • HA Introduction
  • HA Deployment
  • Administration
  • JNDI/JMS under HA
  • Routing under HA
  • Advanced Configuration
  • HA Test Suite

Routing Swiftlet

The Routing Swiftlet provides unlimited connectivity to other SwiftMQ routers with transparent routing of point-to-point as well as publish/subscribe based messages to remote destinations.

Federated Router Network

Each SwiftMQ router is a full-fledged JMS server with its own resources (queues, topics, durable subscribers, connection factories, and so on). The Routing Swiftlet is able to connect single SwiftMQ routers together. Due to dynamic routing which doesn't require any configuration (it's automatically), all resources of those connected routers become globally available. For example, a message can be send to testqueue@router7 from a JMS client connected to router1, a message published to topic testtopic from a JMS client connected to router7 will be send to a subscriber on testtopic which is connected to router88, and a JMS client is able to lookup a connection factory, registered on router10, from a JMS client connected to router11.

For this construct of connected routers with globally available but locally managed resources we have created the term FEDERATED ROUTER NETWORK. Each router is independent but they work together - federated. SwiftMQ includes federation support since its release 1.0 and it's very mature. In fact, there is no other JMS system in the world which implements it better than SwiftMQ, because it's SwiftMQ's core design.

There is no restriction in the number of routers you can connect nor in the form of the topology you like to build. You don't have to create a hub/spoke like topology with a main router in the middle. You can also build a ring. No matter whether a router is directly or intermediate connected (via other routers) - it is reachable. If a connection gets lost and there is another route to the destination, the message travels that way. If no more route is available, the message stays at the last router and will be forwarded once a route becomes available again.

The following example illustrates a possible router network topology:

The Routing Swiftlet routes the messages destination-based, by finding the shortest way. To balance a load or to increase the message throughput, round-robin scheduling can be selected. In this case, the messages are distributed to all routes of a destination evenly:

For maximum reliability and guaranteed delivery, 2-phase-commit (XA) is used to transfer messages in configurable transaction sizes (bulk) from one router to the other, fast. Recovery of in-doubt XA transactions (prepared but not committed) is automatically done during the connect phase from our transaction manager.

Routing Connections

A routing connection can be established if one router provides a listener and the other a connector. There is no limit in the number of listener and connectors. You can define any number of listeners on different ports and any number of connectors.

Listeners

A listener listens on a specific port and can be bound to a particular interface on multi homes machines. It defines a socket factory (default PlainSocketFactory) to use for sockets, created from this listener. Further attributes are a password (which is exchanged with challenge/response) and a host access list which is checked against the host name of incoming socket connections. One can also use TLS by specifying the JSSESocketFactory instead of the PlainSocketFactory.

The following snippet defines a listener on port 4100 with the default PlainSocketFactory and another one listening on port 443 with the JSSESocketFactory and a password:

Example:

<listeners>
    <listener name="plainsocket" port="4100">
        <host-access-list/>
    </listener>
    <listener name="tlsocket" port="443"
              socketfactory-class="com.swiftmq.net.JSSESocketFactory"
              password="secret">
        <host-access-list/>
    </listener>
</listeners>

Connectors

A connector is responsible to establish a routing connection. It points to a listener on a remote router and must be of the same configuration concerning socket factory and password. A connector can be enabled and disabled. It is enabled by default. A disabled connector is inactive.

If a connection cannot be established by a connector or is lost, it retries in intervals, specified in attribute retry-time, to connect. The default retry-time is 60000 (1 minute). Retry is only performed if the connector is enabled.

The following snippet defines a connector, pointing to a routing listener on host chb.acme.com on port 17884. It uses the JSSESocketFactory and password let_me_in. The retry-time is 2 minutes:

Example:

<connectors>
    <connector name="acme" 
               hostname="chb.acme.com"
               port="17884"
               socketfactory-class="com.swiftmq.net.JSSESocketFactory"
               password="let_me_in"
               retry-time="120000"/>
</connectors>

Scheduling a Connector Job via the Scheduler Swiftlet

The Routing Swiftlet registers a job Routing Connector in job group Routing at the Scheduler Swiftlet:

This job takes the name of the routing connector as parameter. It enables the connector at job start and disables it at job stop. Therefore, a connector should be configured as being disabled if it should be used in a job:

Example:

<connectors>
    <connector name="acme"
               enabled="false"
               hostname="chb.acme.com"
               port="17884"
               socketfactory-class="com.swiftmq.net.JSSESocketFactory"
               password="let_me_in"
               retry-time="120000"/>
</connectors>

The Routing Connector should have a specified maximum runtime in its schedule, otherwise it will not be disabled. If the connector will be enabled during job start and the connection cannot be established, the retry behavior will be executed as described in the section above. Retry ends at job stop.

The following example schedules a Routing Connector job for the connector named acme every business day at 09:00 with a maximum runtime of 8 hours, so the routing connection will be effectively established (if possible) between 09:00 and 17:00:

Adjusting Network Buffers

SwiftMQ manages its own network buffers on both sides of the wire. The length of the data sent to the network is determined by the underlying SMQP protocol handlers. Only complete requests are sent. Before a request is sent, it is written to a network buffer. The receiving side receives the data into a network buffer as well. Theses buffers are adjusted automatically. However, adjustment may take time when transfering large messages, so it might be necessary to configure buffer/extend sizes that meets the requirements more specific.

Network buffers are initially created with their initial size which is 128 KB by default. If the protocol handler detects that the buffer is full before it can flush it, it will extend the buffer and continues writing until the request is finished or the buffer fills up again which then leads to another extend. The default extend size is 64 KB.

The initial buffer size and the extend size can be specified for:

  • Router input/Listener
  • Router output/Listener
  • Router input/Connector
  • Router output/Connector

So it's possible to adjust network buffers for both sides by creating the appropriate routing listeners and connectors.

Reconnect

If a routing connection is established and one side disconnects, the other side (the other router) might not detect it. That's not a problem of SwiftMQ but one of the TCP protocol. To detect this invalid connections, SwiftMQ uses a keepalive mechanism on routing connections which works as follows:

If a connector of one router connects to a listener of another router, both sides pass different stages (connect, authentication, recovery, etc) until they reach the final delivery stage in which the actual message exchange takes place. The keepalive mechanism is started at the beginning of the delivery stage. Previous stages are protected by timers which ensure that such a stage will not stuck by waiting for a reply which will never happen due to a disconnect during that stage. If the timers are fired and the stage is in waiting mode, the connection will be disconnected.

The time after which such an "early" stage becomes invalid can be specified via attribute stage-valid-timeout. Default is 15 seconds. Another attribute reject-disconnect-delay specifies the time after which a rejected connection (e.g. routername already connected, authentication failed) is closed. Both attributes are dependent on each other. If a connector connects to a listener, it initializes a timer with the value of stage-valid-timeout. This ensures that the stages becomes invalid if no reply arrives. Say, the router name is already connected so the listener rejects the connection and sends a negative reply. The listener initializes a timer with the value of reject-disconnect-delay which leads to a physical close when the timer is fired.

The keepalive mechanism consists of keepalive messages which are sent from both sides of the connection in the interval specified in attribute keepalive-interval of the routing listener. This value is passed over to the connector during the connect stage. Each side has a counter which is initialized with 5. If a keepalive message is received, the counter is incremented. If a keepalive message is sent, the counter is decremented. If the counter reaches 0, the connection is probably invalid and is closed physically.

A routing connection is valid before the keepalive counter reaches 0. However, it might be already disconnected at one end and that router tries to reconnect which, in turn, will be rejected, because a given router can only be connected once. The other router is able to reconnect after the routing connection has been closed due to the keepalive mechanism. Therefore, the maximum time a router has to wait until it is able to reconnect is 5 * <keepaliveinterval>. The attribute keepalive-interval of the routing listener can be set to a lower value to shorten this time.

Message Routing

Dynamic Routing

Routing between routers of a network requires information about the routes. These routes are exchanged dynamically between each router of the network during the connect phase. That means, each router is able to send messages to each other since it knows every route there. If a router connects another router, it has the direct route to this remote router and gets all routes from here to other routers. Therefore, a message can be routed to a router which is not directly connected but reachable by other intermediate routers.

The Routing Swiftlet stores a table with all dynamic routes, called "routing table", which is displayed below the Usage node of the Routing Swiftlet:

The routing table contains an entry for each known destination router. Each of this entries contains a table of dynamic routes, received by this router. A dynamic route consists of a list of intermediate routers (hops) which a message has to travel until it reaches its final destination.

Per default, always the shortest way is choosen by the Routing Swiftlet during messages transfer, that is the route with the minimum hop count. This is the default routing mode. Therefore the message is routable if at least 1 route to its destination is known, because if a route fails, the next best route is choosen and the message travels another, probably longer way. Another routing mode is "round-robin" which has to be enabled separately. Within this mode, messages are distributed over all known routes to its destination evenly. Round-robin is reasonable to spread a message load over multiple routing connections.

Static Routes

With the dynamic routing architecture, a remote queue can be addressed if a route is available. Otherwise the queue is unknown. To enable clients to address remote queues before a dynamic route is announced, static routes can be created. These are simply router names. Static routes are not announced to other routers. Their only sense is to enable clients to address unknown routers.

How to avoid Route Flooding

The advantage of dynamic routing is its plug-and-play nature. No administrators interaction is required. A message is routed automatically to the destination inclusive failover. However, the disadvantage is the amount of routes which need to be exchanged. Every router knows every route to every other router. So, the more routers the more routes are exchanged. Updated routes are exchanged whenever a routing connection somewhere in a router network connects or disconnects. To reduce this traffic, route filters can be defined.

The following example shows a typical star-like router network topology with 2 interconnected main routers, hq1 and hq2. Each main router has 3 interconnected satellite routers. There is an additional connection between sub3 and sub4:

If a message should be send from sub6 to a queue at sub1, it will by default use the shortest way (minimum hop count): sub6 -> hq2 -> hq1 -> sub1. However, there are many other routes as well, for example: sub6 -> hq2 -> sub5 -> sub4 -> sub3 -> hq1 -> sub2 -> sub1.

Many of this routes don't make sense and will never be used. It may also be required to restrict access between routers in a network. There are 2 way to accomplish this: to define a hop limit at a router and/or to define route filters.

Hop Limit

SwiftMQ 5.0.2 introduces a new attribute called route-announce-hop-limit to limit the routes which are announced from a router to the value specified via this attribute. The router checks each route if the number of hops exceeds the attribute value and only forwards it if the hop count is less. The default value of route-announce-hop-limit is 3. A value of -1 disabled the hop limit.

In the above example, if we define for each satellite router sub1 to sub6 the route-announce-hop-limit=1 then we would have direct routes (via the direct connection) between them and their correspondend main router hq1 resp. hq2. However, since the main routers don't have a hop limit, there were an alternate route for each satellite via it's main router. For example, sub6 could reach sub5 directly but also via hq2. sub6 could also reach sub1 via hq2 and hq1 because the main router don't have a hop limit. However, all nonsense routes like sub6 -> hq2 -> hq1 -> sub2 -> sub3 -> sub4 -> sub5 are elimited by the hop limit.

If we define route-announce-hop-limit=1 for the main routers hq1 and hq2 as well then each satellite could only communicate with its direct neighbor satellite and its main router. Both main routers could communicate as well but not with the satellite of each other. sub6 could reach sub5 but not sub4 and not sub1. The only exception is that sub3 and sub4 can reach each other because they have a direct connection.

Please check the routing table (see picture on top of this page) of your routers while you define your hop limits. Routing connections have to be re-established to force re-announcement of routes.

Route Filters

Route filters provide a way for semantic filtering of routes. They can be hop or destination based and of the include or exclude type. In this context a hop defines a router node to which other routers are connected and which announces routes to the outside. A destination is a single router. Possible filters are:

  • Announce only routes to a single destination outside (include by destination)
  • Announce only routes to a hop and all hop-connected routers (= a subnet) to outside (include by hop)
  • Don't announce routes to a single destination outside (exclude by destination)
  • Don't announce routes to a hop and all hop-connected routers (= a subnet) to outside (exclude by hop)

In the above example, let's define a filter at sub4 for router sub3 of type include by destination with the value sub4. This must be read "to router sub3 announce only routes to destination sub4". Since the only route which has a destination sub4 is the direct route this will filter all routes except the direct route. If we define a similar route at sub3 (for sub4, type include by destination, value sub3) then both routers can reach each other via their direct connection but not any other router via this direct connection.

If we would further add a filter at hq2 of type exclude by hop with value hq1 then sub4 to sub6 wouldn't be able to reach hq1, sub1 to sub3, except that sub3 and sub4 could communicate directly. So exclude by hop excludes a complete subnet, identified by a hop. All other routes are announced. If one would like to exclude all routes except those from a particular hop then include by hop must be used.

Please check the routing table (see picture on top of this page) of your routers while you define your route filters. Routing connections have to be re-established to force re-announcement of routes.

Routing Protocol

Up to SwiftMQ release 9.4.1 messages on routing connections are exchanged with the 2-phase-commit protocol (XA). From SwiftMQ release 9.4.2 onwards there is a choice between XA and Non-XA message exchange. Both have their advantages and disadvantages as described in the next sections.

A transaction has a specific size of messages, configurable via the attribute inbound-transaction-size on both the listener and the connector. Therefore, it is possible to specify different transaction sizes for both directions. "inbound" means that this is the size a router accepts inbound. It is passed to the sending side during the connect.

The Routing Swiftlet tries to load up that size messages from the corresponding routing queue and sends it as a single transaction to the other router. The default transaction size is 20 messages. Determining the proper size is dependent on the message size and on the connection speed. Small messages and high-speed connections should have a higher transaction size, e.g. 500 messages, whereas large messages on a low-speed connection should have a lower transaction size, e.g. 1. The default size of 20 fits usual environments.

The transfer of new transactions takes place while previous transactions are in transit in both directions. There is another attribute inbound-window-size for both, listeners and connectors, to specify the maximum of open transactions. The sender side of the routing connection sends new transactions until the number of open transactions reaches this window size. Thereafter it waits until it has a window again (means, one or more transactions are committed) and continues sending. The higher the window size, the more transactions can be handled asynchronously and the higher the throughput. However, the more open transactions, the longer takes recovery during startup/reboot of the router. Therefore, the default value is 10 which is useful.

XA Protocol

The exchange of messages between routers takes place in form of XA transactions. An XA transaction is a transaction under control of SwiftMQ's transaction manager, utilizing the 2-phase-commit protocol to move it from one router to the other.

If a router is shut down, it might have many open XA transactions, dependent on the number of active routing connections and the configured window sizes. Like JMS XA transactions, these are handled by the XA Resource Manager Swiftlet. It checks the XA log during startup and eventually displays a warning message like this:

Example:

+++ WARNING! 10 prepared transactions found!
+++          Routing XA transactions are automatically recovered.
+++          You may also use Explorer/CLI for commit or rollback.

These open (prepared) XA transactions are automatically recovered once the corresponding router connects again. If that will not be the case, e.g. due to changes in the router network topology, the SwiftMQ Explorer or CLI can be used to commit or rollback these open XA transactions manually. See the XA Resource Manager Swiftlet documentation for details.

The advantage of using XA transactions is that exactly-once delivery (no duplicates, no losts) is ensured by the XA protocol. Messages of prepared but not committed XA transactions are locked until they are committed or rolled back.

Disadvantage is the latency overhead. A single XA transaction requires 3 protocol messages exchanged between source and destination router until the messages are available at the destination router. The overall throughput can be increased by increasing transaction concurrency via the inbound-window-size attribute but this does not reduce the latency of a single transaction.

Non-XA Protocol (since 9.4.2)

Non-XA can be requested by a listener and/or connector. It will be used if both sides request it and if both sides are releases 9.4.2 or later.

A transaction is immediately committed at the receiving router and the sending router is asynchronously informed. If a routing connection is disconnected, the router dies or is shut down, open transactions are rolled back. When the connection is re-established, these messages are marked as redelivered and duplicate message detection at the destination queues will check these messages on arrival if they are duplicates and may discard it.

Advantage of non-XA transaction is reduction of latency. A single transaction requires only a single protocol message.

Disadvantage is that duplicates may occur under certain scenarios:

  • Duplicate message detection relies on the JMS message id. It does not work if the JMS message id was disabled which is possible to configure.
  • If a destination queue gets input from other sources while a routing connection is down, the JMS message ids of the routing connection may be rolled out of the duplicate log in the meantime because it has a limited size.
  • If there are multiple routes over multiple hops to the destination, the rolled back messages will travel these routes. Duplicate detection works only for the next hop so duplicates may not be detected.

Therefore, a scenario that will not generate possible duplicates is

  • All messages have a JMS message id.
  • Destination queues do not get other input than from the routing connection.
  • There is no further route with more than 1 hop to the destination router.

Flow Control

Flow control is an important instrument to avoid overloading a router with messages. SwiftMQ generates flow control delays on every queue during commit of a producer. The flow control delay is a computed estimate how long it takes to consume queue messages with the current production and consumption rate. If the flow control is respected, an optimal throughput flow will be established which holds the messages of a queue just below the maximum cache size. Therefore, the throughput is maximum at the current consumption rate.

During routing, messages are produced to queues during inbound processing. On each commit a flow control delay is returned. An attribute inbound-flow-control-enabled can be set to true or false. Setting to true, the flow control is respected and further commits are delayed, depending on the flow control delays. These delays are cascaded through the whole router network back to the producer client if each hop on the route has inbound-flow-control-enabled set to true. If it is set to false (default), flow control delays are not respected and commits are not delayed. So in the worst case, a router is flooded with messages.

Thread Pools

The Routing Swiftlet uses the following thread pools:

  • routing.connection.mgr
  • routing.exchanger
  • routing.scheduler
  • routing.service
  • routing.throttle

routing.connection.mgr

This thread pool is used from the routing connection manager. This is a single instance, performing several tasks during the connect and disconnect phase of a routing connection. The max threads setting has to be 1.

routing.exchanger

Used from the route exchanger to send, receive, and process routes from other routers. There is only a single route exchanger instance per SwiftMQ router so only 1 thread is required on demand. Therefore, the max threads setting has to be 1.

routing.scheduler

Used from routing schedulers. These are asynchronous running components, responsible to package messages into XA transactions and move them to a connection service stage, determined via dynamic routes. A scheduler exists for every routable destination router. It runs on demand and acquires threads from the routing.scheduler pool. The usage of this pool is low. Min/max of each 3 is quite enough for most use cases.

routing.service

This pool is used from connection service stages. Dependent on the state of a connection and the protocol handling, a connection service has a specific stage running. The most frequented stage is the delivery stage which is activated after the whole protocol handshaking is done and the connection is activated for delivery. The delivery stage sends and received messages and does the whole XA handling, except XA commits if inbound flow control is enabled (see next point). The usage of this pool is high. The default setting for min/max of each 3 is enough to handle about 10 concurrent routing connections under high load.

routing.throttle

This pool is only used if inbound flow control is set to true. In that case, XA commits are dispatched to a throttle handler which throttles XA commits depending on the given flow control delays. That means, threads are blocked during the delay. Because each delivery stage has an associated throttle handler and all handlers are served from this pool, a delay on one connection may block other non-delayed connections if the pool wents out of threads. Increasing the max threads should help here.

Configuration

The configuration of the Routing Swiftlet (Unlimited Connections) is defined within the element

      <swiftlet name="sys$routing" .../>

of the router's configuration file. One can use the SwiftMQ Exlorer or CLI for configuration as well. They both save into that file.

Attributes of Element "swiftlet"

Definition

Attribute Type Mandatory Description
reject-disconnect-delay java.lang.Long No Time (ms) after which a rejected Connection is closed
stage-valid-timeout java.lang.Long No Time (ms) after which a Protocol Stage in a wait State becomes invalid
roundrobin-enabled java.lang.Boolean No Enables/Disables Round Robin Scheduling
inbound-flow-control-enabled java.lang.Boolean No Enables/Disables Inbound Flow Control
crfactory-class java.lang.String No Challenge/Response Factory Class
route-announce-hop-limit java.lang.Integer No Maximum Hop Count for Route Announce (-1 = unlimited)

Values

Attribute Values
reject-disconnect-delay Min: 1000
Default: 5000
stage-valid-timeout Min: 1000
Default: 15000
roundrobin-enabled Default: false
inbound-flow-control-enabled Default: false
crfactory-class Default: com.swiftmq.auth.ChallengeResponseFactoryImpl
route-announce-hop-limit Default: 3

Element List "static-routes", Parent Element: "swiftlet"

Static Route Definitions. This element list contains zero or more "static-route" elements with this template definition:

Definition

Attribute Type Mandatory Description
name java.lang.String Yes Name of this Static Route

Element List "filters", Parent Element: "swiftlet"

Route Filter Definitions. This element list contains zero or more "filter" elements with this template definition:

Definition

Attribute Type Mandatory Description
name java.lang.String Yes Name of this Route Filter
type java.lang.String Yes Filter Type

Values

Attribute Values
type Choice: include_by_hop include_by_destination exclude_by_hop exclude_by_destination

Element List "routers", Parent Element: "filter"

Routers to filter. This element list contains zero or more "router" elements with this template definition:

Definition

Attribute Type Mandatory Description
name java.lang.String Yes Name of this Router to filter

Element List "listeners", Parent Element: "swiftlet"

Listener Definitions. This element list contains zero or more "listener" elements with this template definition:

Definition

Attribute Type Mandatory Description
name java.lang.String Yes Name of this Listener
bindaddress java.lang.String No Listener Bind IP Address
port java.lang.Integer Yes Listener Port
use-tcp-no-delay java.lang.Boolean Yes Use Tcp No Delay
socketfactory-class java.lang.String No Listener Socketfactory Class
password java.lang.String No Password
keepalive-interval java.lang.Long No Interval for sending Keep Alive Messages
inbound-transaction-size java.lang.Integer No Number of Messages per Transaction
inbound-window-size java.lang.Integer No Max. Number of open Transactions
router-input-buffer-size java.lang.Integer No Router Network Input Buffer Size
router-input-extend-size java.lang.Integer No Router Network Input Extend Size
router-output-buffer-size java.lang.Integer No Router Network Output Buffer Size
router-output-extend-size java.lang.Integer No Router Network Output Extend Size
use-compression java.lang.Boolean No Uses Wirelevel Compression if enabled
use-xa java.lang.Boolean No Uses 2 Phase Commit Protocol (XA) if enabled

Values

Attribute Values
bindaddress
port
use-tcp-no-delay Default: true
socketfactory-class Default: com.swiftmq.net.PlainSocketFactory
password
keepalive-interval Default: 60000
inbound-transaction-size Default: 20
inbound-window-size Default: 10
router-input-buffer-size Min: 65536
Default: 131072
router-input-extend-size Min: 65536
Default: 65536
router-output-buffer-size Min: 65536
Default: 131072
router-output-extend-size Min: 65536
Default: 65536
use-compression Default: false
use-xa Default: true

Element List "host-access-list", Parent Element: "listener"

Host Access List. This element list contains zero or more "host-access-entry" elements with this template definition:

Definition

Attribute Type Mandatory Description
name java.lang.String Yes Name of this Host Access Entry

Element List "connectors", Parent Element: "swiftlet"

Connector Definitions. This element list contains zero or more "connector" elements with this template definition:

Definition

Attribute Type Mandatory Description
name java.lang.String Yes Name of this Connector
hostname java.lang.String Yes Remote Hostname
enabled java.lang.Boolean No Enables/Disables this Connector
port java.lang.Integer Yes Remote Port
use-tcp-no-delay java.lang.Boolean Yes Use Tcp No Delay
socketfactory-class java.lang.String No Connector Socketfactory Class
password java.lang.String No Password
retry-time java.lang.Long No Retry Time
inbound-transaction-size java.lang.Integer No Number of Messages per Transaction
inbound-window-size java.lang.Integer No Max. Number of open Transactions
router-input-buffer-size java.lang.Integer No Router Network Input Buffer Size
router-input-extend-size java.lang.Integer No Router Network Input Extend Size
router-output-buffer-size java.lang.Integer No Router Network Output Buffer Size
router-output-extend-size java.lang.Integer No Router Network Output Extend Size
use-compression java.lang.Boolean No Uses Wirelevel Compression if enabled
use-xa java.lang.Boolean No Uses 2 Phase Commit Protocol (XA) if enabled

Values

Attribute Values
hostname
enabled Default: true
port
use-tcp-no-delay Default: true
socketfactory-class Default: com.swiftmq.net.PlainSocketFactory
password
retry-time Min: 1000
Default: 60000
inbound-transaction-size Default: 20
inbound-window-size Default: 10
router-input-buffer-size Min: 65536
Default: 131072
router-input-extend-size Min: 65536
Default: 65536
router-output-buffer-size Min: 65536
Default: 131072
router-output-extend-size Min: 65536
Default: 65536
use-compression Default: false
use-xa Default: true

Element "usage", Parent Element: "swiftlet"

Usage.

Element List "connections", Parent Element: "usage"

Active Routing Connections. This element list contains zero or more "usage" elements with this template definition:

Definition

Attribute Type Mandatory Description
name java.lang.String Yes Name of this Active Routing Connection
routername java.lang.String No Name of the connected Router
connecttime java.lang.String No Connect Time
protocol-version java.lang.String No Protocol Version
uses-xa java.lang.Boolean No Uses 2 Phase Commit Protocol (XA) if enabled

Values

Attribute Values
routername
connecttime
protocol-version
uses-xa Default: false

Element List "routing-table", Parent Element: "usage"

Routing Table. This element list contains zero or more "destination" elements with this template definition:

Definition

Attribute Type Mandatory Description
name java.lang.String Yes Name of this Destination

Element List "dynamic-routes", Parent Element: "destination"

Dynamic Routes. This element list contains zero or more "dynamic-route" elements with this template definition:

Definition

Attribute Type Mandatory Description
name java.lang.String Yes Name of this Dynamic Route
← Queue Manager SwiftletScheduler Swiftlet →
  • Federated Router Network
  • Routing Connections
    • Listeners
    • Connectors
    • Scheduling a Connector Job via the Scheduler Swiftlet
    • Adjusting Network Buffers
  • Reconnect
  • Message Routing
    • Dynamic Routing
    • Static Routes
    • How to avoid Route Flooding
  • Routing Protocol
    • XA Protocol
    • Non-XA Protocol (since 9.4.2)
    • Flow Control
    • Thread Pools
  • Configuration
Copyright © 2020 IIT Software GmbH