A proposal for immutable Docker containers to run the Drools engine

People don’t talk enough about rules engines, but they hold a lot of promise. Even if you’re not a financial institution or an insurance company, engineers and architects should consider them whenever they find the team writing too many algorithms with too many nested if/then conditionals.

Red Hat has an open source rules engine you’ve probably heard of — Drools. Drools is solid technology but there are many ways the core execution runtime gets bundled in various other products, so that flexibility and adaptability make it appear complex at first glance. I want to propose yet another open source permutation for you to consider, but I think it’s a lightweight one.

Let’s say your rules use cases are simple and you’ve got a small, engineering-driven environment

Let’s say you’ve got just a few rules you ever need to execute. The rules, which are written in DRL, are authored and maintained by the engineers, not business people. Given this, you believe all you really need is the open source Drools execution engine. But, you’ve got a bursty environment where you can suddenly have a lot of data show up that you want the rules engine to operate on. So you don’t want to run it embedded in your other code.

For this, may I propose immutable Docker containers running the Drools execution engine and either a REST-based or JMS-based messaging microservices entry point? Something like what Mauricio Salatino proposed.

Immutability, Docker, Drools, and (maybe even) Kubernetes might simplify things for you

Sure, my proposal means you’d lose a ton of the services that the Drools and jBPM team have worked hard to produce, but you’d buy some simplicity and possibly a different kind of scalability.

The developer’s architecture would be simple. The workflow for the developer would be as easy as modifying the DRL files, unit testing, and then committing. Ideally, you’d have Jenkins or Bamboo building the code, running integration and automated acceptance testing (may I suggest Cucumber for Drools??), and then build and push the Docker image.

The runtime architecture would be simple too. The server would pull the latest Docker-based runtime. The runtime would operate on the facts it receives from the microservice entry point. The DRL would be baked right into the container. Immutability.

And if you want to get scalable, you could use Kubernetes to orchestrate it all. (Incidentally, if this all sounds like OpenShift to you, you’d be right.)

To those on the leading edge, this proposal won’t shock you. But I thought it was worth writing up since I didn’t see anything else like it.

Did I join the ActiveMQ Developers list at a great time, or what

I joined the ActiveMQ Developers list to watch the sausage getting made. Maybe I just joined at a good time, or maybe it’s just always this entertaining…?

The background and the vote: Red Hat is donating HornetQ to the Apache Foundation. The ActiveMQ project management committee (“PMC”) needs to report to the board what they should name it and where they should house it. The community narrowly voted to rename it ActiveMQ Artemis instead of ActiveMQ Reactive (I thought reactive was a little confusing too).

The fight: a few of the developers suggested that HornetQ — I mean Artemis — should go to an incubation process first, but that turned out to not be the real issue. No, the real issue appears to be fears or paranoia concerns that the Fuse and Red Hat committers are controlling the code, the process, and effectively masterminding the ASF.

The way it looks is that Fuse/RH/(the Damarillo group), anyway you want to describe that faction is dead set on replacing the existing ActiveMQ with HornetQ (or whatever code name) in version 6 or 10. By keeping HornetQ under the ActiveMQ PMC influence its future will be heavily influenced by the already biased PMC and at the same time hide the lack of diversity in HornetQ. In the incubator, HornetQ will have the opportunity and freedom to grow in any direction and build a diverse community.

Then a response:

We’ve had lots folks from different companies agree with the direction that code contribution is going in. The fact that pin it on ‘Fuse/RH/(the Damarillo group)’ is very disingenuous and I think a poisonous position to take.

Then someone dropped words like evil, conspiracy, and even junta:

Which committer, specifically, could be brought into the PMC to try to counterbalance the alleged RH junta? I’m really discouraged by the insistence from a couple people that the only possible explanation of where we are now is an evil Winston/Fuse/RedHat conspiracy. I think it’s also just barely possible that after working all day people get tired. After providing unpaid all-waking-hours support for first jboss and then geronimo for many many years I sure did. This is not to say that there isn’t a strong need for more community involvement, but expecting the same people to do everything all the time is getting implausible.

Then getting HornetQ into the incubater became a matter of sacrificing oneself to protect Apache values:

Why not be open about it, advocate for it, work for it and build consensus and acceptance instead of putting everybody in front of a ‘take it or leave it’ choice. That’s what rubbed me the wrong way. That’s really not like the ASF I know. That’s why I made a conscious decision to be vocal about it and, in my mind, do my best to protect this community. This may cost me some personal relations, with people like you who are really extremely intelligent and
still do respect

Remember the Junta / Fuse / conspiracy stuff? Here’s one response from one of the alleged but as yet unindicted co-conspirators:

You are the second person to allege that I am acting with secret instructions and communications on this. I demand a pubic apology, immediately. I have done no such thing, all my communications with anyone about this issue have been on this list, and in reply to others raising similar issue on the pmc list. This is disgusting.

Who knew enterprise software could be so… dramatic.

UPDATE: the next morning, my IRC lit up with more conversation from some of the core ActiveMQ folks about yesterday’s discussions. Generally, they seem to think they discussions are good because they indicate people care passionately about ActiveMQ. And then this article appeared:

Ultimately, open source isn’t about code. It’s about community, and as Bert Hubert suggests, “community is the best predictor of the future of a project.” That community isn’t fostered by jerk project leads or corporate overlords pretending to be friendly foundations. It’s the heart of today’s biggest challenges in open source — as it was in the last decade.

Fun and profit in your first few hours with JBoss A-MQ

As part of my pitch to the Virtual JBoss User Group, I’ve been trying to think of the best way to explain how to get started with Red Hat JBoss A-MQ(A-MQ) and how to compare / contrast it with Apache ActiveMQ. While they share the same lineage, the user experience is very different.

So I thought I’d give you a few notes on how to play around with it and to visually work with the administrative interface. To follow along, you’ll need to download both Apache ActiveMQ and JBoss A-MQ because I’m going to rely on the example code bundled with ActiveMQ.

Discovering the A-MQ web interface

After starting A-MQ from the command line, navigate to the hawtio-based interface by loading http://localhost:8181, which is different from ActiveMQ’s default port. Login with username admin, password admin, which are the defaults, and you’ll see something like this:


Watching messages in the queue

Let’s start by sending and receiving some messages. By default, A-MQ runs only the OpenWire protocol. Since ActiveMQ ships example code with multiple protocols, let’s focus by opening ActiveMQ’s example code for OpenWire from this directory:

This code produces and consumes TextMessage messages through two classes: Producer and Listener. After Producer sends 10,000 messages, it sends a message with a body of “SHUTDOWN” which causes Consumer to shutdown and stop listening. To run this with A-MQ, you’ll need to change the hard coded user and password  to “admin” / “admin.”

To make the admin console come to life, we need to slow down the Listener and Producer before we run them because otherwise everything will happen so fast that you won’t be able to observe what’s happening on the hawtio interface. There are many ways to do this, but I just added some sleep statements in the code (about line 48 in Listener class):

Now let’s watch the messages. Start the Producer class and then the Consumer class (they each run independently). The hawtio interface should update pretty fast, and you’ll see this by default (I renamed my queue in the code to “test2,” which is why your queue name will probably say “example”):

a-mq active

Interesting information, but I really just want to know more about the messages actually flowing through the queue at this point. If you click on the “Edit Chart” button near the top, you can the information. I just picked “Queue Size” because I just want to know how many messages get queued up:


Now let’s run it again, but this time start the Producer first and then wait 20-30 seconds before starting the Consumer. You should see something like this:


Your Queue size should grow, stabilize for a while, and then start to shrink. Kind of cool. You might actually see a visual graph too — I think mine didn’t show up in the screenshot because I compressed the view.

Let’s send a message from A-MQ’s hawtio interface to your Java code

For me, I started a git repo on the ApacheMQ examples — you may want to do the same before you start the following example. Since we’re going to send a TextMessage from the hawtio web interface to our Java code, let’s add a little code to the while loop in the Listener class as follows:

As you can see, we’re going to listen for a TextMessage that says “HELLO.” Set a break point on the System.out if you want or just run the Listener class. The Listener is waiting for a message that says “HELLO”. Don’t start the Producer class this time.

Instead, return to the hawtio interface. Click on your queue, which is probably named “example” but could be whatever you named your queue from above (I named mine test2). Then click on “operations” in the context menu as follows:


Now, scroll down a bit and create a TextMessage by clicking on the ambiguously named option “Send text message(java.lang.string, java.lang.string, java.lang.string)” and enter the following:


If everything work correctly (and it always does on my machine, btw), then you should see something like the following:


Good luck out there, and let me know how your mileage varies…

Red Hat Summit / DevNation Call for Papers Extended a Week

You should consider submitting a talk for Red Hat’s Summit and Devnation conference coming up this summer. The deadline was tomorrow, but the organizers just extended the deadline another week to January 14th.


I guess the proposal I gave them wasn’t the proposal to end all proposals…

I’m a middleware consultant with Red Hat, so I’m trying to pitch (1) something about my current client’s JBoss Enterprise Application Platform (“EAP”) setup and its devops integration and/or something (2) about going reactive.

Submit your proposal here.

Forgot that obscure command you issued in Karaf/ServiceMix/Fuse a few months ago? Try this

So here’s a handy feature in Apache Karaf. Very similar to your bash console, Karaf remembers your command history, which is critical when you’ve completely forgotten that obscure command with the fourteen parameters you issued last time you were prepping for a sprint demo.

Here’s how to get it: From your Karaf command line, type: history. Think you can remember that much?


Great. But do you have way too much history to even begin to consider scrolling through your history? Try typing CTRL-R so you can quickly search your history:


Pro tip: So I wanted to search for my most recent “mvn” command to see the command I issued for my last Apache Karaf post. I had to hit CTRL-R a few times, which is important to know. Using the CTRL-R search just retrieves the first search result, so keep hitting CTRL-R to get the command you’re looking for.

Something surprising about working for Red Hat

redhatYou know I’ve always been a consultant at heart, even when that wasn’t my job title. People who know me know this isn’t hyperbole: the only thing that I really care about is doing a great job for my clients — whatever that may mean on any given day and whatever technology may be implicated.

As I started with Red Hat I assumed I’d still be completely unbiased. Even though I’d been a fan of Red Hat and JBoss for as long as I can remember, the only thing I care about at the end of the day is what actually needs to get done out in the real world. And since joining the company, I’ve been doing just that: helping clients resolve the normal issues that come up with big enterprise code bases and helping them improve or tune the way they’re doing things.

It was initially easy to stay the unbiased consultant.

It’s getting harder to stay unbiased though. More and more I find myself pulling for the JBoss (or whatever) code work… to deliver — but not because I work for the company but because I want all those hours of all those people, some of whom work for us but many who don’t, to be able to contribute to what my client’s doing. Having been close to the technology for a while now, I actually know the names of the people working on the technology, I know their blogs and their Twitter accounts, and I know how passionate they are about the code they’re creating. These people aren’t drones sitting in some cubicle. They’re out there in the community and they very much their own brands, but they want to work at this place and they want their work to be out in the community. Put differently, some of these people work for Red Hat and some don’t but you can know them almost as easily as I can.

And it’s infectious. Sometimes I find myself daydreaming that some issue or unexpected behavior of an obscure corner of the code will be broken and I’ll suddenly have an easy opportunity to submit a pull request and get to be a committer on Hibernate or the core EAP or Fuse or something. This is a first for me.

I didn’t know I’d feel like this when I signed up, but yeah… it’s kind of hard to stay unbiased when you know how much goes into it all and how any of us (you included) can be a part of it all — if you want to.

It’s a good surprise.

More open government data for LA — Hack for LA SOLD OUT this weekend

la-open-dataThe LA Mayor, Garcetti, announced that he’ll be rolling out a bunch of new open government data this weekend on crime, car accidents, street lights, business licenses, and other city data.

The site will be available here: data.lacity.org.

Garcetti made the data available just in time for the Hack for LA 2014, which is going on this weekend. Over 450 people went to 2013’s Hack For LA in Boyle Heights, and they submitted over forty apps. That’s really impressive… let’s see what they do with the new data this year. Don’t bother trying to register though — it’s SOLD OUT!

tech-laRelated, there’s a Los Angeles tech event hosted by the Mayor going on at city hall this weekend with an interesting mix of people — some start up people, some college people, some city people… looks like a really interesting mix.

Like the hackathon, this one is sold out too.

Code or people?

Open Source LADavid Hurley says you won’t find the true value of open source in the code. You won’t find it in product. You only find it when you look at the community of people behind any given project.

Few will ever start an argument with Hurley for imbuing us with such a warm glow. Sure, sure… you can’t have an open source “community” without people.

But is it even right to call us members of a community in the first place? Doesn’t the nature of open source “communities” really dilute the definition of “community?” Can a community really be organized by a for-profit company?

Isn’t it true to say that most projects only have a small number of core committers who actually share a vision for any give product? Is it fair to say that many other who submit pull requests just want to leave their individual mark on the codebase or enhance their resume? Or am I taking this too far?

I’m trying to provoke you because I think this would be a great topic to have a panel meetup about. What do you think? Join us on Open Source LA, and let’s talk about it.

Time to come back to Firefox? Maybe… just maybe…

I posted this in the Open Source LA meetup too, but I thought it was worth repeating here:

new-firefox-versionFull confession: I’ve been on Chrome basically since it came out. I abandoned Firefox years ago because it was slow, bloated, etc… In fact, in even fuller, richer, Technicolor confession: I even started the Open Source LA Meetup group using Chrome.

But I think it’s kind of serendipitous that on roughly the same day that I got the group launched, Firefox released a fantastic new version of the browser. And I don’t need to confess anything to tell you that I’m using it now.

I know all the blah, blah, blah with Mozilla and some guy named Brandon and so on… but maybe those just dark days for Mozilla’s and in a era of you-as-a-product-because-you-use-Chrome and a new era of conscientiousness around things like open source… maybe Mozilla’s (and Firefox’s) very best days are ahead.

In a bold move for me, I already made it my default browser.

Building an open source community

group-photoToday I created a new Meetup group called Open Source LA. I don’t know if it will go anywhere, but I think there’s room for this kind of group.

And I posted a message to the group, which currently consists of just me, paraphrasing David Hurley’s recent opensource.com post:

(1) You are still on the hook for support: just because you open source the project doesn’t mean that any developers are going to jump out there and answer support questions.

(2) You need to be the innovator: just because other people can fork and enhance your code doesn’t mean they will; your codebase will likely stagnate without your heavy involvement.

(3) Nurture your contributors: why should anyone help you? If you were building a community playground together, how would you encourage people to help? (Actually, Mr. Hurley put this point quite differently, but this is my post so I get to paraphrase.)

(4) Explain your mission, make it transparent, and stick to it closely.

(5) Fail fast: this is kind of obvious to me at a product level, but I think the idea of “failing” in front of a whole community by writing crappy code or making shoddy architectural choices is something a lot of coders — including me — fear. Don’t.

I hope you’ll consider joining my little Meetup group — or at least tell me why I should fail fast! The group is here: Open Source LA.