I am trying to figure out an effective way of configure the
subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"
ActiveMQ subsystem in the standalone.xml. I find the widlfly 10 documentation on this subsystem sufficient to get you started.
But clearly lacking when you want to further tune Active MQ behavior. (e.g. http://activemq.apache.org/how-do-i-configure-10s-of-1000s-of-queues-in-a-single-broker-.html)
For understanding what is posisble or not with ActiveMQ, I prefer to and I try to use the active MQ as the primary source of documentation.
My expectation, in the end, is that I should be able to find a way configure the active mq features explained on their documentation in the wildfly standalone.xml configuration, somehow. That Wildfly is acting as an interface to configure ActiveMQ, but that it does not act as a limitation to what I can configure.
This is the part I am struggling with.
Once I have read the ActiveMQ documentation and I have an idea about a feature I want to test out. I then go hunting on how to update my standalone.xml to configure the jms broker appropriately, I need to hunt for the XML elements and attributes that would allow me to do this.
So with this context in hand, here are the questions:
(a) Why is that the: docs\schema\jboss-as-messaging_1_0.xsd to jboss-as-messaging_3_0.xsd
Are inconsistent with the configuration that must actually get written in the standalone.xml. For example, if we look at the address-setting element. In the Wildfly 10 official documentation and locally on my machine, this element can be configured through atrributes as illustrated next.
<address-setting name="#" slow-consumer-threshold="20" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" max-delivery-attempts="-1" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
On the other hand, if we look at the XSD of subsytem, the address-setting type should be composed of elements not attributes.
<xs:complexType name="address-settingType">
<xs:all>
<xs:element maxOccurs="1" minOccurs="0" name="dead-letter-address" type="xs:string" />
<xs:element maxOccurs="1" minOccurs="0" name="expiry-address" type="xs:string" />
<xs:element maxOccurs="1" minOccurs="0" name="redelivery-delay" type="xs:long" />
<xs:element maxOccurs="1" minOccurs="0" name="max-delivery-attempts" type="xs:int" />
<xs:element maxOccurs="1" minOccurs="0" name="max-size-bytes" type="xs:long" />
<xs:element maxOccurs="1" minOccurs="0" name="page-size-bytes" type="xs:long" />
<xs:element maxOccurs="1" minOccurs="0" name="page-max-cache-size" type="xs:int" />
<xs:element maxOccurs="1" minOccurs="0" name="address-full-policy" type="addressFullMessagePolicyType" />
<xs:element maxOccurs="1" minOccurs="0" name="message-counter-history-day-limit" type="xs:int" />
<xs:element maxOccurs="1" minOccurs="0" name="last-value-queue" type="xs:boolean" />
<xs:element maxOccurs="1" minOccurs="0" name="redistribution-delay" type="xs:long" />
<xs:element maxOccurs="1" minOccurs="0" name="send-to-dla-on-no-route" type="xs:boolean" />
</xs:all>
<xs:attribute name="match" type="xs:string" use="required"/>
</xs:complexType>
This is a problem to me. Because if you cannot find a documentation page for every single attribute that you can configure, then I would expect to find an XSD that has this technical level of detail in there. Then I can idependently of how up to do date or detailed the documentation is, find my way to set the features I want to enable/disable or tune.
But if the XSDs I find are not consistent with the configuration I end up writing on the stanadalone.xml and which is working, I cannot really trust the XSD as a reliable source of information for features that I can configure. So, on the one hand, I am configuring attributes on an element. On the other hand, I have an XSD that tells me I should be using elements withing elements. Which is it?
(b) The next question is about the scope of configuration that is posisble to do. I want to know if our ability to configure ActiveMQ subsystem via standalone.xml is limited or if we have full capability of configuring the subsytem.
For example, If you look at the ActiveMQ page on per-destination policies. http://activemq.apache.org/per-destination-policies.html
There are features that can be configured such as: "optimizedDispatch" Which is recommended by ActiveMQ if you are going to configured hundreds of queues in an active MQ broker. Hunting the XSDs for optimizedDispatch policy, I find no mention of this configuration element in either the form of an element or attribute. Can I actually configure this behavior on the destinations or not?
I would like to know how far I can go with the tuning of ActiveMQ via wildfly subsystem configuration?
Where are the boundaries between what ActiveMQ supports and what the wildfly stand alone xml supported configuration allows me to Tune.
Can anyone bring some light to these two questions?
Kindest regards.
