Management of HornetQ core queues
While working on AS7-1960[1] Kabir noticed that HornetQ core queues created with the HornetQ API (eg ClientSession.createQueue) were not exposed correctly as AS7 resources. The resource does not exist (:read-resource & :write-attribute fails) but it is still possible to interact with it (eg invoke :read-attribute or other queue-specific operations such as :pause or :resume)[2].
The problem is more general for HornetQ. When HornetQ creates JMS resources, it also creates underlying core queues for them (1 core queue per JMS queue and 1 + n core queues for 1 JMS topic with n subscribers).
These core queues are not exposed by AS7 either[3].
My first idea was to materialize these resources correctly but this brings more problems. Their resource definitions flagged them as stored in the configuration. I don't think that queues created outside of the AS7 management API should be stored in its configuration.
At the same time, for backwards compatibility, we must continue to support the management operations on these core queues at their current addresses (/subsystem=messaging/hornetq-server=XXX/queue=YYY)
After talking to Kabir on IRC, the idea would be to:
- expose all HornetQ core queues as runtime read-only resources in a separate address (eg /subsystem=messaging/hornetq-server=XXX/runtime-queue=YYY). These resources would be handled dynamically based on HornetQServer management service (like it's done for core-address resources)
- for backwards compatibility, forward the "read-only" and runtime management operations (read-attribute, queue-specific operations) from /subsystem=messaging/hornetq-server=XXX/queue=YYY to /subsystem=messaging/hornetq-server=XXX/runtime-queue=YYY
- Queues created by AS7 management API will remain at their current address and support read/write attributes and be persisted in AS7 configuration
[1] https://issues.jboss.org/browse/AS7-1960