Maestro is a collection of tools that can be used for distributed performance testing. It is oriented towards testing of messaging oriented middleware (MOM), such as Apache ActiveMQ and its successor Apache Artemis , but can be extended to other performance test use cases.
Because Maestro forms a test cluster, it requires several components to run and deploying it can be tricky.
In order to simplify the development process as well as simplify it for users hoping to play with and run local tests, I created a set of containers (handled by Docker Compose) that can deploy a Maestro Test Cluster for local testing.
The process is extremely simple and you can go from 0 to the actual test execution in 3 commands (supposing docker-compose is already installed on your system):
There’s a lot of examples in the internet showing how you can obtain the IP address of a libvirt guest virtual machine. Most of the examples show how to do that when the network is using NAT forwarding (aka “Virtual Networks”).
However, how to do that if your setup is using Bridged Networking and your guests receive an IP address from an external DHCP server?
One idea is to install the read the DHCP leases file straight from the guest FS. You can do that by using the libguestfs-tools to cat the file within the image. For RHEL 6 (and CentOS 6 and similar distributions) the process is similar to this:
Just sharing some messaging tools I have been working with recently.
The first one is this performance test tool: msg-perf-tool. There’s no secret here: you run the tool and it does its best to bring your messaging system to its knees (though this may not be the correct way how to test it … check the testing tips on the Github page). For now it supports only AMQP, but Stomp and MQTT support is on the way. You can find rpms for RHEL/Centos (6 and 7) and Fedora (22, 23 and 24) for i686 and x86_64 on my Copr profile here.
The second one is a web page that can display the performance data stored on an ElasticSearch database and present it in a beautiful way. I call it messaging performance center. Here’s how it looks like:
Some bits are still in progress, but it’s functional.
Lastly, there’s litestomp. A C implementation of the Simple (or Streaming) Text Oriented Messaging Protocol. It was built on top of what-seems-to-be the now defunct libstomp project. There’s a couple of bugfixes, a simpler and higher level API for ease of use. Still a work in progress, but you can download the current rpms for RHEL/Centos (6 and 7) and Fedora (22, 23 and 24) for i686 and x86_64 from my Copr project page on this link.
This week I needed to show a colleague how to use Apache Camel, Apache CXF and Spring to create a web-based integration application. To do so, I created a Camel-based implementation of the Simple Apache CXF examples I wrote in 2012. Although this topic is covered more than once on Camel documentation, some details are either missing, which can make it tricky to run this setup this the first time, or are specific to a the application server where the code will run.
Therefore, I created this example (which you can find in this repository in my GitHub account) to complement the official documentation with additional details. I used the open source GlassFish application server to run the code.
It’s pretty common to need to set hostname or a port for your service in OpenShift. If you’re using Apache Commons Configuration, there’s a quick an easy way to access variables exported by the cartridges. You can address the environment variables using the ‘env’ prefix.