Immutant 2.0.2 Patch Release

This patch release resolves issues with Websocket on-close handlers not being fired when close frames aren't actually sent.

What is Immutant?

Immutant is an integrated suite of Clojure libraries backed by Undertow for web, HornetQ for messaging, Infinispan for caching, Quartz for scheduling, and Narayana for transactions. Applications built with Immutant can optionally be deployed to a WildFly cluster for enhanced features. Its fundamental goal is to reduce the inherent incidental complexity in real world applications.

Get In Touch

If you have any questions, issues, or other feedback about Immutant, you can always find us on #immutant on freenode or our mailing lists.

Issues resolved in 2.0.2

  • [IMMUTANT-563] - on-close handler for async channels doesn't fire if server is stopped
  • [IMMUTANT-564] - Websocket on-close handlers not being called when Safari client goes away

Using ActiveMQ Artemis With Immutant

Artemis is a "new" JMS2-compatible message broker based on a merging of the ActiveMQ and HornetQ codebases, and represents the future of both projects.

Immutant is built on an abstraction layer called WunderBoss in order to share much of the implementation with our sibling project, TorqueBox. An additional advantage of this layer is it allows us (in theory) to easily switch out the underlying messaging implementation while keeping the same Clojure API. With the release of Artemis 1.0.0, we've now taken the opportunity to test that theory.

wunderboss-artemis

With only a couple of changes to WunderBoss that allow us to share the bulk of the existing JMS2 implementation between the HornetQ and Artemis adapters and make it easier to exclude the HornetQ dependencies, we're now able to provide wunderboss-artemis. It allows you to use Artemis instead of HornetQ as the message broker in an embedded application (it doesn't yet support Artemis if you are deploying to WildFly).

If you want to give it a try, you just need to depend on a recent incremental build (#585 or newer) and make a few adjustments to your :dependencies:

:dependencies [[org.immutant/messaging "2.x.incremental.585"
                :exclusions [org.projectodd.wunderboss/wunderboss-messaging-hornetq]]
               [org.projectodd.wunderboss/wunderboss-artemis "0.1.0"]]

If you then use messaging and see something like the following in your log output, you're all set!

14:12:44.471 INFO  [org.apache.activemq.artemis.core.server] (main) AMQ221020: Started Acceptor at localhost:5445 for protocols [CORE]
14:12:44.471 INFO  [org.apache.activemq.artemis.core.server] (main) AMQ221007: Server is now live
14:12:44.471 INFO  [org.apache.activemq.artemis.core.server] (main) AMQ221001: Apache ActiveMQ Artemis Message Broker version 1.0.0 [nodeID=2107a7c3-0a1c-11e5-955d-71ef037c4451]

Artemis is brand new - once it matures a bit, we may provide an immutant-artemis lib that would bring in wunderboss-artemis and provide an Artemis management namespace similar to the immutant.messaging.hornetq we currently provide.

As always, if you have any issues or feedback, feel free to get in touch.

An Immutant Plugin For Boot

Boot is an interesting new build tool for Clojure from Alan Dipert and Micha Niskin (if you're not familiar with it, Alan & Micha gave a great intro at Clojure/West).

To support the (probably enormous) set of Immutant 2.x users that use Boot and deploy to WildFly, we've ported the functionality of our lein-immutant plugin to Boot, and have released the cleverly-named boot-immutant.

boot-immutant provides two tasks: immutant-war and immutant-test, which are analogous to the immutant war and immutant test tasks from lein-immutant, respectively.

We consider the current release (0.3.0) beta quality. If you're in the set of users that would find this plugin useful, give it a try and let us know if you run in to any issues, either through the usual channels or by filing an issue.

Immutant 2.0.1 Patch Release

Despite our best efforts, the 2.0.0 release wasn't perfect. This release fixes the imperfections we're currently aware of.

What is Immutant?

Immutant is an integrated suite of Clojure libraries backed by Undertow for web, HornetQ for messaging, Infinispan for caching, Quartz for scheduling, and Narayana for transactions. Applications built with Immutant can optionally be deployed to a WildFly cluster for enhanced features. Its fundamental goal is to reduce the inherent incidental complexity in real world applications.

What's changed in this release?

Mainly the following:

  • Subscribing to remote topics now actually works
  • When running inside WildFly, if your :main doesn't return, we abort the deployment instead of letting it hang the deployer. See the WildFly guide for details.

See below for a full list of changes.

Get In Touch

If you have any questions, issues, or other feedback about Immutant, you can always find us on #immutant on freenode or our mailing lists.

Issues resolved in 2.0.1

  • [IMMUTANT-558] - Clarify that the :main fn must return for deployment to succeed in WildFly
  • [IMMUTANT-559] - Time out the :main calls that block
  • [IMMUTANT-560] - Subscribing to pre-existing topic on remote context throws NPE
  • [IMMUTANT-561] - Concurrent websocket requests can fail under load in-container on slow hardware

Immutant 2.0.0 Released (FINALLY!)

It was just last April that we announced our plans for the second major release of Immutant, code-named The Deuce. And today, a year later, we're happy to announce the end of our beta cycle and the first official release of Immutant 2.0.0.

We'd like to send out a big, fat THANK YOU! to all our early adopters who provided invaluable feedback on the alpha, beta, and incremental releases. It was a total community effort.

From this point forward, we're going to stick to the 3-digit release naming convention, so no more -alphaX or -betaX suffixes, just {major}.{minor}.{patch} numbers.

What is Immutant?

In case you didn't know...

Immutant is an integrated suite of Clojure libraries backed by Undertow for web, HornetQ for messaging, Infinispan for caching, Quartz for scheduling, and Narayana for transactions. Applications built with Immutant can optionally be deployed to a WildFly cluster for enhanced features. Its fundamental goal is to reduce the inherent incidental complexity in real world applications.

What's changed in this release?

The only change in this release since beta3 is a fix for a race condition in scheduling that generally only manifests on slow systems.

How to try it

There is no longer any "installation" step as there was in 1.x. Simply add the relevant dependency to your project as shown on Clojars. See the installation guide for more details.

The guides included in the apidoc are the best source of information, and our Feature Demo application provides working code samples demonstrating all the Immutant namespaces. Its README includes simple instructions for getting started at a REPL or command line, packaging and various deployment options, e.g. a standalone "uberjar", a WildFly cluster, Heroku and OpenShift.

If you're already familiar with Immutant 1.x, you should probably take a look at our migration guide.

Get In Touch

If you have any questions, issues, or other feedback about Immutant, you can always find us on #immutant on freenode or our mailing lists.