Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-171

AS7 messaging resources throws NPE when hornetq-server is a backup

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Done
    • None
    • 8.0.0.Alpha1
    • JMS
    • None

    Description

      steps to reproduce:
      Configure AS7's hornetq-server to be a backup ready for failover.

      Run AS7 standalone-full configuration with hornetq-server configured to be a backup:

      <hornetq-server>
         <backup>true</backup>
         ...
      

      The AS7 will start, its hornetq-server too but it will not be active:

      18:24:56,527 INFO  [org.hornetq.core.server] (HQ119001: Activation for server HornetQServerImpl::serverUUID=349065dd-87f2-11e2-911d-f19bf97ea7a7) HQ002211: HornetQ Backup Server version 2.3.0.CR1 (buzzzzz!, 122) [349065dd-87f2-11e2-911d-f19bf97ea7a7] started, waiting live to fail before it gets active
      

      The hornetq server will not become active until a live node fails. When this occurs, the server will become active, accept connection, create core and JMS resources etc.

      The issue is that any runtime operation on a hornetq-server's children will fail.
      The runtime operations rely on HornetQ's management resource (eg TopicControl, QueueControl) and these objects are not available until HornetQ server is active.

      For AS7 integration that means that we must somehow prevent any runtime changes to any hornetq-server's children resources for a passive server. There are no corresponding runtime resources in HornetQ for them.

      Additionnaly, hornetq-server does not expose the "active" runtime attribute to know whether the server is active.

      Attachments

        Activity

          People

            jmesnil1@redhat.com Jeff Mesnil
            jmesnil1@redhat.com Jeff Mesnil
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: