When you are using a certain version of Mule ESB you are going to run into an existing bug sooner or later. That isn’t really a problem, I would call it inevitable (at least based on my own experience). The big advantage of the open source idea is that you can dive into the source code and see where the problem is caused and fix it ( or at least work around it). I remember the time I was using Oracle Forms Developer to build applications. When you ran into a bug you had to wait until Oracle was ready to fix/patch it (or, of course, convince the client to not want that specific feature in their application).
Although its true you can find all known bugs for Mule in Jira, you still have to discover yourself your application is having a problem with that known issue. I recently implemented a new interface in our application and I started to make use of the CXF transport (until now it was mainly based on JMS and VM). The exception I got when processing a message was
java.io.IOException: Attempted read from closed stream.
The weird thing was, I didn’t get this exception when running my unit tests and it sometimes even worked in my deployed application.
As I said we got this exception when we added the CXF endpoint, although we did it as described in the manual. Well, to make a long story short, it appeared we were running into this issue. In our deployed version we make use of the Mule Notifications. We have extended the default Mule endpoints so they can indicate if a message they are processing should be logged. This logging is done by receiving the Notification and extracting the message from it. Then we log the payload of the MuleMessage as text in our database.
This works great as long the payload of the message isn’t an InputStream! in case of an InputStream the stream is read to make a String of it and since a InputStream can only be read once, the rest of the application cannot read it again (hence the ‘Attempted read from closed stream‘). This behaviour is described in Jira but you can image that it took some time before we realized we were running into this. Especially because the stack trace isn’t of much use in this case since it is pointing to some deep down CXF code that tries to read the input stream.
Next time someone has a similar issue and you are using Notification Handlers you might want to check these out and this way save yourself a lot of time looking for the cause of this issue.