Recently, I wrote about the difference between long-term support and continuous delivery releases of IBM MQ. In that discussion I pointed out that based on their traditional cadence that a new MQ release was not far off.

The meshIQ blog provides insights into pivotal and disruptive technologies, such as Hybrid Cloud, i2M, Messaging Middleware, AI, blockchain, and more contributed by MeshIQ experts and innovators.
Recently, I wrote about the difference between long-term support and continuous delivery releases of IBM MQ. In that discussion I pointed out that based on their traditional cadence that a new MQ release was not far off.
Are you like many enterprises, using a mix of messaging middleware applications including IBM MQ, Kafka and/or Tibco EMS?
And
Are you in the process of either moving some apps off of mainframes and in-house datacenters to the cloud, or starting to build news apps in new cloud environments?
Nastel RemoraJ, an open source, low overhead extensible Java Bytecode agent that allows you to perform application tracking.
This short video runs through how RemoraJ can be used with Nastel XRay to instrument a JBOSS application server and visualize and analyze a complex application.
It’s been four years since IBM MQ introduced Continuous Delivery (CD) and Long Term Support (LTS) releases.
The main objective was to give MQ users a choice between getting access to the latest and greatest features sooner than later (CD) or using a stable environment that had only bug fixes (LTS).
Previously I wrote about the difference in technology today compared to when MQ first came out. One of the areas that is most notable is network speed and how that relates to I/O as well as reliability.
1. Performance analysis for 3rd party Java software
2.
RemoraJ is an open source Java byte code instrumentation agent designed to help developers profile running Java apps with little overhead.
The focal point of RemoraJ is to provide visibility into what’s coming in and out of your java app by tracking calls such as HTTP, JDBC, JMS, WebSocket, IO Streams, Kafka and other inter JVM/IPC communications.
I recently had a technical problem to solve that had me stumped. My first reflex was to read the available documentation, hoping to find an answer. I didn’t find what I was looking for.
I thought I’d share our experiences of running Solr in production. So far Solr 6.6.6 has been very stable provided GC, memory and other system resources are carefully managed. Here are some of the technical details which I hope will be useful to anyone considering this platform.