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.

Immutant 2 (The Deuce) Beta3 Released

We're as excited as this puppy to announce The Deuce's very last (we hope!) beta release: Immutant 2.0.0-beta3! We intend to release our final 2.0.0 next Monday during Clojure/West.

We would appreciate all interested parties to try out this release and submit whatever issues you find ASAP. And, as always, big thanks to all our early adopters who provided invaluable feedback on the alpha, beta, and incremental releases.

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?

We have quite a few fixes in this release, as well as changes to a few things in the API that we wanted to get right before 2.0.0. The notable API changes are:

  • The concurrency for queue listeners now defaults to the number of cores to provide better messaging throughput out of the box (it was 1). The default for topic listeners remains at 1.
  • The :subscription-name option to immutant.messaging/context has been renamed to :client-id to remove confusion with the :subscription-name option to immutant.messaging/subscribe. Both are only used for durable topic subscribers.
  • immutant.messaging.pipeline/pipeline error handlers now get passed the decoded message instead of the Message object, and there is now a immutant.messaging.pipeline/retry function to ease retrying messages from the error handler.
  • You can now set the headers and status of an async HTTP channel response when calling immutant.web.async/send!. You can also now provide any valid Ring body type in addition to String and byte[] to send!.
  • The :on-complete option to immutant.web.async/send! has been replaced with two separate callback options: :on-success and :on-error.
  • immutant.transactions/manager is now a function instead of a value. If you were using the manager directly, you'll now need to invoke it.

For a full list of changes, see the issue list below.

lein-immutant 2.0.0

We've moved lein-immutant out of beta. The only changes in 2.0.0 over 2.0.0-beta1 are:

  • lein immutant war now properly honors a :main that points to a fully-qualified function in addition to a namespace
  • The test profile is now active when running lein immutant test

How to try it

If you're already familiar with Immutant 1.x, you should take a look at our migration guide. It's our attempt at keeping track of what we changed in the Clojure namespaces.

The guides are another good source of information, along with the rest of the apidoc.

For a working example, check out our Feature Demo application!

Get 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.

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.0-beta3

  • [IMMUTANT-261] - add cluster tests
  • [IMMUTANT-360] - Consider defaulting listener :concurrency based on the number of cores
  • [IMMUTANT-514] - Notes for improving the migration guide
  • [IMMUTANT-525] - wrap-resource from ring 1.3.2 breaks requests to / in WildFly
  • [IMMUTANT-527] - Session cookie attributes ignored in-container
  • [IMMUTANT-528] - Update docs to cover the whys and hows of destination creation in WF
  • [IMMUTANT-529] - Websocket On-Close is Not Called in All Cases
  • [IMMUTANT-531] - Expose Undertow's AJP listener
  • [IMMUTANT-532] - HTTP streams close after 30 seconds inside WildFly
  • [IMMUTANT-533] - ring request maps fail when used with clojure.core/find
  • [IMMUTANT-534] - Fix web/run options when they are passed as strings (ala lein run)
  • [IMMUTANT-535] - Completed scheduled jobs never go away
  • [IMMUTANT-536] - WildFly module should transitively depend on tools.nrepl
  • [IMMUTANT-537] - request/response times out when used against multiple remote servers with the same queue name
  • [IMMUTANT-538] - Review guides before release
  • [IMMUTANT-539] - Multiple schedulers with different options cannot be created
  • [IMMUTANT-540] - Expose internal quartz scheduler
  • [IMMUTANT-543] - :on-close callback for web.async channel not firing when client disappears
  • [IMMUTANT-544] - Throw when immutant.messaging.hornetq/set-address-settings is called in-container
  • [IMMUTANT-545] - Rename msg/context's :subscription-name back to :client-id
  • [IMMUTANT-546] - Calling immutant.scheduling/stop with no args throws NPE
  • [IMMUTANT-547] - Allow setting status and headers from async/send!
  • [IMMUTANT-548] - Transactions don't work from an uberjar
  • [IMMUTANT-549] - Allow sending ring bodies to channels
  • [IMMUTANT-550] - Replace :on-complete with :on-success & :on-error for async/send!
  • [IMMUTANT-553] - Don't create a transaction manager at compile time
  • [IMMUTANT-554] - Concurrent ws requests can cause a channel to be used for multiple clients in-container
  • [IMMUTANT-555] - pipeline error-handlers should be passed the decoded mesage
  • [IMMUTANT-556] - pipeline error-handlers should be able to retry a message and still deliver to the caller's future

Survey Results

A few weeks ago, we put out a short survey to gather information about how the community is actually using Immutant. We'd like to share our take on the results.

But first things first: THANK YOU! Time is currency in open-source, and we appreciate the 62 of you who spent a little of it feeding back your Immutant experience to us.

Given the small sample size and the non-rigorous approach we took to developing the questions, we can't really draw any statistically significant conclusions, but we can possibly get a general feel of the community.

Noteworthy items include:

  • It appears we need to do a bit better job of communicating the improvements of 2.x over 1.x. Of the minority of folks who evaluated Immutant and decided to use something else, most of them either hadn't actually used it or had only used 1.x. So we mayhap have some opportunity there.

  • There is a good bit of interest in clustering and a fairly high number of deployments to internal data centers. Those two are likely related. Immutant 2 is far more "cloud friendly" than its predecessor since it contains no app server, only libraries, so we may see more publicly-hosted deployments in the future.

  • Almost as many 2.x deployments in production as 1.x, even though 2.x is still in beta. We're going to chalk this up to the fact that 1) 2.x has been pretty stable over the course of its VERY long beta cycle, and b) 2.x is simpler than 1.x.

  • Of the folks that have used 2.x, almost as many have used it in WildFly as have embedded, which surprised us. We expected a larger percentage to be embedded users. It may be that some of the WildFly users came from 1.x, and appreciate the value of the container and clustering.

Take a gander at the the full results of the survey if you are so inclined.

Final Finally

2.0.0.Final is imminent! We're pretty excited about that! :)

As always, if you have any questions, comments, or issues with regards to Immutant, let us know.