Release 4.0.0

Major Enhancements

Intra-VM JMS Clients

The intra-VM JMS client is a client which is connected with a SwiftMQ router via an intra-VM connection. This is not a socket connection but a virtual connection from the JMS client part to an intra-VM connector in the Network Swiftlet. Using the intraVM is the usual way if a SwiftMQ router is an embedded messaging system in an OEM product, for example. More ...

JMS Application Container Swiftlet

The JMS Application Container Swiftlet enables you to run your JMS applications as a component inside the SwiftMQ router. JMS applications use an intra-VM JMS client and are either defined statically or can be hot deployed (incl. version upgrades) during runtime. More ...

JBoss/JOnAS intra-VM Integration

SwiftMQ can now be integrated intra-VM in JBoss 3.0.3. We provide an MBean to start SwiftMQ as a JBoss service. Read the How To ...

The same works with JOnAS 2.6. Read the How To ...

Of course, everything is fully XA/ASF!


SwiftMQ 4.0.0 introduces versioned protocol stacks for SMQP/SMQPR, versioned JMS, JNDI, routing connections, route exchange, pub/sub subscription exchange, and management via SwiftMQ Explorer, CLI, CLI Admin API. Versioning enables clients, routers and management tools with different versions (different jar files) to interconnect and thus to upgrade large distributed systems and/or federated router networks smoothly without disrupting the whole system. More ...

High-Speed 2-Phase-Commit (XA) on Routing Connections

The Routing Swiftlet is completely new and now uses fully asynchronous and high-speed XA to exchange messages between routers. The size of the XA transactions (max. number of messages) as well as the window size (max. number of XA transactions in transit) are configurable. Recovery of in-doubt transactions after reconnect is fully automatically done by SwiftMQ's transaction managers on both sides of the line. Routing-XA is able to transfer multiple thousands of messages per seconds in both directons. More ...

JMS 1.1

SwiftMQ now implements the whole set of the JMS specification 1.1, including the JMS 1.1 XA and ASF parts.

Administratively Creation of Durable Subscribers

It is now possible to create durable subscribers administratively. More ...

Slow Subscriber Conditions and Static Remote Subscribers for Pub/Sub

A slow subscriber condition identifies a slow subscriber during the publish transaction and, if the condition matches, avoids to send further messages to those matching subscribers until the condition doesn't match with future publish transactions. Thus, a constant publishing rate is created. More ...

In a federated router network, subscriptions are exchanged dynamically between routers. If a router starts up, it has initially no knowledge about remote subscriptions. Once another router connects to this router, subscriptions are exchanged and messages are forwarded between the routers on base of these subscriptions. To enable message forwarding for times when a router has no remote subscriptions (it was just started and no other router has connected yet), static remote subscriptions can be defined. More ...

Pluggable Admin Frames and a new Queue Browser Facility

The SwiftMQ Explorer has been extended to support pluggable admin frames. We have added a new Queue Browser Facility to the SwiftMQ Explorer and CLI to view any queue on any router with the ability to delete a single or sets of messages. More ...

Management Authentication to protect Routers within Router Networks

Starting with this release, the access to the Management Swiftlet can be password protected and administration tools have to perform an additional authentication step to get access to the protected router. More ...

Minor Enhancements

  • JNDI: JNDI Replication now uses a keep-alive mechanism (lookup) to detect broken connections.
  • Deploy: Introduction of deploy spaces (multiple deploy directories) for hot deployment in different contexts.
  • Mgmt: new CLI commands "output", "view", "remove", "authenticate".
  • Explorer/CLI: Blanks are now permitted.
  • Network/JMS/Routing: Configurable network buffer sizes to handle very large messages more efficently.


  • JBoss/SwiftMQAdmin: A new InitialContext is now returned each time.


  • JMS: receiveNoWait delays 1s on every call if the queue is empty.
  • JMS: wrong behavior with msg.setStringProperty(name, null).
  • JMS: Single session, creating a new receiver to receive each message leads to double delivery (Problem: client consumer id was reused).
  • JMS: Message property names permit non-Java start/part characters and leads to problems when using it in message selectors.
  • JMS XA/ASF: setThreadContextCL/Objectmessage not set for SessionListener.
  • CLIS: waitForRouters, router event occurs before the main thread turns into wait and thus locked.
  • Store: StoreException when creating 500 queues via clis..
  • Deploy: System.getLibrary() fails on reboot with TimeTen.


Note: SwiftMQ 4.0.0 uses JMS 1.1 internally! You have to update your clients with the new jms.jar therefore. It is not enough to update the swiftmq.jar only!

  • Configuration compatible with previous releases: 3.0.0 (conversion to 4.0.0 takes place automatically on the first start up)
  • Class compatible with previous releases: No (Versioning starts with 4.0.0)
  • Message compatible with previous releases: No
  • Protocol compatible with previous releases: No (Versioning starts with 4.0.0)