OpenWire | ActiveMQ free implementation of the OpenWire protocol

Given simple configuration:

• Server - ActiveMQ
• Client1 - Producer. Sends messages using OPENWIRE protocol
• Client2 - Consumer. Receives messages using STOMP protocol

It works fine as long as we're using ActiveMQ 5.15.9. But it does not work with Artemis. In Artemis GUI I can see, that OPENWIRE protocol uses multicast queue with the name VirtualTopic.Some.Topic.Name and consumer with STOMP protocol uses multicast queue with the name /topic/VirtualTopic.Some.Topic.Name. And when Client1 (producer) sends a message, I can see this DEBUG log entry:

I have ActiveMQ Artemis 2.8.1 running and get the following error when I try to connect to it using a Spring Boot application over SSL.

We have multiple application servers in a cluster connecting to an instance of ActiveMQ Artemis 2.17.0. One of the applications will act as master and the remaining application servers will act as slave nodes.

The master will try to do drop the queue and recreates the queue before producing or consuming the messages as part of the data processing cycle.

Below is the exception stack we are observing in Artemis logs

I am trying to setup a cluster of ActiveMQ, using static mode. I have for the moment only 2 instances. One is TE5021 / 192.165.20.21, with this configuration file (extract):

I'm trying to migrate from ActiveMQ "Classic" to ActiveMQ Artemis.

We have a cluster of 2 active nodes that we try to migrate without impacting the consumers and producers. To do so, we stop the first node, migrate it, start it and do the same on the 2nd when the first is back up.

We are observing that the consumers/producers are not able to reconnect:

o.a.a.t.f.FailoverTransport | | Failed to connect to [tcp://172.17.233.92:63616?soTimeout=30000&soWriteTimeout=30000&keepAlive=true, tcp://172.17.233.93:63616?soTimeout=30000&soWriteTimeout=30000&keepAlive=true] after: 30 attempt(s) continuing to retry.

Consumers/producers are able to connect after we have restarted them. Is it normal behavior ?

Here is the ActiveMQ Artemis broker :

I'm trying to deploy ActiveMQ Artemis with Spring Boot and Docker. Artemis plus Spring Boot works fine. I'm using spring-boot-maven-plugin to generate a fat jar. When I try to deploy that fat jar into Docker I see that acceptor is started:

AMQ221020: Started EPOLL Acceptor at localhost:61616 for protocols [CORE]

But I'm not able to connect to it from outside of Docker.

Exception in thread "main" ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119013: Timed out waiting to receive cluster topology. Group:null]

I'm using this command to run it into Docker:

On my Windows machine I set up a local test cluster of 2 brokers (version 2.19.0): 1 master, 1 slave. The ha-policy is replication and cluster communicating goes over JGroups.

master broker.xml:

I'm using JMS on a Spring boot client to connect to an ActiveMQ Artemis broker over SSL. The client is able to connect regardless of the validity of the certificates in the truststore and even if invalid credentials are used. How do I ensure that the broker is filtering clients out based on the configured parameters?

The acceptors in the broker.xml are defined as show below. The SSL acceptor uses port 61617.

I'm using ActiveMQ Artemis 2.18.0 and version 2.5.5 of the spring-boot-starter-artemis dependency on a Spring Boot client. In my use case clients are required to communicate with each other via topics. The issue is that the string jms.topic. is getting prefixed to every topic defined on the client. For example the topic foo.sendInfo becomes jms.topic.foo.sendInfo.

The broker.xml file is as shown below. The acceptor used by the Spring Boot client is the netty-ssl-acceptor on port 61617.