Nginx as reverse proxy for RabbitMQ MochiWeb server

Hi all,

I’ve suffered a hard day trying to find the solution to a problem that apparently has no a clear solution in the internet, at least, i couldn’t find it. So, i made mine.

RabbitMQ offers several plugins to enhance its usability, like the RabbitMQ management plugin (provides an HTTP-based API for management and monitoring of your RabbitMQ server, along with a browser-based UI and a command line tool) among others. Every plugin that requires any HTTP interaction works over a MochiWeb server automatically installed once installing the plugin. This server offers the 55672 port (default one) to interact with the API. For example, you can ask for the current RabbitMQ queues.

curl -u guest:guest http://localhost:55672/api/queues

In my case, i had to use Nginx web server as a reverse proxy for the MochiWeb server in order to have the management plugin web interface along with the default domain name, something like:

http://myserver/rabbitmq

Therefore, i configured Nginx in this super easy way:

location /rabbitmq/ { 
    proxy_pass http://0.0.0.0:55672/;
}

But the problems started when i tested the full web interface and there were some parts not working, like consulting the queues: go to the queues tab and click in a queue, you will get this:

Not found

The object you clicked on was not found; it may have been deleted on the server.

Continue reading

Advertisements

Fixing the postbuild order problem of the upstream/downstream solution i wrote

Some days ago i wrote a post about how to get the overall status in the upstream job from the downstream jobs in Hudson or Jenkins (https://fatalfailure.wordpress.com/2011/06/14/jenkins-hudson-getting-the-overall-status-in-the-upstream-job-from-the-downstream-jobs/).

A user (v22 ) test my code and had some problems, and actually, there is a problem.

As i said in the comment reply, there is a problem in the execution order of the post build actions, this is not deterministic and depends on how the job configuration is stored in a XML file located in the master node.

The relationship between the upstream jobs and the downstream jobs is ready when the fingerprints are recorded. This action is done on a post build action, like the Groovy execution. If the Groovy execution is performed before the fingerprint recording, there is not upstrem job set yet, therefore the Groovy code fails.

I proposed in that reply a workaround to change the order execution of the post build actions, but this is not working as i expected, so there is not a way to force the Groovy execution after the fingerprint recording.

There is an open ticket in the Jenkins and Hudson issue tracker to add a way to specify the post build actions executions: https://issues.jenkins-ci.org/browse/JENKINS-7408

But everything has a solution, and a solution that always works 😉

Continue reading

Jenkins / Hudson getting the overall status in the upstream job from the downstream jobs

Few days ago i asked in http://www.stackoverflow.com this question:

http://stackoverflow.com/questions/6141003/jenkins-hudson-upstream-job-does-not-get-the-status-ball-color-of-the-downstrea

I wanted to get the result of the upstream job depending on the result of the downstream jobs. I mean:

If in the upstream job i get a “stable” result but if in one of the downstream jobs i get an “unstable” or “failed” result i want to get the worst status in my upstream job.

In my case, i wanted to speed up the test execution paralellizing the build in different downstream jobs, therefore, i wanted to have the overall result of the build in the main job (the upstream) in order to see the result of the complete build in a single point.

I couldn’t find any good solution, only workarounds. So i started to investigate and discovered the best Jenkins / Hudson plugin i have ever seen: the Groovy Postbuild plugin

https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Postbuild+Plugin

With this plugin you can do almost whatever you want with Jenkins / Hudson. It allows you to execute a Groovy script in the post build phase and offers you the “build” and “hudson” Java objects.

The solution for my problem was a simple Groovy script added in the downstream jobs. This code gets the upstream job, access to the last build, check the result and if its result is better than the downstream one, it updates it.

This is the piece of code:

Continue reading