Enhancements
Extension Swiftlets
The release 1.2 implements a separation between the kernel and the Extension Swiftlets. Extension Swiftlets extend the functionality of a SwiftMQ router and are hot plug-in components. The SwiftMQ kernel and the respective Extension Swiftlets are offered in separate release lines. Thus, the release-frequency of the kernel is reduced obviously. Now, new functionalities may be added easily to a router as Extension Swiftlet.
Two Extension Swiftlets are offered with this release: JMS Bridge Extension Swiftlet and Mailer Extension Swiftlet. The JMS Bridge Extension Swiftlet permits to bridge queues and topics between a SwiftMQ router and any JMS 1.0.2 compliant systems as e.g. WebLogic JMS or MQSeries JMS. Through this, the possibilities to use SwiftMQ expand enormous and the users are in the position to compile a "best-of" messaging infrastructure. The Mailer Extension Swiftlet is able to send eMails and may be installed on any router within the network. The mailing is done by sending a JMS message to a queue. On demand, the Swiftlet sends a receipt to the JMS application after sending the mail. The recurring task to develop own mailsender applications is automated by the Mailer Extension Swiftlet and may be performed simply by a SwiftMQ router.
Programmatic Administration: CLI Admin API
An administration API on the basis of CLI is now provided concerning the programmatic administration. Whole router networks may be administered easily by this API using CLI commands from a Java program. As the API is based on CLI, one may learn it easily (no inconvenient, change-prone class libraries), but possesses the mightiness of CLI.
JNDI: Static Remote Queues
So far, it was impossible to perform a JNDI lookup on remote queues if the remote router has been disconnected because of the exclusively dynamic implementation of SwiftMQ's JNDI system. With this release, static definitions of remote queues are implemented. Through this, the local JNDI Swiftlet is now able to restore these destinations in the case of a lookup if the remote router is disconnected. However, one should keep in mind that a static route should also exists to this router because otherwise an InvalidDestinationException is thrown while creating senders or recipients.
Changes
Default JMS Delivery Mode
So far, the default delivery mode at SwiftMQ has been set to DeliveryMode.NON_PERSISTENT. The JMS specification, however, states the DeliveryMode.PERSISTENT. This has been changed. Now, the default delivery mode is DeliveryMode.PERSISTENT.
Unidentified Message Producer
QueueSender and TopicReceiver may be created unidentified. In this case, null is specified as Queue resp. as Topic parameter. The JMS specification states that only the send/publish methods, which do have a Queue resp. a Topic as parameter, may be used in the case of an unidentified producer. Contrariwise, only those methods may be used concerning an identified producer which do not have a Queue resp. a Topic as parameter. This has been changed according to the JMS specification. The call of unauthorized methods will throw an InvalidOperationException.
Foreign Messages
Subject to the JMS specification, a JMS provider needs to be able to process also messages of other JMS providers. These have been neglected hitherto. However, this is delivered subsequently in addition to this release. SwiftMQ is now able to process foreign messages. These are converted on-the-fly to SwiftMQ messages.
reset() on Stream/BytesMessages
Concerning this message type, the JMS specification states that the JMS provider performs a reset() after sending and receiving to set the message to the read-only mode. This has been changed subject to the JMS specification.
Bugfixes
Asynchronous close() on MessageConsumer
An asynchronous call of the close() method of a MessageConsumer led to an exception. This has been changed.
Multiple sending of the very same message
The multiple sending of the very same message without changing the contents led to an exception, if message compression was activated. This has been changed.
Exception on SwiftMQ Explorer startup
The SwiftMQ explorer saves the last screen position and the screen location in a property file within the user.home directory. If this file is corrupt, an exception occurred. This has been changed. The SwiftMQ explorer is now more fault-tolerant.
Multiple rollback leads to a redelivery of acknowledged messages
Due to a synchronization problem within the message buffer of a JMS client and the server, a multiple rollback sometimes led to a redelivery of already acknowledged messages. This has been changed.
Unreferenced non persistent messages on a queue's backstore
Because of a cache fault it could happen that after a rollback messages were saved within the queue backstore, which were no longer referenced and as a result were as well not deleted. This has been changed.
Upgrading from Release 1.1
The release 1.2 is fully configuration but not class compatible with the release 1.1. You cannot use a SwiftMQ 1.1 client or router with a SwiftMQ 1.2 client or router. If you have changed the standard SwiftMQ 1.1 configuration or if you have durable subscribers or persistent messages, you have to copy these objects to the new distribution as follows:
- Unpack the distribution as described in "Getting Started".
- Stop your router(s) and client(s).
- Copy your SwiftMQ 1.1 router configuration file(s) to the SwiftMQ 1.2 distributions 'conf' directory.
- Replace the complete 'store' directory of the SwiftMQ 1.2 distribution with the 'store' directory of your SwiftMQ 1.2 distribution.
- If you have the SwiftMQ 1.1 distribution in your CLASSPATH or start scripts, change this to the SwiftMQ 1.2 distribution.
- Start your router(s) and client(s).