4 Replies Latest reply on May 7, 2013 8:53 AM by alfred.holzinger.idv

    Application design/architecture to support HornetQ upgrades

    alfred.holzinger.idv
    alfred.holzinger.idv May 7, 2013 3:49 AM

      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.

       

      Questions:

      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,

      Alfred

        • 1. Re: Application design/architecture to support HornetQ upgrades
          ataylor
          ataylor May 7, 2013 4:15 AM (in response to alfred.holzinger.idv)

          It depends on how (and if) the Hornet servers are talking to each other, if you are using coe bridges then you will have to upgrade all the servers at the same time, we only supoort backward compatibilty from a clients perspective.

            • Actions
          • 2. Re: Application design/architecture to support HornetQ upgrades
            alfred.holzinger.idv
            alfred.holzinger.idv May 7, 2013 8:25 AM (in response to ataylor)

            We use core queues, diverts and core bridges to build up the integration between different HornetQ servers. Each hornetQ server sends and receives messages.

             

            I'm aware that servers that are talking to each other need to be on the same version. Some minor upgrades might work for the hornetQ client side.

            My question is more on a strategic level. Our applications will have as endpoint (beyond the messaging) either a legacy system or a database.

             

            My current approach would be:

            Step 1. Application A in version 1.0 embedding HornetQ 2.3.0.Final - it can only talk to this version on all the different instances.

            Step 2. Install application A v2.0 embedding HornetQ 2.4.x.Final on the same physical machine(s). Port and data directory will be configured differently. Both servers are running in parallel.

            Step 3. Uninstall application v1.0 once all messages are processed and no new once are to be expected.

             

            Step 2 and 3 would be repeated for all machines in the whole enterprise system which might be within days or even weeks.

            The whole enterprise system with 100+ servers will be migrated gradually from A1.0 to A2.0.

             

            Is this all to think of or am I missing something?

              • Actions
            • 3. Re: Application design/architecture to support HornetQ upgrades
              ataylor
              ataylor May 7, 2013 8:39 AM (in response to alfred.holzinger.idv)

              as long as different hornetq servers dont talk to each other i don't see any problems

                • Actions
              • 4. Re: Application design/architecture to support HornetQ upgrades
                alfred.holzinger.idv
                alfred.holzinger.idv May 7, 2013 8:53 AM (in response to ataylor)

                Thanks Andy! This is good and helpful answer.

                  • Actions