I’m working with AddressControl and QueueControl objects in Artemis v2.32.0, and I noticed some surprising behavior with respect to sizes. I expected that the sum over all queues bound to an address of QueueControl#getPersistentSize() would yield (at least roughly) AddressControl#getAddressSize().

2024-05-21 15:40:38,522 WARN [org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection] Errors occurred during the buffering operation javax.jms.IllegalStateException: Transaction not started, XID:[1463898948,globalId=001ffffff8f60ffffffd4ffffffeb4f0002834b37448ffffffa6ffffffc07efffffffe75ffffffa6773a7922ffffffebffffffa9fffffff274ffffff97ffffffe149ffffffebffffffbb,branchId=001ffffff8f60ffffffd4ffffffeb4f0002834b37448ffffffa6ffffffc07efffffffe75ffffffa6773a7922ffffffebffffffa9fffffff274ffffff97ffffffe149ffffffebffffffbb000100000000000002] at org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processCommit(OpenWireConnection.java:1549) ~[artemis-openwire-protocol-2.33.0.jar:2.33.0] at org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processCommitTransactionTwoPhase(OpenWireConnection.java:1602) ~[artemis-openwire-protocol-2.33.0.jar:2.33.0] at org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:102) ~[activemq-client-5.18.3.jar:5.18.3] at org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.act(OpenWireConnection.java:366) ~[artemis-openwire-protocol-2.33.0.jar:2.33.0] at org.apache.activemq.artemis.utils.actors.ThresholdActor.doTask(ThresholdActor.java:68) ~[artemis-commons-2.33.0.jar:2.33.0] at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) ~[artemis-commons-2.33.0.jar:2.33.0] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:57) ~[artemis-commons-2.33.0.jar:2.33.0] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32) ~[artemis-commons-2.33.0.jar:2.33.0] at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:68) ~[artemis-commons-2.33.0.jar:2.33.0] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?] I am running Artemis version 2.33, which […]

I noticed that invoking QueueControl#removeAllMessages can return a value less than the number of messages in the queue seen by QueueControl#getMessageCount. I observed it to be up to 32,768 messages less when I simulated an unresponsive consumer. I tracked this down to prefetch (consumerWindowSize for Artemis clients) as the cause, which makes sense (and verified that setting prefetch to 0 caused us to result in a message count of 0 afterwards).

I am tuning the Artemis global-max-size attribute, and I noticed that when I set it to 90% of the JVM max heap, it OOMed in a load test I ran. I know the default is half the max memory available to the JVM, but for a broker with 32GB Xmx, for example, this feels too conservative of a limit. I understand that it likely OOMed in my case set to 90% given that Artemis does require memory to track internal state and queue information, but I’m trying to figure out what a good rule of thumb might be in order to keep us from OOMing but not waste resources. This is especially important as we do not page to disk. So we want to keep GC times low but also FAIL as an address full policy.

I’m trying to configure artemismq cluster with zookeeper lock manager using 2 machines. Zookeeper runs on 3 machines. Here is the parts of broker.xml file:

Goal I have a server, where all the traffic to any public IP goes through proxy. I have configured https_proxy and http_proxy. I want to connect to ActiveMQ Artemis running in cloud with public IP. Now, when I hit a curl command to ActiveMQ Management Console I get the response, which implies that I am […]

I’m aware that this method was unsafe in ActiveMQ Classic from a security perspective. However, using Artemis v2.32.0 with ActiveMQ Classic v5.16.0 client results in an ClassCastException when trying to Map<String, String> map = genericCast(message.getObjectProperty(key))

The MBeans for ConsumerCount on each queue, TotalConsumerCount and ConnectionCount are exposed but why not ProducerCount and SessionCount?

The MBeans for ConsumerCount on each queue, TotalConsumerCount and ConnectionCount are exposed but why not ProducerCount and SessionCount?

Im creating ActiveMQ Cluster using Jgroup Kubernetes Ping. After I have upgraded to ActiveMQ Artemis 2.33.0, Im getting java.lang.NoSuchMethodError. Seems like like [JGroups to 5.3.2.Final][1] has to do with something.