Need 77% performance boost? No problem with Mule 3.7 using Kryo

Currently, Mule relies on plain old java serialization in order to store objects to files or to replicate them through a Mule cluster. That imposes limitations on:

Batch Module: Obtaining the job instance id in Mule 3.7

A popular request among users of the Batch module is the ability to grab the job instance id in any of a Batch job’s phases. Why is that useful? Well, there could be a number of useful scenarios:

XSLT transformations: also faster since Mule 3.6

motif

speedspeed

This is a follow up to the last post in which we discussed performance improvements on our XPath functionality obtained from the revamped XPath and XSLT support in Mule 3.6. This time, we’ll go through the same exercise but for the XSLT use case.

The test

Just like with XPath, we worked with Luciano Gandini from the performance team.

XPath Performance boost using Mule 3.6

This character is QuickSilver and he’s the fastest of the X-Men. Mule 3.6 has no super powers, but when it comes to XPath, it’s the fastest ever! As you may remember, with the release of Mule 3.6.0 the XPath and XSLT was revamped. In this post, I’d like to not only continue elaborating on how great the improvement is, but also focus on a new aspect: Performance.

Mr. Batch and the Quest for the right Threading Profile

Sometimes (more often than we think), less concurrency is actually more. Not too long ago, I found myself in a conversation in which we were discussing non-blocking architectures, tuning, and performance. We were discussing that tuning for those models often starts with “2 threads per core” (2TPC). The discussion made me curious about how Mule’s batch module would perform if tested by 2TPC. I knew beforehand that 2TPC wouldn’t be so impressive on batch, mainly because it doesn’t use a non-blocking threading model.

Object Lifecycle and Dependency Injection in Mule 3.7

motif

Howdy! This is the last post of the Mule 3.7 series Be sure to check out the other posts in the series:

IMPORTANT: If you haven’t read the previous posts in this series, do so now. This will be very difficult to follow otherwise.

One to contain them all: Unifying the Mule Registry in 3.7

motif

In this post we’re going to continue the discussion started our last post “A sneak peek into Mule 3.7’s deepest internals” about how Mule’s registry, lifecycle and dependency injection mechanism are being overhauled in Mule 3.7. In this case, we’re going to take a deep dive into how we managed to unify the registries while keeping backwards compatibility and all the implications of such maneuvers.

A sneak peek into Mule 3.7’s deepest internals

motif

Mule 3.7 is approaching, and among other things we decided to put a lot of focus on the experience of the guy coding custom components (Devkit based or not). For this, the first 3.7 milestone is incorporating big changes in terms of the how Mule Lifecycle and Dependency Injection are applied.

As I said, these changes are BIG, so for clarity reasons we’ll cover them in a series of post starting with this one.

Exposing CXF webservice with Mule Cache

motif

guest_postguest_post
The first thing that comes to mind on Mule Cache scope is how to implement this cache mechanism with a webservice. Mule has a wonderful mechanism of caching with its cache scope, available in Anypoint Studio with Mule ESB Enterprise, and there are examples available on internet on how to extend the Mule caching mechanism with EHCache. Check out Mule caching with EHCache if you are still looking for an example.

Library upgrades in Mule ESB 3.6

motif

If you have read the Mule ESB 3.6 release notes then you already know what I’m about to say, but just to recap, here we go…

A lot of effort was put in 3.6 to upgrade our libraries stack. Even though we try to stay innovative, it doesn’t make sense to reinvent the wheel all the time, so we use a lot of third-party libraries. However, keeping those up-to-date while maintaining our strict backwards compatibility policy is something that’s really difficult to do.