I have a chat application I created using Spring Boot with SockJS over STOMP backed by and external ActiveMQ Broker,
My issue is that after approximately 4000 client connection and 10000 ActiveMQ destinations, ActiveMQ crashes with out of memory relating to KahaDB.
I would like to switch to Apache Artemis as the blog mentioned it performs better than ActiveMQ and handles alot more client connection and also implements non-blocking in.
My hope was to just swap out ActiveMQ with Artemis, however, I see the clients connects and subscribe to topics and queues but they are not receiving the messages via Artemis.
And ideas what could be the issue?
Here is my settings in Artemis broker.xml config file:
<address-settings>
<!--default for catch all-->
<address-setting match="#">
<dead-letter-address>jms.queue.DLQ</dead-letter-address>
<expiry-address>jms.queue.ExpiryQueue</expiry-address>
<redelivery-delay>0</redelivery-delay>
<!-- with -1 only the global-max-size is in use for limiting -->
<max-size-bytes>-1</max-size-bytes>
<message-counter-history-day-limit>10</message-counter-history-day-limit>
<address-full-policy>PAGE</address-full-policy>
<auto-create-jms-queues>true</auto-create-jms-queues>
<auto-delete-jms-queues>true</auto-delete-jms-queues>
</address-setting>
</address-settings>
Any help would be much appreciated.
Thanks in advance.
With artemis, You should try the latest version available (1.5.2 at the time I'm writing this).
You probably need to change the address name and queue name accordingly with Artemis 1.x. (jms.queue and jms.topic) prefixes.
With the upcoming release of 2.0 the address model doesn't require prefixes any longer, but at the current version you may be hitting the issue of having to define prefixes on your application.
Feel free to start a discussion on the user's list, which is the place where contributors are mostly active.
Related
I have a Spring Boot application using Qpid JMS to speak AMQP with an ActiveMQ 5.15.14 broker. Even though the redelivery plugin is configured, the redelivery policies of the broker are ignored. However the redelivery policy of the client (Qpid) does come into play.
When the exact same code and client configuration is connected to a ActiveMQ Artemis broker, the redelivery policy of the broker kicks in which is what I'm looking for.
Anything you are aware of that could explain this different behavior between ActiveMQ 5 and ActiveMQ Artemis? Both brokers are using pretty much OOTB configuration aside from the redelivery policies, and schedulerSupport is enabled in my ActiveMQ 5 broker as well. Here's what the redelivey configuration looks like in activemq.xml:
<redeliveryPlugin fallbackToDeadLetter="true" sendToDlqIfMaxRetriesExceeded="true">
<redeliveryPolicyMap>
<redeliveryPolicyMap>
<defaultEntry>
<redeliveryPolicy initialRedeliveryDelay="5000" maximumRedeliveries="9" redeliveryDelay="60000" />
</defaultEntry>
</redeliveryPolicyMap>
</redeliveryPolicyMap>
</redeliveryPlugin>
One more thing to consider : the redelivery policies of the ActiveMQ 5 broker are applied when I use Openwire (JMS) instead of AMQP.
The AMQP protocol head in ActiveMQ 5.x is far more primitive than that of the Artemis broker implementation and is likely not reacting correct to the dispositions that are being sent back from the AMQP client. Also the 5.x broker can react differently based on the transformer setting in the 'transportConnector' on the broker which can be one of JMS, NATIVE or RAW. The JMS transformer will give the most ActiveMQ compatible behaviour but requires a complete transformation internally to an OpenWire message and then back to AMQP when going from AMQP sender to AMQP receiver which can hurt performance significantly. The NATIVE transformation will attempt to preserve some insights into the redelivered state of the message but won't catch every case most likely. With the RAW mode there will be no insight into the message delivery count at all and as such you definitely won't get any redelivery processing on the broker side.
I short, if you are looking for a fully functional AMQP broker then choose Artemis as it has had a lot of work, if you just need something that can get messages flowing then 5.x should work but don't expect the same quality of service.
While doing some load tests with the ActiveMQ Artemis broker and my Spring Boot application I am getting into performance issues.
What I am doing is, sending e.g. 12,000 messages per second to the broker with JMSeter and the application receives them and saves them to a DB. That works fine. But when I extend my application by a filter mechanism, which forwards events after saving to DB, back to the broker using jmsTemplate.send(destination, messageCreator) it goes very slow.
I first used ActiveMQ 5.x and there this mechanism works fine. There you could configure the ActiveMQConnectionFactory with setAsyncSend(true) to tune performance. For the ActiveMQ Artemis ConnectionFactory implementation there is no such a possibility. Is there another way to tune performance like in ActiveMQ 5.x?
I am using Apache ActiveMQ Artemis 2.16.0 (but also tried 2.15.0), artemis-jms-client 2.6.4, and Spring Boot 1.5.16.RELEASE.
The first thing to note is that you need to be very careful when using Spring's JmsTemplate to send messages as it employs a well-known anti-pattern that can really kill performance. It will actually create a new JMS connection, session, and producer for every message it sends. I recommend you use a connection pool like this one which is based on the ActiveMQ 5.x connection pool implementation but now supports JMS 2. For additional details about the danger of using JmsTemplate see the ActiveMQ documentation. This is also discussed in an article from Pivotal (i.e. the "owners" of Spring).
The second point here is that you can tune if persistent JMS messages are sent synchronously or not using the blockOnDurableSend URL property, e.g.:
tcp://localhost:61616?blockOnDurableSend=false
This will ensure that persistent JMS messages are sent asynchronously. This is discussed further in the ActiveMQ Artemis documentation.
I have a Python and Java Spring application communicating 2 ways. The stack is mostly built on Java/Spring so ActiveMQ and JMS were the logical choices. However, we added a Python application that needed to interact with the rest of the services so I used qpid proton (AMQP library) and added the following configuration inside the ActiveMQ configuration to get it working:
<transportConnectors>
<transportConnector name="openwire" uri="ssl://0.0.0.0:61617?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
<transportConnector name="amqps" uri="amqp+ssl://0.0.0.0:5671?maximumConnections=1000&wireFormat.maxFrameSize=104857600&transport.transformer=jms"/>
</transportConnectors>
which worked flawlessly on ActiveMQ and allowed to send/receive JMS TextMessage with an AMQP client.
Unfortunately, Amazon MQ refused this configuration and returned the following error:
The value 'amqp+ssl' of attribute 'name' on element 'transportConnector' is not valid with respect to its type, 'protocol'. and cvc-enumeration-valid: Value 'amqps' is not facet-valid with respect to enumeration '[openwire]'
AWS markets Amazon MQ as a managed ActiveMQ service but they seem to be lacking in functionalities since the mapping from AMQP to JMS has been available since version 5.8: https://activemq.apache.org/amqp and the Amazon MQ broker that I'm using is at version 5.15.12
I have tried adding the amp;transport.transformer=jms and transport.transformer=jms headers to the query string of the broker's URL, as well as using STOMP as the protocol (since it is a plain-text protocol) in the Python app instead of AMQP but none of these worked.
So, do you know any potential missing configurations or other ways I could send an AMQP message in my Python app and receive a JMS TextMessage in the Java app?
By default in the open source ActiveMQ 5.x code the AMQP transport already defaults to the JMS transformation so unless the Amazon version has altered that you shouldn't need to even set that explicitly if you want JMS transforms of the inbound AMQP messages. If they've altered that then you'd need to contact them to determine how to change that configuration.
Has anyone succeeded in creating a bridge between IBM MQSeries (MQS) and ActiveMQ Artemis 7.x (AMQ 7) so that the later can send messages to and receive from the first? Currently I have no problem bridging between MQS 7.5 and AMQ 6.3 by deploying a camel route and MQS libraries on the broker itself. However, the same way doesn't work anymore as each route deployment requires a broker reconfiguration and restart.
Thanks in advance for any feedback.
A few examples ship with ActiveMQ Artemis which might be helpful:
The "inter-broker-bridge" example in the examples/features/sub-modules/ directory. This example demonstrates how to deploy an instance of org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl to the broker using Spring in a web application.
The "camel" example in the examples/features/standard/ directory. This example demonstrates how to deploy a Camel route to the broker using Spring in a web application.
I can't speak to whether or not either of these can be updated at runtime as I've not actually attempted that. Both of these options should be able to move messages in either direction (i.e. from Artemis to MQS or from MQS to Artemis).
Another option would simply be to run Camel standalone and deploy your routes there. This would give you more flexibility as it would allow you to specifically choose the hardware where the routes run as well as how many resources the Camel JVM consumes. Running Camel routes directly on the broker, while convenient, isn't a great fit because the broker is a broker and not an application server.
To be clear, ActiveMQ Artemis and IBM MQSeries are not directly compatible with each other and are not expected to be. This true for most (if not all) JMS broker implementations. The role of components like the ActiveMQ Artemis JMS bridge and integration platforms like Camel are to solve the compatibility problem by using a common API to speak to both brokers - JMS in this case. Any broker which implements JMS can be integrated using these methods.
We are using the Spring JmsTemplate implementation with a CachingConnectionFactory. We have configured the connection with a failover-url:
failover:(ssl://172.16.0.11:61616,ssl://172.16.0.12:61616)?maxReconnectDelay=2000
On the transport connector in ActiveMQ we have enabled the option "rebalanceClusterClients":
<transportConnector name="openwire" uri="ssl://0.0.0.0:61616?maximumConnections=1000&wireFormat.maxFrameSize=104857600" rebalanceClusterClients="true">
<publishedAddressPolicy>
<publishedAddressPolicy publishedHostStrategy="IPADDRESS" />
</publishedAddressPolicy>
</transportConnector>
However, all of the clients are connecting to the first broker in the list of brokers instead of some of them being rebalanced to the second broker.
Previously we did not use the Spring JMS implementation, but instead we used the ActiveMQ libraries directly. This implementation did allow rebalancing the connected clients.
Is something in Spring preventing the rebalancing? Perhaps the CachingConnectionFactory?
EDIT 2019-07-10
I've found these two (p1 and p2) posts on SO where it is stated that CachingConnectionFactory doesn't play nicely with the failover-protocol. However, I think this has been resolved since then as we do see the connections moving between brokers if a broker is turned off.
What we do not see is connections being balanced across brokers. We did see this behavior when we were still using our own custom JMS implementation. So might it be something in Spring or the JmsTemplate?
The actual problem was not ActiveMQ or Spring rather an external firewall prevented this from working.