To close the loop on this - the higher connection rate seems to be related
to our use of JBoss, the active MQ resource adapter, and use of XA transactions:
https://issues.redhat.com/browse/ENTMQ-2087
https://access.redhat.com/solutions/3023001
Chris
On 2022-03-31, 12:17 PM,
2022-04-20 20:24:30,165 | INFO | The connection to 'tcp://??.??.??.??:44934'
is taking a long time to shutdown
We are seeing a slowly growing number of these messages flooding our logs since
transitioning to Amazon MQ (5.16.3) - they never occurred with our local
brokers.
The first group sta
I was purging ExpiryQueues and I noticed the following warning in our Artemis
logs.
We have a dual mirror setup. It's marked as a WARN, I'm just wondering what the
implications are, or if it should be filed as a bug (if so I'm not sure how to
reproduce).
2022-04-20 11:47:16,131 WARN
[org.apa
Hello,
switching from Artemis broker 2.20 to 2.21 we experienced an issue about
message delivering.
It looks like MQTT devices don’t receive the messages matching their
subscriptions.
The test code (***) run with an Artemis broker 2.19 or 2.20 as target (wildcard
addresses modified as (**)
For the subscription I’ll start a new thread as you suggested.
About the NPE I tried again to run the test from my Eclipse IDE (after
rebuilding all the images “mvn clean install -DskipITs -DskipTests -Pdocker”)
and the test environment seems to start correctly.
Which is your output of “docker i
