Fear, Loathing and Windows Server 2008

Let me preface by stating I loathe and despise Windows. Excluding the desktop product from this rant, I had the unfortunate experience of dealing with their server product (in the forms of IIS, Sharepoint and AD) over a two year period. I've been lucky enough, since then, to avoid dealing with Windows directly. That is, however, until this week. As such, in an effort to save others pain here are some things I learned:

• The Java administrative tools (jstack, jmap, etc) don't work over RDP if you're connecting to a Java process running as a service. You instead get this helpful error: "Not enough storage is available to process this command". The solution is to download "PsExec" then preface the java commands with "PsExec -s".


• When running a 32-bit JVM, lowering the max amount of heap helps avoid this exception: "java.lang.OutOfMemoryError: unable to create new native thread". Details are here.


• There appear to be issues using NIO with Windows 2008 under concurrent load. If you're using the Apache Commons FileUtils stuff and are seeing weird NIO exceptions try using the Guava equivalents instead. The latter doesn't appear to use NIO under the covers.

MongoDB Transport 3.1.0.2 Released

I released version 3.1.0.2 of the MongoDB transport. This release, thanks to Craig Skinfill at OpenSky, introduces the "gridfs-file" message processor. gridfs-file allows you to load a single file from GridFS using either the payload of the message or a query. Documentation is available on MuleForge.

MongoDB Transport 3.1.0.1 Released

This blog is quickly becoming a release log for the MongoDB transport - I hope to have some content up soon. Until then I just released version 3.1.0.1 of the transport. Special thanks to Craig Skinfill and Steve Surowiec at OpenSky for suggesting and helping me test the fixed / new features. Here's some of what's new and improved:

• Query support on outbound-endpoints


• Misc upsert fixes


• Support for queries on updates


• Expression support added for queries

I don't like and didn't anticipate how complex behavior would become with the outbound-endpoints. As such I'm working on having the outbound-endpoints mirror the JDBC transport more closely, with nested configuration elements, rather then message properties, dictating the behavior of the endpoint.

MongoDB Transport 3.1.0.0 Released

I just released a new version of the Mule MongoDB transport. This is a major release that fixes a few bugs and introduces some new features. Thanks to David for suggesting and testing a lot of the new stuff.

Here's a list of what has changed:

• Mule 3.1 support


• Support for replica sets


• "dispatch_mode" support to specify how messages are dispatched to Mongo. This allows you to specify "insert","update" or "delete" on the outbound message to control how the payload impacts Mongo.


• A query parameter for updates has been added, allowing you to specify what documents will be updated.


• upsert and multi support is also in place for updates.


• Dependencies are now properly scoped.


• WriteConcerns are now supported.


• Deletion is now supported via dispatch_mode.


• Global endpoints are now fully supported.


• Flows are now fully supported.


As usual full documentation is available on MuleForge.

MongoDB Transport 3.0.1.1 Released

I just released version 3.0.1.1 of the MongoDB transport. This version populates an "objectId" outbound property, corresponding to the "_id" of the saved document or file, to messages sent to a collection or bucket. You can reference this property when chaining mongodb endpoints in a chaining-router or flow. This is primarily useful in creating subsequent DBRef's in the processing chain.

MongoDB Transport 3.0.1.0 Released

Just released version 3.0.1.0 of the MongoDB transport with, not surprisingly, full support for Mule 3.0.1. As usual details are on the Muleforge page.

Annotations in Mule 3

The official Mule 3 release was a couple of weeks ago, Ross covers a lot of the new features here. I've been using the release candidates for about two months in a few contexts. The MongoDB transport and SAAJ module have SNAPSHOT support for 3.x. David and I are working on upgrading the book examples over to Mule 3. I'm additionally using Mule 3 on a new project. We started on RC2 and are readying for an alpha release next week.

So, to sum it up, I've spent a lot of time recently with Mule 3. In doing so, I came to appreciate one of the nice "themes" of Mule 3.0: the reduction of configuration noise. Annotation support is a feature that particularly reinforces this. I refactored a couple of services that were using a Quartz inbound-endpoint to instead use the new @Schedule annotation. Here's what I did, hopefully it will illustrate how the XML configuration is cut down by some of the new annotations.

The service in question was responsible for executing a configurable command on the system and sending the output to an FTP server. An additional requirement is that the filename on the FTP server needs to have the timestamp of the command execution embedded in it.

Here's how I refactored the implementation to use Mule 3 annotations. First off, here's the service class:

/**
* Simple facility to run a system command and return the output as a String.
*/
public class CommandRunner {

 String command;

 @Schedule(interval = 5000)
 public String runCommand(@OutboundHeaders Map<String, Object> outHeaders) throws Exception {

     ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
     PumpStreamHandler streamHandler = new PumpStreamHandler(outputStream, System.out);

     CommandLine commandLine = CommandLine.parse(command);
     DefaultExecutor executor = new DefaultExecutor();
     executor.setStreamHandler(streamHandler);
     int exitValue = executor.execute(commandLine);    

     if (exitValue < 0) {
         throw new RuntimeException("Error running: " + command);
     }

     outputStream.close();
     outHeaders.put("COMMAND_TIME_STAMP",new Date().getTime());

     return new String(outputStream.toByteArray());
 }

 public void setCommand(String command) {
     this.command = command;
 }

}

The @Schedule annotation invokes the "runCommand" method every 5 seconds. Note that there is a Map being passed as the argument to runCommand(). This is annotated with @OutboundHeaders, indicating the contents of this map will be available as message properties on the outbound endpoint. We'll use this to set the COMMAND_TIME_STAMP header to contain the timestamp the command was run. That's it from the Java side. Let's see how this is wired up in the XML config:

<model name="Integration Services">
 <service name="CLI to FTP Service">
     <component>
         <spring-object bean="commandRunner"/>
     </component>
     <outbound>

         <pass-through-router>
             <ftp:outbound-endpoint user="${ftp.user}"
                                    password="${ftp.password}"
                                    host="${ftp.host}"
                                    port="${ftp.port}"
                                    path="${ftp.path}"
                                    outputPattern="#[header:COMMAND_TIME_STAMP].txt">
             </ftp:outbound-endpoint>
         </pass-through-router>
     </outbound>
 </service>
</model>

Using the @Schedule annotation eliminates the need for explicitly configuring an inbound-endpoint, which is missing from the above. We also don't need to jump through hoops with the MuleMessage in either the service class or with message-properties-transformers to use the COMMAND_TIME_STAMP to name the FTP file.

As I mentioned in my diatribe about implementing component classes, I prefer to avoid implementing Callable on my components. I find doing so couples the code too tightly to the Mule runtime. Using the annotations allows you to implement functionality previously required by getting at the MuleContext without extending or implementing a Mule class. This is a best-of-both-worlds scenario. Your component code can still stay decoupled from Mule, to ease unit testing, while indirectly giving you access to common pieces of the MuleContext (ie, the message payload, inbound and outbound headers, etc.)

So the annotation support, for me, is a welcome addition to the available configuration options. In addition to reducing XML noise it also streamlines integrating POJO's with the message flow.

The improved jBPM support on Mule 3 is another feature I'm excited about. For one reason or another, jBPM has been a constant in practically every Mule project I've worked on in the last year. I'll cover that in the next post.