Year: 2010

Dynamic port testing in Mule 3

Posted on | by dzapata | Leave a Comment on Dynamic port testing in Mule 3
Reading Time: 4 minutes

I wanted to write about a little project I have been working on which I added to the Mule testing framework recently: dynamic port testing.  As long as I have been working on the Mule ESB project, we have had weird random intermittent test failures which fail with a message like this:

Caused by: org.mule.transport.ConnectException: Failed to bind to uri 
at org.mule.transport.tcp.TcpMessageReceiver.doConnect(TcpMessageReceiver.java:81)
at org.mule.transport.http.HttpMessageReceiver.doConnect(HttpMessageReceiver.java:83)
at org.mule.transport.AbstractConnectable$3.doWork(AbstractConnectable.java:238)
at org.mule.retry.policies.AbstractPolicyTemplate.execute(AbstractPolicyTemplate.java:67)
... 50 more
Caused by: java.

.net

BindException: Address already in use

Most of the time, the condition is not reproducible and re-running the test again would pass.  After a lot of investigation/poking around, I traced the cause of the problem to be the OS not releasing the port quickly enough for the next test to use it.  This usually happened when the build machine was under high load.  That’s where dynamic port testing comes in.  Using variable substitution in our Mule test configuration files, I wrote a wrapper test framework class which looks for and assigns free ports to tests so we can avoid the ‘Address already in use’ condition.

If you are writing functional test cases for Mule ESB and would like to use dynamic ports, you simply need to do the following:

Continue reading →

OSGi? No Thanks

Posted on | by Ross Mason | 44 Comments on OSGi? No Thanks
Reading Time: 6 minutes

There have been bubbles of interest about OSGi in the Java community over recent years. I for one was very excited about the advent of a modular Java platform that freed us from the classloader issues in the JDK manifested best by Jakarta commons-logging (clogging our app servers).

OSGi was going to change everything, dependencies would be completely isolated (no more tripping over conflicting dependency versions), visibility and would be strictly enforced between each ‘bundle’. I was so bought into the promise of OSGi, like many others, I focused our engineering team on making Mule OSGi-enabled.

Continue reading →

Remote Mule bootstrapping from MMC

Posted on | by Julien Eluard | 1 Comment on Remote Mule bootstrapping from MMC
Reading Time: 2 minutes

One of the key point of Mule ESB Management Console (MMC) is facilitating administration of your Mule instances.

On top of all the features we plan for next releases we are starting to think about Mule instance remote bootstrapping. The idea would be to facilitate installation/upgrade of whole mule instances on remote machines, including new ones.

Because the world does not need yet another agent, MMC could leverage SSH to remotely:
* push well known Mule distribution images (eventually customized)
* setup environment
* setup Mule
* start and register in MMC this fresh instance

Continue reading →

Enabling devops through Tcat permissions

Posted on | by Dan Diephouse | Leave a Comment on Enabling devops through Tcat permissions
Reading Time: 5 minutes

In my previous post, I talked about what devops is and the need for devops tools around Tomcat. In this post, I want to go in depth around collaboration between devs and ops and how it applies to Tcat Server.

A key concept of the devops movement is that not only are there developers and operations, but there are also lots of people in between. Perhaps there is an ultimate authority on the operations team, but there are still many things you might want to enable developers or devops persons to do outside the operations team:

Continue reading →

REST constraints: A benefit-focused discussion, part 1

Posted on | by juergen.brendel | 1 Comment on REST constraints: A benefit-focused discussion, part 1
Reading Time: 18 minutes

REST – the REpresentational State Transfer as defined in Roy Fielding’s thesis –  is not a protocol, a standard, an API, a technology or a product. You cannot buy it, you can’t download and install it and you don’t need to poke another hole in your firewall for it. Instead, REST lives at a level completely decoupled form any specific technology, protocol or product, because REST is merely an architectural style: A set of constraints and principles, which should influence your system architecture decisions. When building a distributed system, you will end up with a RESTful architecture if you don’t just do whatever is technically possible, but instead voluntarily restrict yourself only to what is allowed in the narrow confines of those constraints.

While  working on a RESTful web-services platform, I came across a lot of discussions devoted to these REST constraints, sometimes arguing the point merely by quoting from Mr. Fielding’s thesis or more ominously warning about ‘bad things’, which could happen if not following the constraints to the letter.

But engineering is all about making the right compromises. Therefore, it is important to know the potential benefits of following a REST constraint and the issues you might have to deal with should you chose not to. Whenever we are told to restrict ourselves, it is only fair to ask “why?” That is the only way we as engineers, designers and architects can make an informed decision. So, in this small series of articles then I will explore those constraints with a firm focus on the actual, real-world benefits of the individual constraints.

Continue reading →

Re-use: Accomplished! Configuration Patterns Catalog for Mule

Posted on | by Aaron Landgraf | Leave a Comment on Re-use: Accomplished! Configuration Patterns Catalog for Mule
Reading Time: 6 minutes

If you follow this blog or what’s happening in Mule 3, you’ve heard about the newly introduced configuration mechanism based on patterns. In the coming releases of Mule, we will keep adding new patterns based on users feedback and requests.

But this doesn’t mean your experience with configuration patterns will be limited to the ones that come with Mule distributions: we have made it easy for you to create your own patterns and, even further, your own pattern catalogs.

Continue reading →

Tcat Server Restarts Extend, Improve, and Automate Stock Tomcat Restarts

Posted on | by jasonb | 1 Comment on Tcat Server Restarts Extend, Improve, and Automate Stock Tomcat Restarts
Reading Time: 22 minutes

You wouldn’t necessarily be very excited about reliable, graceful app server restarts — unless you go to restart your server and it doesn’t restart, or unless the restart script corrupted your webapp data. There are times when a reasonably fast, fully reliable restart is a very important feature. Some examples:

  • You found that your webapp has a new memory leak, and you just fixed it in development, just finished testing it, and you’re about to deploy the fixed version. But, first, you want to undeploy and restart the server to be completely sure the memory leak code is gone. While you’re doing this, your server is offline, and you want to get it serving again as soon as possible, so you run the restart command.. but it doesn’t stop. It stays running, and while you spend time trying to figure out why, your webapp is undeployed.
  • You have more traffic on your site, and now your memory utilization is climbing, and you’ve decided you should increase your Tomcat’s heap memory allocation. You make the configuration change, and you run the restart command, which runs and happily completes, but Tomcat doesn’t budge — it’s still running. You spend the next hour or two trying to figure out why.
  • You wrote a shell or batch script that changes your web site in a way that it also has to restart Tomcat to make all the right changes take effect. Your script runs Tomcat’s stop command, and then Tomcat’s start command. But, after using it a few times you find that the script isn’t successfully restarting Tomcat like that either due to an error. You spend lots of time looking for the cause of the problem…

If stock Tomcat restarts could both integrate well with the operating system, and also be fully reliable, it would save you time in cases like these, and it would allow you to automate more. We’ve cases like these with stock Tomcat, and we have improved server restarts as part of Tcat Server.

Let’s also define what we mean by reliable server restarts: When the administrator tells the server to restart, the server gracefully shuts down as quickly as reasonably possible, and immediately starts a new Tomcat JVM only after the original Tomcat JVM process is completely gone. When the administrator tells the server to stop, the restart script stops the JVM reliably. If for any reason the original Tomcat JVM was hung up on something during a stop operation and wasn’t going to exit, the restart script handles this case and (after waiting the appropriate/configurable timeout) kills the JVM process to make sure that it does not stay hanging and broken. When the restart script exits, it returns an exit code that reliably denotes whether the start, stop, or restart operation was successful. This exit code is a 100% reliable indicator of what the Tomcat JVM was doing at the time the restart script exited, so the exit code can be used by another script. The restart script also outputs textual information such that the person running the script can reliably see what is going on with the server.

Continue reading →

Devops and the role of Tcat Server

Posted on | by Dan Diephouse | Leave a Comment on Devops and the role of Tcat Server
Reading Time: 7 minutes

I’m pretty sure that if Dante was in IT, there would be at least one stage of hell devoted to getting developers and operations to work together well.  Horror stories abound. One of my favorite recent ones was about a company where the operations team wouldn’t let the developers surface any UI that they could access to manage their applications. The developers decided that they could get around this by building an API and then having a UI locally that they could use which was not in the realm of the operations team. Which, was a ridiculous waste of time and effort.

Granted not all companies are like this, but you can certainly understand why a division has arisen between the two groups. Developers are on the hook to deliver new functionality. Operations are on the hook to create a stable, secure, well run environment.  Developers push change. Operations resist.

On top of this, you have completely different sets of skills and knowledge, creating a gap between the two roles. In his, “What is this Devops Thing Anyway?” post, Stephon Nelson-Smith characterizes it like this:

Continue reading →

Deploy your applications while developing

Posted on | by Dirk Olmes | Leave a Comment on Deploy your applications while developing
Reading Time: 3 minutes

The Mule IDE 2.2.1 release that went out today contains a big productivity improvement: a hot deployment builder. It allows you to deploy your project to a running Mule 3 instance automatically. Read all about hot deployment in Mule 3 in the user guide.

The easiest way to get started with the hot deployment builder is to create a new Mule project. It will have the builder attached automatically. Note that the builder is only active when you create a new Mule project that is associated with a Mule 3 distribution. Projects that point to a Mule 2 distribution will still have the builder configured but it simply does nothing.

If you have an existing Mule IDE project and you want to use the hot deployment builder with it that’s possible, too: Simply right-click on the project and use the “Toggle Mule Nature” menu item from the context menu. As soon as you add the nature you will notice that the project icon changes slightly.

The hot deployment builder still has some rough edges but I wanted to publish it rather sooner than later to give Mule IDE users a chance to try it out. Please provide feedback if you find this feature useful.

If you have previously installed Mule IDE from the update site you can just check for updates and the new release should be downloaded and installed. See the Installation Guide for instructions how to install from scratch.

Walk this Way: Building AJAX apps with Mule

Posted on | by Ross Mason | 5 Comments on Walk this Way: Building AJAX apps with Mule
Reading Time: 9 minutes

There are some cool new features in Mule 3 for building AJAX applications. I figured I’d take you through a tour of the GPS Walker, an small example that demonstrates how to use AJAX to communicate from a Mule Service to the browser. This example uses other new features in Mule 3 including automatic JSON bindings, the @Schedule annotation and Flow.

Continue reading →