Skip to main content

JBOSS Openshift Queue Deployment

Deploying to Openshift is, in theory, as simple as git push. But if you've made any changes to the app-server environment you'll find it gets blitzed on deployment (this is actually a good thing since it'll force you to get into the habits of automating deployments).

To deal with this Openshift gives you the ability to define a set of action-hooks that get called during the various stages of the applications lifecycle.

These are just shell scripts and are pretty easy to define - just create a file in the .openshift/action_hooks directory in the project root matching the name of the hook you want.

In the case of queue deployment we need a post_start script which uses the JBOSS CLI to create queues.

The script .openshift/action_hooks/post_start looks like this:

echo "Starting JBOSS Queue Configuration..."
${OPENSHIFT_JBOSSAS_DIR}/bin/tools/jboss-cli.sh --connect controller=${OPENSHIFT_JBOSSAS_IP}:${OPENSHIFT_JBOSSAS_MANAGEMENT_NATIVE_PORT} --file=${OPENSHIFT_REPO_DIR}/cli/create-queues.cli
echo "JBOSS configuration complete!"


Make sure the script is executable via chmod +x .openshift/action_hooks/post_start.

The use of various environment variables ensures the script will work regardless of the configuration the image fires-up with and the "echo" commands ensures some sort of output is dumped to stdout during push for confirmation.

This script references a cli script (cli/create-queues.cli) looking like this:

jms-queue add --queue-address=queueA --entries=queue/QueueA
jms-queue add --queue-address=queueB --entries=queue/QueueB


And hey presto! On deployment you'll see a couple of messages output showing:

remote: Starting JBOSS Queue Configuration...
remote: JBOSS configuration complete!


And if you tail the logs (rhc tail -a ) you should see confirmation of the deployment as below:

2016/02/01 16:57:57,641 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-8) trying to deploy queue jms.queue.queueA
2016/02/01 16:57:57,644 INFO [org.jboss.as.messaging] (MSC service thread 1-8) JBAS011601: Bound messaging object to jndi name java:/queue/QueueA
2016/02/01 16:57:57,738 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-8) trying to deploy queue jms.queue.queueB
2016/02/01 16:57:57,740 INFO [org.jboss.as.messaging] (MSC service thread 1-8) JBAS011601: Bound messaging object to jndi name java:/queue/QueueB


Finally the JBOSS console will show your queues in all their glory...

JBOSS Queues

Comments

Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.