Introducing the WebSockets connector


To achieve efficient implementations with Async APIs, the need for new protocols and exchange patterns has become critical. Which is why we are excited to announce the release of the Mule WebSockets connector!

A WebSocket is a bi-directional, full-duplex, and persistent connection that is established on top of your existing HTTP infrastructure. Now, you no longer need to open new ports, modify firewalls, routers, or support new protocols. 

A Look into Error Handling in Mule 4 Beta

error handling mule 4 beta

If you ever used Mule 3, then there are probably two things about error handling you already know:

  1. It’s really Java exception handling
  2. It’s a “trial and error” experience

In this post, I’ll explain the major changes introduced in Mule 4 around error handling, including easier routing and the introduction of our new try scope.

How Automatic Streaming in Mule 4 Beta Works

automatic streaming mule 4

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.

The making of: Mule 3.6 Next-Gen HTTP Connector


You might have read Dan Diephouse’s post last month announcing the release of Mule 3.6, and if you haven’t – go read it! And then come back to this. Seriously.

Ok, so now that you’ve read about the new HTTP connector in Mule 3.6 and seen the cool demo that Dan put together it’s my turn to drill down into some of the more interesting details – why we built the new connector,

Handling File Attachments: handling multipart requests in Mule


Recently, I came across the following situation while working with Mule: I needed to handle an http post that would carry not one but N > 1 uploaded files.

If I were to do this back in the days where I didn’t know about such a thing called “Mule”, I would have needed to:

  • Handle a http multipart stream
  • Identify all the parts in the message
  • Read each file
  • Clean up

Of course there’re libraries and frameworks that can help you with this,

Error handling in Mule 3.3: Catch Exception Strategy


We put a lot of effort in Mule 3.3 to improve error handling in Mule ESB. One of the most common requirements during error handling was the ability to continue processing the same message that was being processed at the time of the exception. And that’s why that is the default behavior for the new exception strategies shipped with Mule 3.3.

Another very common use case was the need to differentiate between handled and unhandled exceptions within a flow.

Mule School: Invoking Java Component over HTTP


Since Mule is built on Java and Spring, it has native integration capabilities to invoke Java and Spring components. In this tutorial, we shall learn how to pass request received from HTTP endpoint on to Java component and receive response.

Please complete Hello World lesson from last week before proceeding further.

Agent-Based Synchronous HTTP Request Handling (A Recipe)


In the vast majority of cases, HTTP requests are processed synchronously: the operation that the client wants to perform on the targeted resource is executed by the same thread and the result is returned right away. This is usually done by connecting the HTTP layer directly to the service layer.

This post demonstrates a slightly different approach where HTTP requests are first sent to a messaging layer, then processed by dedicated agents whose responses are eventually returned synchronously to the client that is blocked waiting.

Push Web Integration with Mule and PubSubHubbub

September 22 2011


As discussed recently in this blog, web streaming APIs are a hot topic. One goal of streaming APIs is to reduce polling and replace it with resource efficient event-driven content distribution mechanisms.

With PubSub Huddle meetup happening in London today (unfortunately, I couldn’t go), it seems like good timing to tell you what we’ve done with one of the recently proposed protocols, PubSubHubbub (aka PuSH).

Feed my inbox; reading RSS feeds with Mule ESB – Part 2

February 24 2011

1 comment.

In my last blog post I showed a simple flow to retrieve an RSS feed periodically, split it and send each RSS entry via eMail. The solution has one major drawback, though: once the Mule application is restarted, Mule has forgotten which feed entries have already been sent. The RSS feed is retrieved again and another bunch of eMails is sent.

Adding idempotency

The standard EAI pattern for receiving messages only once is the idempotent receiver.