AMQ7 is full of new and exciting technology and capabilities. However, with both routers and brokers now securing your topology can get confusing. Particularly securing the routers and learning how to use clients with them, using AMQP can be challenging for those of us used to using jks files and pure jms.

In this post, I wanted to address how to configure mKahaDB persistence storage on ActiveMQ for better management and reducing disk usage.

Default configured KahaDB persistence adapter works well when all the destinations (queues/topics) being managed by the broker have similar performance. However, an enterprise solution where several third parties are involved is never the case.

There are multiple queues or topics and different consumers or listeners listening to these queues/topics. Some consumers might be slower than other consumers. This will grow the message store’s disk usage rapidly. Due to this situation and being single KahaDB all store destinations might perform slow.

Last month was Arm TechCon, the annual developer conference showcasing offerings from Arm and its partners. Arm laid out its vision and strategy to achieving even greater integration in its processors and circumventing the slowing Moore’s law. As always, there was a bevy of new product announcements but overall, the show seemed to lack the energy of the last few years and especially the excitement of last year after Arm was acquired by Softbank. For example, there was no big vision keynote like the one last year from Masayoshi Son (Chairman & CEO of Softbank) who had talked of IoT enabling a Cambrian Explosion (which enabled thousands of new species on Earth), leading to 1 trillion IoT devices in 20 years.

It was more than 2 years ago that I blogged about building a Managed File Transfer (MFT) solution using Fuse and AMQ. First, many things have progressed, particularly the technology landscape. Second, MFT protocols have evolved. AS4 provides a new and improved way of securely exchanging documents over HTTP. In addition, the OASIS consortium governs a vendor-neutral open standard. This is great news, but how do we achieve support for these new standards and transports with our antiquated, legacy, and proprietary MFT software?

We know that containers in Openshift or Kubernetes don’t persist data. Every time we start an application, it is started in a new container with an immutable Docker image.
Hence, any persisted data in the file systems is lost when the container stops. Hence if an application or container is rebuilt or restarted than we can’t view previous logs or if we are using containers with mysql or any other database then schema, tables, and all data will be lost, if using any messaging broker than if there is journal file than it will also not persist.
Hence, these ephemeral containers cannot be used in production environment. In a production environment, we must configure a shared storage.

But what about the development environment, because we might not always have enough labs and VM’s available. To rescue we have volume type hostPath, which can be easily set up with Minishift and Minikube.

This article will provide details how to setup hostPath volume type.

Continue reading “How to configure persistent storage with OpenShift or Kubernetes for development environment”

We hear about Microservices a lot nowadays. Its implementation requires us to deal with new challenges. A key question that comes with using microservices is how to handle interactions in an asynchronous way. The answer to that is messaging.

Among other things, messaging features the following:

Loose coupling since it decouples client from services.

Improved availability since the message broker buffers messages until the consumer is able to process them.

One of the most famous products in messaging is JBoss A-MQ. Among the questions I receive from customers is whether it’s possible to run Red Hat JBoss A-MQ on Red Hat OpenShift. The answer is yes, Red Hat JBoss A-MQ (A-MQ) is available as a containerized image that is designed for use with OpenShift. It allows developers to quickly deploy an A-MQ message broker in a hybrid cloud environment.

The configuration of the broker can be performed two ways:

using the S2I (Source-to–image) tool. A complete example here that you can follow step by step: amq62-basic-s2i.