That is the summary of my first day at the summit.

First impressions: awesome presentations (I hope the videos will be online soon), high quality speakers, lots of interesting open-minded people talking about development, nice goodies, nice food, free beers and good coffee.

Other secondary impressions: it seems it is very trendy to talk about DevOps, or how to have developers and operations working in harmony. The other buzz word seems to be Paas – at least in communications from Red Hat (Openshift, Openstack, Docker…).

DevNation Opening Session, Neal Ford

After a good breakfast and a small recap of the DevNation agenda, the first talk was from Neal Ford, software architect, who I think is an independent consultant. His presentation was about the principles of agile architectures. If that sounds a bit “buzzy”, it was in fact very passionate and interesting, highlighting concrete good and bad architectural patterns when it comes to agility, i.e. being able to quickly to respond to changes. For example, the micro-services architecture (which recommend to have isolated independent services rather than a monolithic application) or the CQRS (Command and Query Responsibility Segregation) pattern when designing CRUD applications.

He also derives a bit to other conclusions:

Continuous delivery (i.e. reducing the time between the commit of code and the production of a ready-to-deliver artifact) is an ideal that one should achieve.
Dev and operations should work closely. And the maxim of Amazon has been quoted: “You build it, you run it”, then making developers responsible of the code they have made.
Reactivity should be preferred over planning, since changes are inevitable.

Inspecting JVMs with Hawtio, Stan Lewis

I wanted to attend this presentation since we are starting to investigate some monitoring tools which can be useful at work.

Hawtio is a monitoring and management web console. It comes de facto with Fuse or with Active MQ (which I am familiar with).

The good thing about Hawtio is that it is nice and extensible. It exists a variety of plugins to monitor and manage a wide range of things:

The JMX plugin enable to monitoring of any metrics and operations
The Health plugin can show a page as an aggregation of the health of different components or applications (think green/red panel to give a first-glance health of the systems)
The Active MQ plugin to monitor the queues and topics, send messages…
The Camel plugin enables the visualization (as a graph) monitoring of the different Camel routes. It enable also message tracing and debugging (we can set breakpoints in the route)
The log plugin to browse the log of an application
And much more: JBoss/Tomcat management, a dashboard panel to display any metrics, an OSGi console, a Wiki module to hosts application documentation…

Having the demonstration, it is possible to manage different hosts at the same time. It only requires to plug to an application where Jolokia is deployed (Jolokia is a Rest connector for JMX).

However, to my mind, Hawtio lacks some important feature : the persistence of the monitoring information or the management of JMX notification and alerting.

Resilient enterprise messaging with RH JBoss A-MQ, Scott McCarty and Scott Cranton

I went to this presentation but I did not learn a lot more than from the recommendations of the Active MQ documentation concerning the high-availability topology where it is recommended to have each Active MQ instance “backed-up” by a slave broker. In a network of broker topology involving N nodes, we then have to provision 2N brokers (one active and one passive for each node of the network). The active-passive is done via some locking (the master broker is the one holding the lock) and they should either share a same message store (RDMS or a NAS), either replicate it (but in that case the replication should be synchronous if one does not want to loose messages). The latest version of Active MQ (5.9) enables LevelDB as message store, which there replicates message to at least 2 other nodes (therefore requiring a 3N topology). Although exciting, the presenters said it was maybe not mature enough to risk a usage in production :-)

The presenters also talked about Fabric, which I was not very familiar with. Fabric eases the provisioning and the creation of the Active MQ instances and topologies by centralizing the configuration to the Fabric server. It therefore avoids the configuration of each activemq.xml configuration files.

With Fabric, Active MQ instances are given logical names and can be managed by groups. One can say easily sees which is active or passive, which Active MQ is connecting to which group, etc… We can also avoid the usage of the recommended 2N nodes by making a node agnostic of the Active MQ it is the slave of.

During this presentation Red Hat JBoss Fuse (and therefore AMQ) was just released under version 6.1.

Lunch

Why everyone needs DevOps now, Gene Kim

In this enthusiastic presentation, it was again an apology of the DevOps or why developers and operations should work closely. The presenter based his conclusions on a various of facts he gathered from various successful companies like Amazon, Facebook, Google, Netfix… He says for example that in Google developers are responsible for managing, maintaining and deploying their code in production for 6 months before an handover to operations.

The outcome are in fact the DevOps principles which can be summarized by:

Production releases should be done at a high rate (e.g. one every 10s on Amazon)
Environment creation should be fast and easy
Automation of testing is necessary
Monitoring is crucial so that developers can see potentially immediately their impact of their deliveries.

I was surprised that most of the analysis he did came from a book I read called “The Goal”, which is mainly about the manufacturing world, which he derived into a book called “The Phoenix Project”.

He also emphasized the concept of delivery of feature vs the delivery of code. He quoted the example of Facebook, which released the chat feature in production far before enabling it. It then enabled a “live” testing of the code (each users had some hidden “chat session” which tested the chat feature directly in production)…

JVM finalize Pitfall, Jason Greene

This presentation was probably the geekiest I attended today (and maybe for my whole life). But it was very good though…

The subject: the danger of implementing the finalize() method in a class.

The method finalize() is called by the JVM on an object right before it is garbage collected. And actually I have always been told that implementing this method was dangerous because of the performance overhead (the method calls before a GC) and most of all because of the nasty side effects (potential leaks or corruption).

So I was a bit surprised about the topic of the presentation. Why talking about the finalize() method?

It seems that the Java specification considers the implementation of finalize legitimate for a particular case: protect resource leaking by closing them on garbage collection. Think for example of a FileInputStream that the user has forgot to close in a finally block. Then this resource should be closed anyway, and this can be done in the finalize() method. Actually it is similar to the C++ destructor…

But implementing a finalize() has many dangers, especially because one does not know when GC is called… The presenter even presented us a case when GC could be called while in a method of an object which is garbage collected?! That was on OpenJDK. The explanation lies in the JDK implementation which may be doing some invisible optimization you do not know.

Hence some tips for doing this, that I won’t copy here since there are on the presenter GitHub. In a nutshell, they may involve synchonized or volatile keywords and they are not so easy to understand.

Middleware keynote

Here is the start of the Red Hat Summit. Previous presentations were DevNation ones. So as soon as the summit started the Moscone center started to be more and more crowded. Among others, colleagues of mine were there.

The Summit started with a keynote. And that was quite an American show. The auditorium was big, with big screens and broadcasting cameras everywhere…

The keynote was mostly about different trends the Middleware division of Red Hat is going to (Fuse, Vert.x, Fabric…), but the most interesting was the live demo where a bunch of Red Hat developers came on stage to demonstrate the whole middleware stack of red Hat.

So they gathered a pile of laptop in the middle of the stage, they installed Openstack and Openshift on them. They installed Fuse and some Camel routes listening to Twitter feed and sending to an Active MQ queue.

Another application built with JBoss BPM (i.e. jBPM) processes the message of the queue did some analytic, retrieved the Twitter user contact from RH Salesforce CRM (if a match exists) and it yes, send a text message to the user phone.

Quite and impressive demo actually.

Exhibition hall

After the keynote, we could stroll in the exhibition halls to see different partners. I had some talks with various guys from Red Hat and ElasticSearch which had a booth there.

There was also food and beer.

The final keynote and the 10 year celebration

Here the Jim Whiteburst, CEO of Red Hat, did a dynamic presentation. I was waiting for something like the “developers, developers, developers…” of Steve Balmers, but it was not really like this, but neverminds…

However, here we had the stress on the Paas strategy of Red Hat, something they call xPaas (for extended Paas).

Finally the day ended by a band with dancers suddenly appearing on the stage. The Red Hat Summit is indeed 10 years old, hence this celebration.

Hermes JMS is a great tool to monitor the activities on your JMS broker. Especially, it is quite useful to see what are the messages transiting in the queues and topics (you can also record them and replay them, which is pretty cool).

However, when you are monitoring the messages transiting in a queue, Hermes JMS only takes a snapshot of what is pending, i.e. not yet delivered. That means that if you have a consumer plugged on this queue, you will barely see any message since they are immediately consumed as they are sent (most of the cases at least)… It is a problem when you want to see the flow of messages, record it and replay it.

Mirrored queues

I am using Apache ActiveMQ as a JMS Broker. My solution for this broker is to use mirrored queues.

This feature of ActiveMQ enables to route messages from one destination to another without any external interventions. So if we route messages from the queue we want to monitor to a topic, messages coming to the queue will be automatically sent to the topic. If we subscribe to this topic with Hermes JMS, then we are able to see all messages which have been sent to the original queue. Indeed, topics are easier to monitor with Hermes JMS. We see there the continuous flow of messages as they arrive.

How is this done in ActiveMQ? I requires very few configuration in your activemq.xml.

First you need to configure the broker instance as enabling virtual topics:

<broker brokerName="localhost" 
   useVirtualTopics="true" 
   dataDirectory="${activemq.data}" ... >

Then, if we assume the queue to monitor is called test.queue and if you want to route the messages to be routes to a topic called test.queue.mirror, you have to create a destination interceptor:

<destinationInterceptors>
	<virtualDestinationInterceptor>
		<virtualDestinations>
			<compositeQueue name="test.queue" forwardOnly="false">
				<forwardTo>
					<topic physicalName="test.queue.mirror"/>
				</forwardTo>
			</compositeQueue>
		</virtualDestinations>
	</virtualDestinationInterceptor>		
</destinationInterceptors>

Be sure the queue and topic destinations exists as well:

<amq:destinations>
	<amq:queue physicalName="test.queue"></amq:queue>
	<amq:topic physicalName="test.queue.mirror"></amq:topic>
</amq:destinations>

Back to Hermes JMS

Here we are! Restart ActiveMQ and you will notice that when you send a message to queue.test, this message is also sent to test.queue.mirror.

Start to Hermes JMS and connect to the topic: you see the flow of messages sent to the queue arriving.

Clément Pinchedez

Tag Archives: ActiveMQ

Day 1: DevNation and the keynotes of Red Hat Summit