4 Replies Latest reply on May 7, 2013 8:53 AM by Alfred Holzinger

    Application design/architecture to support HornetQ upgrades

    Alfred Holzinger Newbie

      Today we have a enterprise system transferring data with the file mechanism. This will be replaced with a messaging oriented architecture and we have chosen HornetQ. Performance and Large Messages work well for us.


      We are embedding HornetQ (currently on 2.3.0.Final) in our Java application running under OSGI/Apache Karaf. One important issue is how to upgrade HornetQ in a good way (e.g. 2.3.0 -> 2.4.0 -> 3.0.0) in our live environments. Our system will have 100+ HornetQ Instances. One server will have one HornetQ instance. The servers are maintained by multiple companies. The topology is hub like. A couple of central servers that forward messages to other servers.  We will need to be able to run 2 different HornetQ versions in parallel and upgrade the enterprise system gradually. Upgrades should take place within days or weeks.



      1. Are there any best practices to upgrade a Enterprise system from a HornetQ perspective?

      2. Are there any considerations to support upgrades in a good way from a application design/architecture?


      I've not found information to this in the HornetQ community sites and not in the HornetQ documentation. Different HornetQ versions will not be able to exchange messages (except minor upgrades) between each other. As I understand it, I can run different HornetQ Versions by using different ports and data directories. This is already configurable on our java applications.

      In this way we can run different versions in parallel as long as it is needed and upgrade our enterprise system gradually.


      Any recommendations?


      Many thanks,