jbonofre's blog

Finally, after several months of work, Apache ActiveMQ 5.17.0 has been released. This is a major milestone in Apache ActiveMQ roadmap, bringing lot of changes, and already preparing ActiveMQ 5.18.x. Let's take a quick tour on some major changes in ActiveMQ 5.17.0. JDK 11+ If ActiveMQ 5.16.x already supported JDK 11+ at runtime, the build was still using JDK 8. ActiveMQ 5.17.0 now requires JDK 11+ for both build and runtime. Spring 5.x Before ActiveMQ 5.17.0, we used Spring 4.x, a deprecated (not maintained) version of Spring. It was a concern as Spring 5.x includes improvements and fixes, especially CVE fixes. So, it made sense to bump to Spring 5.x (latest available major version right now). From an user standpoint, nothing change, the main conf/activemq.xml is basically the same. Log4j 2.x If ActiveMQ 5.16.4 switched from log4j 1.x to reload4j, in order to fix CVE issues (see Apache ActiveMQ 5.16.4, reload4j and more for details). In ActiveMQ 5.17.x, we decided

Apache ActiveMQ 5.16.4 has just been released. This release is an important one on ActiveMQ 5.16.x series, bringing several important changes/fixes. Reload4j replaces log4j Apache ActiveMQ 5.16.3 is using log4j 1.x. If this log4j version is not impacted by log4shell vulnerability, it's affected by several security issue. reload4j ( https://reload4j.qos.ch/ ) is a fork of log4j 1.2.17 with the goal of fixing pressing security issues. Apache ActiveMQ 5.16.4 now uses reload4j 1.2.19, bringing the following security fixes compared to log4j 1.2.17: CVE-2021-4104 (JMSAppender) CVE-2022-23302 (JMSSink) CVE-2019-17571 (SocketServer) CVE-2020-9493 and CVE-2022-23307 (Chainsaw) 2022-23305 (JDBCAppender) broken MDC in newer JDKs XML entity injection attack CVE-2020-9488 (SMTPAppender) There's no impact for users: the conf/log4j.properties configuration file is the same as before, just the jar files changed. If ActiveMQ 5.17.x will use log4j 2.x, ActiveMQ

Apache ActiveMQ 5.16.3 has been released today. In this blog, I would like to highlights some changes we introduced in this release. Better Camel 3.x support and JMS2 dependency I've rewritten the Karaf features repository in ActiveMQ 5.16.3. Firt, the Karaf features doesn't contain inner repository anymore. The purpose is to let user pickup the version he wants at runtime. Concretely, it means that, in Karaf, ActiveMQ 5.16.3 can already use Spring 5 (fully Spring 5 support including in the ActiveMQ standalone distribution is already done on main branch for ActiveMQ 5.17.x). By the way, I will do similar improvement in Apache CXF and Apache Camel features repositories (removing inner repository to let users pick up at runtime), and Karaf will provides a spec features in a dedicated features repository. I also updated the range to support JMS 2.x dependency, instead of always forcing JMS 1.x. Even if ActiveMQ 5.16.3 doesn't really support JMS 2, you can already

Apache ActiveMQ 5.15.15 and 5.16.2 has been released. 5.15.15 is the last planned one on the 5.15.x branch, and contains only bug fixes. If you use ActiveMQ 5.15.x, you should upgrade to 5.16.x. Now, we are focusing on 5.16.x and coming 5.17.x (see later in this blog). ActiveMQ 5.16.2 brings important fixes and improvements. Let's take a quick tour ;) Fix on failover priorityBackup When you have brokers located on different networks, failver priortyBackup allows you to specify a preference to "local" broker. For instance, you can use a broker URL like this: failover:(tcp://local:61616,tcp://remote:61616)?randomize=false&priorityBackup=true With this URL, client will try to connect to tcp://local:61616 and stay connected there. The client will connect to remote only if local is not there. However, client will constantly try to reconnect to local . Once the client can do it (when local is back), he will automatically reconnect. By default, the first U

If you are using ActiveMQ, you probably use the default tcp transport connector configured in the conf/activemq.xml : <transportConnectors> <transportConnector name="openwire" uri="tcp://0.0.0.0:61616?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/> </transportConnectors> ActiveMQ also provides other transport connectors for some particular protocols ( amqp , mqtt , stomp ) or particular transports. Especially, it supports a very convenient transport connector to go through firewalls: the http transport connector (and extended from http like https , etc. It means that it’s possible to load balance the HTTP connections. We won’t be able to balance the messages (we need a network of brokers for that, see previous blog posts about that. However, the HTTP transport is based on the openwire protocol. So, it’s not just a HTTP request to send a message: the client has to send several HTTP requests to establi

When you use Apache Camel routes for your integration, when a failure occurs, a classic pattern is to retry the message. That’s especially true for the recoverable errors: for instance, if you have a network outage, you can replay the messages, hoping we will have a network recovery. In Apache Camel, this redelivery policy is configured in the error handler. The default and dead letter error handlers supports such policy. However, by default, the redelivered exchange is stored in memory, and new exchanges are not coming through since the first redelivered exchange with exception is not flagged as “handled”. This approach could be an issue as if you restart the container hosting the Camel route (like Apache Karaf), the exchange is lost. More other, in term of performance, we might want to still get the exchanges going through. There are several solutions to achieve this. In this blog, I will illustrate a possible implementation of a persistent redelivery policy with backoff support. Apa

Apache JMeter is a great tool for testing, especially performance testing. It provides a lot of samplers that you can use to test your web services, web applications, etc. It also includes a couple of samplers for JMS that we can use with ActiveMQ. The source code of this blog post is https://github.com/jbonofre/blog-jmeter . Preparing JMeter for ActiveMQ For this article, I downloaded JMeter 2.10 from http://jmeter.apache.org . We uncompress jmeter in a folder: $ tar zxvf apache-jmeter-2.10.tgz We are going to create a test plan for ActiveMQ. After downloading ActiveMQ 5.9.0 from http://activemq.apache.org , we install and start an ActiveMQ broker on the machine. $ tar zxvf apache-activemq-5.9.0-bin.tar.gz$ cd apache-activemq-5.9.0/bin$ ./activemq console... INFO | Apache ActiveMQ 5.9.0 (localhost, ID:latitude-45782-1409139630277-0:1) started In order to use ActiveMQ with JMeter, we have to copy the activemq-all-5.9.0.jar file provided in the ActiveMQ distribution into the JMeter lib

With my ActiveMQ friends (especially Dejan and Claus), I’m working on ActiveMQ 5.9 next release. Today, I focus on the HA with ActiveMQ, and especially Master-Slave configuration. Update of the documentation The first thing that I noticed is that the documentation is not really up to date. If you do a search on the ActiveMQ website about Master-Slave, you will probably find these two links: http://activemq.apache.org/kahadb-master-slave.html http://activemq.apache.org/shared-file-system-master-slave.html On the first link (about KahaDB), we can see a note “This is under review – and not currently supported”. It’s confusing for the users as this mechanism is the prefered one ! On the other hand, the second link should be flagged as deprecated as this mechanism is no more maintained. I sent a message on the dev mailing list to updated these pages. Lease Database Locker to avoid “dual masters” In my test cases, I used a JDBC database backend (MySQL) for HA (instead of using KahaDB). I hav