I’m very excited to announce that the October release of Dataloader.io is now available! It includes many new features, UI enhancements and bug fixes, which we hope it’ll make you love your data loader even more.
Picking up where Dirk Olmes left off in the post, Migrating a MuleForge project to Github, we now suggest a utility to facilitate the migration: svn2git.
svn2git is a tiny utility for migrating projects from Subversion to Git while keeping the trunk, branches and tags where they should be.
This involves three basic steps:
Step 1 is where svn2git is very appropriate. To use it, you just need to execute the command “svn2git” followed by the url of the svn repository and the utility does the rest. Great, isn’t it?
Step 2 is really easy. You simply go to github.com and, after logging in with a github account, create a repo following the help.github guide.
What Step 3 first requires you to add the directory to the git repository by executing
Next, the only thing left is to push all by executing
In most cases that’s it! The work is done. But we had some trouble while migrating our project. After executing Step 1, we received this error message:
After checking the process in more detail (adding –v to the command) we found the specific place where the mistake appeared:
To solve this, you only need to execute the fetch this way:
Problem solved!
Hope this helps. Good luck.
The Jenkins build systemhas an open API which means we can do stuff with it. Today we’re going to automate the deployment of an application with a specific stable version. Jenkins has a great UI, it’s very flexible indeed, but sometimes is not enough. For instance, for CloudHub we deploy a Jenkins build to our QA environment, according the period in our development cycle, and we also need to execute automated tests. However, we can create a quick web application to choose a version of an application in Jenkins to deploy, using Mule Studio and CloudHub.
So, here is a Mule application that gather information from Jenkins and even start builds using a UI that satisfy our need creating:
Continue reading One of the most common use cases while building flows/applications in mule is to be able to communicate to external systems. The performance of that external system is often beyond the user’s control. It could be possible where the rate at which mule flow sends the messages outbound is faster than the rate at which that external system could process the message. In such scenarios, there is a need to be able to perform some kind of throttling so that we don’t burden/break the external system. Again it is needless to say that the call to the external system could be synchronous or asynchronous depending on whether one cares to do some processing with the response or not. Our approach to throttling greatly depends on the exchange pattern of the outbound call to the external system.
The key here is to use the scheduler support provided by Active MQ.
Since we connect to ActiveMQ, we need to have the apache active mq library in the build path and the libraries required can be found here.
Before we go any further, please make sure that you have made the following changes to the activemq.xml file in the conf folder of your activemq installation.
Note: Restart activemq after making the config change.
We make use of AMQ_SCHEDULED_DELAY to inject a delay before being delivered by the broker.
Now lets look at how we throttle depending on the exchange pattern of the outbound call to the external system.
Now in scenarios where one does not care about the response that is returned by the external system, it is fairly simple. We just set the AMQ_SCHEDULED_DELAY before sending the message via the jms outbound endpoint.
Let’s consider a scenario where we receive http requests and perform some transformations and send it off to an external system via a one-way endpoint. In this case, we don’t care for the response that we get back from the external system. As discussed, the goal is to inject a delay before we send the message to the external system. To simplify things a little bit we just use a logger in place of the one way outbound endpoint (that makes the call to the external system). To perform throttling we split the original flow that would have been just an http inbound endpoint followed by the one way outbound endpoint (with some message processors in the middle) into two flows:
flow 1 that receives the requests via http inbound endpoint, introduces a delay using a message property followed by a jms outbound endpoint.
flow 2 that reads the message via the jms inbound end point and calls the external system(which is a logger in our example but it could really be any transport).
The complete configuration looks like:
It gets little interesting when one really cares about the response that is returned from the external system to be able to process downstream. To accomplish sychronous throttling we make use of request-reply router.
To simulate the call to the external system, we make use of VM endpoint with a request response exchange pattern. In this example we have three flows:
This flow receives requests via an http inbound endpoint, introduces a delay by setting the message property “AMQ_SCHEDULED_DELAY” and then JMS endpoints enclosed with in request-reply router.
This flow reads the message via jms inbound endpoint, and call the external system via an outbound endpoint with exchange pattern set to request-response.
This flow simulates the external system that will be called by the outbound endpoint in Flow2.
The bottomline is we are using the scheduler support provided by the JMS in stead of using some other not so clean ways like using a script to perform a thread.sleep(). This approach is lot cleaner.
Note: I’ve only evaluated this using ActiveMQ. From what I can see in documentation it should be supported by the most common platforms. Please feel free to comment if you have experience from using scheduler support with other platforms.
 |
MotivationWe are evaluating using Nagios or a similar Big Brother Enterprise solution for displaying information about our many Enterprise Mule instances, applications and the status of our production and staging environments. The only sure thing is that we presented a budget for buying a couple of 55” monitors and were approved. Pure awesomeness! |
This is complicated. We would have to hire a Java programmer to develop an agent to gather statistics from servers distributed in different geographical zones. Pretty heavy stuff. The project would take a while to complete. And once that is done, we would have to start worrying about upgrades, deployment of the agent, and paperwork. We are using a waterfall cycle. You know the pain.
We have expertise on our own infrastructure. We know how to handle Big Brother issues/configuration/maintenance. So what does the Mule team have to offer for gathering statistics about distributed Servers, apps and their corresponding status (among other things)?
We took a look at two possible approaches:
After comparing capabilities of both systems, we decided to go for the alerts. They are a better match for our needs: Notifications in almost real time for environment changes. For example:
 | Ah! How do we process the alert info? At first we thought about email alerts, but then we realized that trapping SNMP messages with our existing infrastructure was the way to go with Big Brother (in particular with Nagios). |
If you want to implement your own SNMP server or you want to set up a suite of integration tests, here is a basic implementation that allows you to trap MMC alerts.
 |
Basic SNMP server implementation to trap MMC alertsHere you can find a Java barebones implementation of an SNMP server optimized for MMC. A listener calls a method when a message arrives. There are two flavors of SNMP listeners: Version 1/2c (without authentication) and version 3 (with authentication). Once you instantiate the class by using one of the static methods (if you use the secure version, user, pass and passphrase will be requested), a listener will be binded on localhost to a port of your choice. After that, each time an alert is trapped, processPdu(…) will add the alert to an internal list for asynchronous retrieval (when getPduListAndClear() is called). |
 | The SNMP framework used is SNMP4J, which is also an open source project. |