In our production environment we use ActiveMQ 5.4.3
We encouter a problem since we added the option schedulerSupport="true" in the broker. The problem encountered is : javax.jms.JMSException: PageFile is not loaded
I recently discovered that this problem is fixed in the version 5.8
Would it be a problem to use the jar activemq-all-5.8.0.jar with that broker or do I have to upgrade the broker from 5.4.3 to 5.8 too ?
Thanks
It's recommend that client and Broker use the same versions. In theory you can mix versions as the underlying Openwire protocol is backwards compatible however it's not something we test heavily. The usual case if that people can upgrade their Broker and need to leave client's behind and that is known to work better. The problem with mixing versions is that there may be bug fixes in one that are necessary for the other to function correctly so you might still see bad behaviour even though you think it should improve things.
Related
I would like to know are there feature wise same or different? Could you also mention any pros and cons about both of these? Also please mention real-world use case for both Embedded BrokerService vs installed ActiveMQ broker. Thanks in advance!
ActiveMQ is just a Java application, and the embedded version offers essentially the same features as the stand-alone version. In fact, you can configure an embedded broker to take its configuration from an XML file, in which case it will look very similar to the stand-alone broker.
Embedding a broker is a reasonable thing to do if you need the benefit of programmatic configuration; that is, you want to configure things according to rules which are hard to implement in an XML file. It also makes sense if you want close-coupled operation between the broker and the application components, with message data being passed in memory. This might be the situation if you're using JMS as an inter-module communication mechanism within the application.
Embedding a broker has the disadvantage -- and it can be a profound one -- of making it difficult to disentangle problems in the broker from problems in your application. Figuring out the cause of, say, runaway memory consumption could be very difficult. You can get commercial support for ActiveMQ, should you need it, but it will be hard for any commercial organization to support a hybrid broker+application installation.
I've currently got ActiveMQ 5.12.1 running and want to upgrade to ActiveMQ 5.14.1. I can't seem to find any documentation on upgrading from one version to another. Is it as simple as copying the files over? I don't want to lose any of my queues or subscribers.
The important data is in the persistence-store, i.e. typically KahaDB.
You can simply install the new ActiveMQ version and copy the store (or simply point it out if it's on a shared disk or whatnot) and all messages should remain.
Although the configuration is probably just fine to copy, I would make it a habit to look through the release notes of new features and improvements and see if there is something you can use. This is even more important if you use advanced AMQ features such as network of brokers or newer features where there are more updates, such as AMQP, MQTT and WebSockets.
If there is some major thing that needs attention from one version to another, there will be a note in the release-notes.
Planning to migrate Active MQ version form 5.5.1 to 5.11.2 how to migrate the existing messages from older version(5.5.1) to newer version(5.11.2)
Thanks in advance.
This assumes you have already taken care of any migration issues noted in each release note from 5.6.0 to 5.11.2.
There are essentially two ways to upgrade/migrate a broker.
Simply install the new broker and point out the old (kahaDB) database. This will automatically upgrade to a new version. This may cause some downtime during store upgrade (at least if there are a lot of messages in the store).
Have two parallell brokers running at once and let the old "fade out". You can setup a shiny new 5.11 broker side by side. This also makes it possible to migrate to other store types (JDBC or LevelDB). It's a little more work but will keep you uptime maximized. If you depend on message order, I would not recommend this method.
Setup the new broker.
Remove transportConnector from the old broker, and add a network connector from old to new.
Stop old, start new, start old.
Now, clients (using failover, right?) will fail over to the new broker and messages from the old brokers will be copied over to new as long as there are connected consumers on all queues.
When no more messages are left on old broker, shut it down and uninstall.
As with all upgrades, bypassing a lot of versions will make the upgrade less reliable. I would try some dry run upgrade of a production replica to ensure that everything goes as planned.
This would be my first time using ActiveMQ (instead of the out-of-the-box OpenMQ in GF) and I am trying to determine which approach is better in terms of scaling and maintaining an ActiveMQ environment. We do have experience in setting up and maintaining Glassfish clusters and deploy applications to it. But we are contemplating on what approach is better as we don't want to go down a rabbit hole that we can't get out of because we built environments around it and seeing towards the end that the infrastructure we had setup wouldn't scale.
Has anybody tried using both approaches? Even if anybody implemented one of the approaches with Glassfish, telling us their experience (gains and pains) would be very helpful and appreciated.
For 99% of cases, it's usually better to deploy a standalone broker - this way you're treating your messaging as just another layer of the infrastructure, much like a database. When a broker is standalone, you can set it up as highly available, upgrade it at will without modifying your applications (a broker can be upgraded without upgrading the client libraries), and can scale it out as appropriate later on if you need to (most projects don't).
I have seen people deploy brokers as embedded, with a convoluted network of brokers to get all the boxes in a cluster talking to each other. This usually ends in tears and reverting back to a separate master-slave pair of brokers. Which is all they needed all along.
I've been using RabbitMQ in a few setups now, and I can't shake the feeling that there must be something that's more easily set up. Despite it's conveniences it's hard to justify MQ for a solution that only processes a couple of thousand messages a day, simply because maintaining RabbitMQ is so much work.
Does anyone know an AMQP implementation with a simple installation and maintenance process?
For those who don't know it, RabbitMQ is an AMQP implementation written in Erlang. It is supposed to be very stable, but that is only really the case if you know enough about Erlang to avoid its problems. Whether it's memory limits or changes in the hostname, there is always a need to get deeper into it.
http://www.zeromq.org/ might be what you are looking for.
If you are on Windows you might use MSMQ
EDIT: I guess I missed the AMQP part of the question.
ActiveMQ seems to be good alternative, I was using RabbitMQ to set up "cluster" over WAN, which is not supported by RabbitMQ cluster, since it requires all machines within same location.
It seems ActiveMQ is better than RabbitMQ, in the sense that it is easy to set up and maintenance, for "cluster"
Apache Qpid is another open source AMQP broker: http://qpid.apache.org/
Disclaimer: I haven't used it myself so I can't tell you how it compares to RabbitMQ.