Month: October 2010

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 →

Flow in Action: Simple Orchestrations Pwned!

Posted on | by Aaron Landgraf | 1 Comment on Flow in Action: Simple Orchestrations Pwned!
Reading Time: 4 minutes

Three months ago, I’ve introduced the newly created Erlang Transport for Mule 3 in this blog. To illustrate a usage scenario for this transport, which allows fast and seamless bi-directional communications between the JVM and the Erlang worlds, I presented an example where Mule was exposing a JSON over HTTP service for provisioning users in RabbitMQ.

At that time, the new configuration mechanism named Flow was not fully baked so I implemented the example “Mule 2 style“, which means that I used Services tied together with VM queues.

Now that Mule 3.0.0 is out, my challenge for today’s post was to redo the configuration “Mule 3 style“, i.e. using by Flows.

mule_flow
Continue reading →

Taking a Rest from Code Camp 2010

Posted on | by Ken Yagen | Leave a Comment on Taking a Rest from Code Camp 2010
Reading Time: 3 minutes

Code Camp continues to grow by leaps and bounds each year. For those not familiar with Code Camp, it’s an all volunteer run conference at Foothill College each October and is on version 5.0. It lasts the whole weekend and this year over 3000 people registered and over 1900 ended up spending their weekend attending technical sessions ranging from How to Teach Programming to Kids to HTML5 Crash Course.

What I love about Code Camp is it represents the long tail of conferences and learning. Anyone can propose and lead a topic making it a great place for those that have an interest in speaking to technical audiences to cut their teeth. Even more important, you can find a talk on just about any subject. And with 3000 registrants, you are bound to find at least a dozen or more other people interested in the same. From a small sampling of my audience, this year’s hot topic was HTML5.

Continue reading →

Implementing Kanban for Sustaining Engineering

Posted on | by Ramiro Rinaudo | Leave a Comment on Implementing Kanban for Sustaining Engineering
Reading Time: 10 minutes

I’ve been working at MuleSoft on the Sustaining Engineering team for a few months. In this time I watched how things work and find out what type of challenges we deal everyday have and how we solved them. I watched a great team working long hours to solve customers problems as fast as possible. Our primary goal is to enable our customers to meet their deadlines, and remove any problem they might have with MuleSoft’s products in the process.

Context on the type of work

The sustaining engineering team works on solving problems for our customers, improving the code, implementing new features and reviewing how things behave to answer questions. Usually questions come from our customers, and sometimes we get high priority issues with high visibility. Critical issues may appear without any planning and they need to be solved as soon as possible. This type of events cause disruption in the team’s work. If any disruption propagates over time, it causes bigger or permanent problems. There is a mixture of high priority things popping up, with planned features or improvements.

Problems and challenges

This is the list of problems I’ve seen during this time.

Continue reading →