Streaming in Mule 4 is now as easy as drinking beer!

There are incredible improvements in the way that Mule 4 enables you to process, access, transform, and stream data. For streaming specifically, Mule 4 enables multiple parallel data reads without side effects and without the user caching that data in memory first.

A lot of people are not familiar with the concept of streaming. So before we get into the specifics of streaming with Mule 4; let’s first go through a couple of use cases that highlight its value.

Read more

Welcome to the final post in the three post series about batch improvements on Mule 3.8!

The last new feature we have is a simple one which comes quite handy when you need to read through logs. As you know, batch jobs are just programs processed in batch mode, and each time the job is triggered, a new job instance is created and tracked separately. Each of those instances is unique and therefore has a unique ID.

Read more

Welcome back! Following the series about new batch features in Mule 3.8, the second most common request was being able to configure the batch block size.

What’s the block size?

In a traditional online processing model, each request is usually mapped to a worker thread. Regardless of the processing being synchronous, asynchronous, one-way, request-response, or even if the requests are temporarily buffered before being processed (like in the Disruptor or SEDA models), servers usually end up in this 1:1 relationship between a request and a running thread.

Read more

Hello there! If you’ve been using Mule for a while now, you probably remember that the batch module was introduced back in the 3.5 release. If you’re not familiar with it, you can familiarize yourself by following these links:

Read more

• Introducing the Batch module
• Batch Module Reloaded
• How to build a Batch enabled connector
• Near Real time syncs with the Batch Module
• Handling errors
• Tuning Batch Jobs

This all began with a very popular request: “We want to be able to throw an Exception from a flow”. The motivation for this is that it’s fairly common to run into “business errors” (errors not related to the handling and transmission of data but the data itself) which should actually be treated in the same way as a connection or system error (things like the remote endpoint is down).

Read more

If you have read the Mule ESB 3.7 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.7 to upgrade our libraries stack. That effort actually began in 3.6, and although the list of upgraded libraries is not so big as it was on that release, it’s somehow more significant given that we upgraded some dependencies that we held very close to our hearts and core.

Read more

A high-reliability application (one that has zero tolerance for message loss) not only requires the underlying ESB to be reliable, but that reliability needs to extend to individual connections. If your application uses a transactional transport such as JMS, VM, or DB, reliable messaging is ensured by the built-in support for transactions in the transport. This means, for example, that you can configure a transaction on a JMS inbound endpoint that makes sure messages are only removed from the JMS server when the transaction is committed. By doing this, you ensure that if an error occurs while processing the message, it will still be available for reprocessing.

Read more

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:

Read more

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:

Read more

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. He came up with a test in which he measures the transactions per second (TPS) and latency of two XSLT transformations which inverts the tags of an XML.

Read more