PlusOne - ActiveMQ 6.1.7 and Beyond with Matt Pavlovich
Video Summary
Rich Bowen and Matt Pavlovich discuss the evolution of ActiveMQ Classic, highlighting the transition from Java to Jakarta ecosystem and the release of ActiveMQ 6.0, which introduced Jakarta support and JMS 2.0. ActiveMQ 6.1 focuses on fixes and observability improvements, with 6.2 set to introduce a new configuration system and virtual threads. Pavlovich emphasizes the importance of unit tests and modernization efforts, such as MQTT 5 support and JDK 17/21 adoption. The project aims to enhance observability, support cloud environments, and make ActiveMQ easier to embed in applications.
The video can be seen on YouTube, and the audio only version can be found here.
Video Contents (18:38)
Rich Bowen 0:11
Hi Rich here frequent listeners, and I hope there's a few of you will notice that I'm doing two videos back to back about ActiveMQ, and that's because ActiveMQ has two sub projects under it, there's ActiveMQ Classic and ActiveMQ Artemis, as the name suggests, Classic is the older, more mature project, while Artemis is a newer one, although it's been around for a decade, these two projects have overlapping committers and similar missions, but different approaches. So in this week's episode, I'm covering a release of the classic project, and you'll notice a lot of the similar themes, but they are distinct projects. Welcome to plus one, the voice of the Apache Software Foundation. Today, I'm speaking with Matt Pavlovich. And as you will know if you've been watching these, I just did an interview with clever about ActiveMQ. And this is about ActiveMQ. But what you might not know is that this project has two sub projects that release independently, and whereas we were talking about Artemis in the other recording today, we're talking about ActiveMQ, sometimes called ActiveMQ Classic. Matt is one of the PMC members on this project. Thank you so much for making time for this.
Matt Pavlovich 1:42
Yeah, you're welcome. Hey, Rich, thanks for having me on again. Always love to share what's going on with the with the ActiveMQ project. Yeah, as you mentioned, I specifically focus on the active what, yeah, people call ActiveMQ, or sometimes referred to as ActiveMQ, Classic side of things. So this is the kind of, the core broker that started it all, and is continuing to develop and got its own roadmap. And yeah, we're excited to see where, where it goes here in the future, and talk about what we've already got in the we've already completed the last few releases.
Rich Bowen 2:13
Well, yeah, let's talk about that. So ActiveMQ 6 released, what, two years ago, year and a half ago, and 6.0 is currently listed on the website, is deprecated, and you're in the 6.1 branch with six dots coming sometime later. So let's talk about first let's start with 6 versus 5. What was, what was the big impetus for coming out with a new major version.
Matt Pavlovich 2:43
Yeah. So, you know, just everything in the Java ecosystem, Java ecosystem is really under a lot of change for good, for the better. So they're the one of the core impetuses is really the, it's two things. It's the Jakarta migration. So that's a whole another sidebar, but the short version of it is the APIs, or the interfaces that Java developers will use to talk to a lot of enterprise grade capabilities like transactions and databases and messaging and rest and web apps. All of those went under a conversion because now they're more they're more open source, they're more freely available. But as part of that, that little spec of that little line at the top of the of the Java code file that says, import javax.jms now needs to be kind of rewritten as import jakarta.jms. It's a great thing for the community as a whole. It's a little bit of a drag just to get, get over the transition home, but I think it's going really well across a lot of the Java community projects in Apache and, you know, and even outside other projects, because a lot of these projects work together, and they use each other's pieces and parts. So 6.0 was ActiveMQ 6. Was the first release where we applied support for Jakarta. With that came a lot of things. So namely Jakarta support. We also implemented and added a lot of the JMS 2.0 which is also known as the Jakarta 3.1 feature. So these were API updates that happened, you know, awhile back. ActiveMQ never really needed them, and the APIs were really compatible. ActiveMQ actually had another one of the key features there. ActiveMQ had, like a kind of an alternative that actually worked better when you're running it, but ultimately it was kind of a hold up for ActiveMQ to get into Jakarta. So we said, man, let's go ahead and get those. You know that JMS 2.0 that core functionality in as well as the Jakarta support, so that's what you get with 6, 6.0 was really that. Let's modernize the code base. We're moving to JDK 17. We're moving to Jakarta base. We're adding the JMS 2.0 APIs, moving to spring six. So it's a big, just kind of uplift. And as we got through that, a lot of great changes. At the same time, the community decided to start now that we have, now that we kind of unlocked the version 6.0 which was something. That was needed for a while, ActiveMQ is now making releases that are more closely adhered to semantic versioning. So what that means is, when we make big changes that would impact a developer or an administrator that's deploying it those version numbers, you know, it would go from six to seven. So if you see we'll clearly communicate when you see ActiveMQ 7 come out. This is gonna be a big change. There might be something admins need to dive in and look at, or even app code or say, hey, some things may have changed. And then that middle number is going to be where we do little features and little fixes along the way. And the last number is just going to be patches and fixes. So it's going to be much easier to consume ActiveMQ releases we're aligning more towards like an LTS strategy or an LTR strategy. So in ActiveMQ If you adopt, let's say 6.1 is kind of the current LTR or LTS you can, know, hey, there's not gonna be major changes or new features in 6.1. We're just gonna get, if we upgrade, we could, we should be able to just upgrade in place and get fixes and make it quick, kind of thing. So that was the big changes with 6. You know, within 6 we kind of got over the big hump. We quickly wanted to get to 6.1 so we could get those, those last little as we got feedback from the community on 6.0. We needed to get to 6.1 pretty quick. And we pushed some of those changes in that and 6.1 has been great. We've had, we're actually in the process of releasing another one here in the next couple of weeks, it'll be 6.1.8 but what you see in in 6.1 is a lot of improvements around fixes, getting dependency updates. There was a security fix that was really important for users to get, as well. But I think what you're seeing is, as users are taking in the 6 series, we're getting more enhancements around observability, any kind of little tweaks and things like the last couple of the last couple of last releases, a lot of things related to, like HTTP related transports around, if you're talking with WebSocket or STOMP some of this kind of secondary protocols, you're seeing those, those users start adopting and finding little things. And so we're just, you know, it's kind of a cleanup release, but it's, it's, we're excited about it. And then 6.2 is gonna be another big one that that will start putting us in a position to eventually get to 7 where we want to have better configuration. We want to remove the dependency on having spring to configure the broker. So really just geared up for how, how teams need brokers these days, which is I need to be able to run in any environment, whether it's cloud Kubernetes on prem embedded in my application active. That's really the benefit of ActiveMQ. It could do all these things. You could put it everywhere. And so yeah, 6.2 will be exciting where we'll put the next set of features for the 6 series, though, that'll be in 6.2.
Rich Bowen 7:35
So within the 6 or 6.1 branch, you can just upgrade in place and things keep working, right?
Matt Pavlovich 7:43
Yeah, absolutely, that's the goal. You can go back, and we've also, in the release notes, we made it a focus to really point and show developers like, what's changed, what's an improvement, what's a fix, what's the security and where the dependency upgrades. Some users package their own ActiveMQ. Some users embed it like inside a web application, they'll embed the broker, and so having that view of like the dependencies in the in the in the changes, will help them kind of consume it much more quickly.
Rich Bowen 8:10
One of the things that I ask frequently is where people can get involved in this project. You know, working with the team at work that works on this has become clear that understanding the code base deeply is challenging, but it's kind of a big, a big technical ramp up to get involved with the code. But if somebody wanted to get involved in the project, where would be a good place to dip their toes to start understanding what's going on?
Matt Pavlovich 8:38
Yeah, no, that's a great question. I'm glad you're asking. We definitely get a lot of users that, like, find little things and they want to make some enhancements. Or, like, you're talking about, like, teams of people. They're like, Hey, we're going to really get in and make want to start making big shifting changes. And the really, I think the best place to get involved is identifying some of the areas where we're working on modernization. So like, the unit test suite, we'd really like to get the total time it takes the tests to run right now, it takes, like, several hours to get all the tests run. And we went back, we did make a pass, and it looks like there's probably about an hour, an hour and a half of that test that could just get reduced, if we just had some time to go make these tests run faster, like use more modern approaches to timing and things like that. So jumping into unit tests is a great way to kind of learn how the broker works, how the project works. You know, also kind of getting familiar with the language. You know, brokers can be a they're really exciting because you get to understand how computers work, how disk io, network, you're balancing, like, all the resources. You know, I can kind of geek out, geek out on it a lot. But you're really kind of solving, you know, kind of everything about a computer, right? You're balancing IO, disk io, network io, CPU, lots of queues, lots of connections, moving data. So you really kind of get really close to the metal. So it's really kind of a fun place to work in. You get to understand security, how those things work. Optimization, observability, that's a big thing we're adding, is more observability. So one of the features that's going to be in 6.2 is message flow metrics. So people better look at a queue and see when's the last time a message came in, when's the last time a message was consumed. So we're doing a lot of things with that. Those are also areas where you can get in, make a change, but not have to know, like the in-depth of you know, the data store indexing and all these crazy thread safety things that might take, like, somebody that's newer, not just ActiveMQ, or maybe has, you know, doesn't have the 20 years of Java experience to dive in. Definitely start unit tests. We want to modernize the secondary, I don't really call them the secondary protocols, but the, the non JMS protocols, we want to modernize those so I think there's a great opportunity to get in, like, MQTT 5 support. I think is low hanging fruit. We could easily support it, and we just need someone to jump in and, like, start adding MQTT 5, things like that. So there's tons of opportunity. It's fun. And the other cool thing is, like, if you dove, jumped in, now, there's a lot of really good opportunity to learn, like, all the changes that come with the JDK, because as we're modernizing, we're starting to adopt like JDK 17, JDK 21 that's actually one of the exciting features that'll be in 6.2 is virtual thread support. And virtual threads are the new capability in the JDK that allow you to have more non-blocking IO without having to write reactive coding. So you get a lot of upside, and ActiveMQ is really well suited for that, because a lot of the internal locks are already like reentrant, which is the type of lock that works better with, with virtual threads. But there's going to be a couple of areas where there'll be hotspots and things like that. So there's gonna be a lot of cool things. So if you somebody were to come in start writing some tests, validating virtual threads, finding where those deadlocks are, there'd be an opportunity to work with, like the newer version of the JDKs, as they improve the virtual threading, then we kind of get a bunch of stuff for free. So like writing tests and all that stuff. It'd be neat. You'd be able to pump, pump out, like a lot of benchmarks and show improvements between versions, where all we've really done is change a little configuration, where how ActiveMQ is using Java, and it's like, boom, you get all this scalability benefit out of it. So
Rich Bowen 12:02
it's always cool to me to see a project that's almost 20 years old. So this project started in 2007 and has, has really adapted to the changes in the industry around it and has remained relevant. One of the things we talked about was just listening to the recording that we did in 2021 and you were talking then about how the whole industry had changed around you, and you had to adapt to it. And here we are, you know, just four years later, and you're talking about completely different architectural things. So that's pretty exciting, that the project has managed to stay vibrant and keep up with the industry.
Matt Pavlovich 12:40
Yeah, I think just the industry goes through cycles. And, you know, I've been in this, I've been at this a while, and I think there's just a couple of things that are like forever technology and message queues are one of them. They act as a balance between network, distance and location and things like that. And that's, you know, as long as we have computers in different places, you're always going to need queues and or as long as you want applications to have a little disconnect cues, and, you know, some of the other technologies around streaming and things like that have, have taken a run and have great use cases. But there's also things are like, streaming is not great, either from a not delivering on the on the same functionality or cost or complexity, or all of those things. And so I think people are coming back and looking at queues, especially as they're looking at from a cost perspective, running in the cloud, we help our customers get on board with this. One of the things that we see in cloud environments, and whether it's on prem or in public, one of the most expensive pieces of the solution is the disk. And if you want to buy fast disk, you got to buy big fast disk. And message keys don't always need massive terabytes of disk, but you got to buy them just to get the speed. And so I think people are looking for, hey, alternatives to if you're doing streaming or things like that, it's like, I don't need a two terabyte disk. So how can I do this? You know, performance effectively, but also cost effectively. And so I think, yeah, you're starting to see a lot more chat around queues, and that's exciting for us. You know, like you said, that the project's been around forever. It's got ton of burn in time on it. It's been used. And, you know, we, we know billions and billions of messages are being processed a day, and this is great. It's a great tool so, and it solves a lot of use cases. So we'll continue to modernize it and make it useful to developers and make it easier for developers. And I think ultimately that's what, what drives me is just, you know, helping people solve some of the stuff. Just, you know, computers can be hard, too hard sometimes, like, oh, let's make it easier for them. So that's what I tried to do.
Rich Bowen 14:31
Touched on this a little bit, but tell me about your roadmap going forward.
Matt Pavlovich 14:36
Yeah, I think in general, the goal is to make ActiveMQ easier to run in in different environments early on, like, a lot of the way ActiveMQ started, or most people started as using Spring. But we're also running into a lot of environments where, like, Spring is not always available, or there's some limitations in Spring, specifically, like, if you want to do runtime configuration updates, like enterprise grade, where you have like, where there's like, encryption and things. Like that. So some limitations, just with the current approach, with the way just Spring works. And so I think we're looking at, or the, one of the big things in 7 will be, you'll still be able to use the Spring configs people have used over long, you know, like you said, the past, you know, 15, 20, years. But we'll have a version of it you can boot up without Spring and making the configuration more modular, and the ability for it to dynamically update. So this is going to really help cloud environments. People that are using ActiveMQ as a cloud, like base queue-as-a-service, or platform-as-a-service, you'll be able to make configurations to like policies. So you could onboard, for example, you could have a cluster of 20 brokers that are servicing 200 applications, and you needed to deploy a new message flow. Well, those that configuration could be loaded dynamically without having to restart the entire environment. So really give you that platform queue-as-a-service. Along with that, there needs to be more observability. So when users and operators are looking at the broker, they need to be able to see, okay, what's going on. A lot of what has happened in 6 and then all the way up to 5.19, is observability around connections. So what's going on? How old is the connection? What's the status of the connection? What's the version of the client? So these kind of things, when you're when you're deploying ActiveMQ in a small environment, those things tend not to be a big issue. But if you're really connecting, like hundreds of applications, thousands of microservices you need to have on the platform side, the observability of what is the connection health? How are these connections authenticating? What's the version? So if you're the platform operator, you can say, hey, I need to go call the order team you guys. Hey, you're using an old version of a library. I need you got to update it for security policy or something, things like that. Or, Hey, you're not using SSL two-way. I need you to go do that. So a lot of capability around observability out of the broker, new configuration system that doesn't require Spring, and that's going to open up a lot more use cases. And there's a really key use case, which is embedding the broker, which I think a lot of microservices would benefit from, where you could, you literally just embed a small broker and then kind of push the data out, kind of make a broker mesh architecture, and when you have that Spring component in there, kind of it also kind of balloons your application. And so having this, like, really small, easy way to do that configuration is going to really open the door to that architecture, which is super valuable for applications. And I think a lot of applications are looking for that solution of, how do I asynchronously hand off a message, but don't have to wait for that whole round trip all over the remote broker, and that broker mesh architecture solves it. So really excited about that. So new configuration system, more observability Tech Preview on virtual threads. That's the exciting parts of the roadmap,
Rich Bowen 17:36
and that stuff that's targeted for 7 or for 6.2?
Matt Pavlovich 17:38
So 6.2 will have the virtual threads. The observability piece will kind of come in waves. So every kind of middle, 6.2, 6.3, 6.4, there'll be more observability metric added along the way. I talked about the connection ones. We've already done the message flow metrics. I'm also going to be contributing metrics around more the data store, so we can have more observability metrics around the index and the data store files, so people can see about health, about the data store, so those will come incrementally on the way to 7. The big thing with 7 will be the new configuration system without it not requiring spring.
Rich Bowen 18:10
Well, thank you so much for your time, and look forward to following the progress of the project as it goes along.
Matt Pavlovich 18:16
You're welcome rich. Thanks for having me on anytime.
