For a JMS use case, I think you're going to get unwanted behavior with
a configuration like this:
<address name="jms.topic.AtmosphericParameters">
<multicast>
<queue name="AtmosphericParameters"/>
</multicast>
</address>
With this configuration every message sent to "AtmosphericParameters"
by a JMS application will be routed to the "AtmosphericParameters"
queue. However, normal JMS subscribers won't consume the messages in
this queue because each subscriber will have its own individual
subscription queue (as you've seen with jms.topic.Clock). Therefore,
messages will accumulate in the "AtmosphericParameters" queue
(consuming heap memory) and will eventually page to storage (consuming
disk space). Without remediation the disk will eventually fill up and
the broker will stop.
A comparable situation was recently reported on this list where an
unattended queue filled with over 20 million messages over 18 months
resulting in a similar outcome.
Justin
On Wed, Mar 4, 2026 at 8:22 AM [email protected]
<[email protected]> wrote:
>
> Possible SUCCESS!
>
> I changed the broker to use this pattern:
>
>
>
> <address name="jms.topic.AtmosphericParameters">
>
> <multicast>
>
> <queue name="AtmosphericParameters"/>
>
> </multicast>
>
> </address>
>
>
>
> All JBoss items still deploy, I see no unrouted counts, and live counts are
> occurring in the console.
>
>
>
> From: Turner, George (US)
> Sent: Wednesday, March 4, 2026 7:38 AM
> To: '[email protected]' <[email protected]>
> Subject: RE: EXTERNAL: Re: help setting broker.xml
>
>
>
> So I need some help figuring out the prefix mapping.
>
> I am not having any success disabling the jms.topic. prefix from JBoss.
>
> I have removed it in the broker.xml acceptors.
>
> I have restored in on the broker.xml addresses.
>
> All my code in JBoss deploys, but the broker logging is still showing things
> are “unrouted”.
>
>
>
> I need to understand and resolve the routing issues in the broker.
>
>
>
> From: Turner, George (US)
> Sent: Tuesday, March 3, 2026 11:47 PM
> To: '[email protected]' <[email protected]>
> Subject: RE: EXTERNAL: Re: help setting broker.xml
>
>
>
> Well that was fun.
>
> I re-discovered the reason I added the prefix was because JBoss wanted them.
>
> But I found a pooled-connection-factory attribute to disable usage.
>
> Crossing my fingers.
>
>
>
> From: Turner, George (US)
> Sent: Tuesday, March 3, 2026 11:11 PM
> To: [email protected]
> Subject: RE: EXTERNAL: Re: help setting broker.xml
>
>
>
> It looks like this is my issue (from the metrics logging)
>
> artemis.unrouted.message.count{address=jms.topic.SFConsoleExecutor,broker=0.0.0.0}
> value=58
>
>
>
> Please help me correct this issue if you can. This should be something
> purely defined by the broker.xml
>
>
>
> I need static defined queues (I do not want clients to create queues or
> topics).
>
> When a publisher calls “createTopic”, they should be creating a routing to a
> common queue that should multicast from the queue to any subscribers of the
> topic.
>
>
>
> My understand is that this should be the only xml I need to create a named
> queue of AtmosphericParameters with a mapped topic (address) of
>
>
>
> <address name="jms.topic.AtmosphericParameters">
>
> <multicast/>
>
> </address>
>
>
>
> Possibly I have misread the docs. Please advise.
>
> In the console, I see a queue name that is always a UUID string.
>
> Topic addresses have one or more multicast queues which seems “backwards”
>
>
>
>
>
>
>
>
>
> From: Justin Bertram <[email protected]>
> Sent: Tuesday, March 3, 2026 10:05 PM
> To: [email protected]
> Subject: Re: EXTERNAL: Re: help setting broker.xml
>
>
>
> If they never show anything other than "0," the chances are good that you're
> looking at the wrong queue(s).
>
>
>
> That said, I think understanding your full use case would be worthwhile. What
> kind of clients are you using? Are you sending and consuming messages or only
> sending them? What names are you using for the queues/topics in your
> applications?
>
>
>
> It's a bit odd to see addresses with the "jms.topic." prefix. We stopped
> using that almost 10 years ago now. Are you using older clients that need
> this?
>
>
>
> Lastly, you don't need to add the metrics plugin to see message counts in the
> web console. The metrics plugin is intended only for integration with
> external monitoring systems. Even so, both the web console and the exported
> metrics pull from the same internal data structures so if you're seeing
> non-zero message counts in the metrics you should almost certainly see those
> reflected in the web console as well.
>
>
>
>
>
> Justin
>
>
>
> On Tue, Mar 3, 2026 at 9:37 PM [email protected]
> <[email protected]> wrote:
>
> They never have anything other than “0”. I have added the metrics plugin to
> the broker and the logging now shows message counts, but all “0” in the
> console.
>
>
>
> On another note, would you look at the bottom of the broker xml and verify
> the pattern that I am using.
>
>
>
> The intent is to statically define a queue with “XXXX” for the name.
>
> Then define a multicast java topic of jms.topic.XXXX.
>
>
>
> I am not 100% positive that the static queues are mapping to the “java”
> topics correctly.
>
>
>
> From: Justin Bertram <[email protected]>
> Sent: Tuesday, March 3, 2026 9:28 PM
> To: [email protected]
> Subject: Re: EXTERNAL: Re: help setting broker.xml
>
>
>
> Can you elaborate on why they are unusable for you?
>
>
>
>
>
> Justin
>
>
>
> On Tue, Mar 3, 2026 at 9:18 PM [email protected]
> <[email protected]> wrote:
>
> The two columns in the far right of this picture.
>
>
>
> From: Justin Bertram <[email protected]>
> Sent: Tuesday, March 3, 2026 9:08 PM
> To: [email protected]
> Subject: Re: EXTERNAL: Re: help setting broker.xml
>
>
>
> Which columns are unusable?
>
>
>
>
>
> Justin
>
>
>
> On Tue, Mar 3, 2026 at 9:05 PM [email protected]
> <[email protected]> wrote:
>
> It seems a big shame that the console has these columns and they are
> basically unusable.
>
>
>
>
>
> -----Original Message-----
> From: Justin Bertram <[email protected]>
> Sent: Tuesday, March 3, 2026 1:43 PM
> To: [email protected]
> Subject: Re: EXTERNAL: Re: help setting broker.xml
>
>
>
> The discrepancy you see may result from the queue's actual operation and how
> the metrics are reported. It's worth noting that the message count reported
> via the management API will not necessarily match what you see in a message
> "browser."
>
>
>
> The message count for a queue tracks messages in several different states:
>
>
>
> - in-memory pending delivery
>
> - scheduled, not yet available for delivery
>
> - paged to disk pending delivery
>
> - in delivery (i.e. dispatched to a consumer, but not yet acknowledged)
>
>
>
> However, a message "browser" will only show messages pending delivery whether
> they are in memory or paged to disk. It will not show messages which are
> scheduled or in delivery because those messages are technically unavailable
> for consumption by a corresponding consumer.
>
>
>
> Lastly, I noticed you enabled message counters in your broker.xml using
> <message-counter-enabled>true</message-counter-enabled>. I wanted to clarify
> that setting this parameter isn't necessary to track message counts via the
> web console. "Message counters" [1] is a legacy feature for tracking count
> data over time. These days if you want history for such metrics we recommend
> using the metrics subsystem [2] to configure a plugin that will export
> metrics to an external system purpose-built for tracking metrics over time.
> For example, folks can use this plugin [3] to expose metrics that Prometheus
> (or any other service supporting the Prometheus format) can consume. These
> tools offer monitoring, graphing, and alerting mechanisms for advanced
> use-cases.
>
>
>
>
>
> Justin
>
>
>
> [1]
> https://artemis.apache.org/components/artemis/documentation/latest/management.html#message-counters
>
> [2]
> https://artemis.apache.org/components/artemis/documentation/latest/metrics.html#metrics
>
> [3] https://github.com/rh-messaging/artemis-prometheus-metrics-plugin
>
>
>
>
>
> On Tue, Mar 3, 2026 at 11:25 AM [email protected]
> <[email protected]> wrote:
>
> >
>
> > With the latest settings, I have seen the count increase on a specific
> > queue of a subscriber, but If I refresh the browser page, all values for
> > that queue return to 0.
>
> > Values should stay consistent until the "next day" when the counter starts
> > again.
>
> >
>
> > -----Original Message-----
>
> > From: Justin Bertram <[email protected]>
>
> > Sent: Tuesday, March 3, 2026 5:11 PM
>
> > To: [email protected]
>
> > Subject: Re: EXTERNAL: Re: help setting broker.xml
>
> >
>
> > > The biggest issue I am having right now is trying to get the console
> > > (running with admin user account) to consistently show message counts.
>
> >
>
> > Can you elaborate on the exact problems you're having with the web console
> > consistently showing message counts? It's not clear to me that any settings
> > in broker.xml will be relevant at this point.
>
> >
>
> >
>
> > Justin
>
> >
>
> > On Tue, Mar 3, 2026 at 9:25 AM [email protected]
> > <[email protected]> wrote:
>
> > >
>
> > > I am behind a corporate firewall and their initial deployment of Slack
> > > bombed and they don't allow it anymore, but thank you anyway.
>
> > >
>
> > > The biggest issue I am having right now is trying to get the console
> > > (running with admin user account) to consistently show message counts.
>
> > >
>
> > >
>
> > > Below is the "top" of the file. Anything below what I am pasting here is
> > > not "useful".
>
> > > Thanks
>
> > >
>
> > > <configuration xmlns="urn:activemq"
>
> > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> > > xmlns:xi="http://www.w3.org/2001/XInclude";
>
> > > xsi:schemaLocation="urn:activemq
>
> > > /schema/artemis-configuration.xsd">
>
> > >
>
> > > <core xmlns="urn:activemq:core"
> > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> > > xsi:schemaLocation="urn:activemq:core ">
>
> > >
>
> > > <name>0.0.0.0</name>
>
> > >
>
> > > <message-counter-enabled>true</message-counter-enabled>
>
> > >
>
> > >
>
> > > <persistence-enabled>true</persistence-enabled>
>
> > >
>
> > > <!-- this could be ASYNCIO, MAPPED, NIO
>
> > > ASYNCIO: Linux Libaio
>
> > > MAPPED: mmap files
>
> > > NIO: Plain Java Files
>
> > > -->
>
> > > <journal-type>ASYNCIO</journal-type>
>
> > >
>
> > > <paging-directory>data/paging</paging-directory>
>
> > >
>
> > > <bindings-directory>data/bindings</bindings-directory>
>
> > >
>
> > > <journal-directory>data/journal</journal-directory>
>
> > >
>
> > >
>
> > > <large-messages-directory>data/large-messages</large-messages-direct
>
> > > or
>
> > > y>
>
> > >
>
> > >
>
> > > <!-- if you want to retain your journal uncomment this following
> > > configuration.
>
> > >
>
> > > This will allow your system to keep 7 days of your data, up to 10G.
> > > Tweak it accordingly to your use case and capacity.
>
> > >
>
> > > it is recommended to use a separate storage unit from the journal
> > > for performance considerations.
>
> > >
>
> > > <journal-retention-directory period="7" unit="DAYS"
>
> > > storage-limit="10G">data/retention</journal-retention-directory>
>
> > >
>
> > > You can also enable retention by using the argument
>
> > > journal-retention on the `artemis create` command -->
>
> > >
>
> > >
>
> > >
>
> > > <journal-datasync>true</journal-datasync>
>
> > >
>
> > > <journal-min-files>2</journal-min-files>
>
> > >
>
> > > <journal-pool-files>10</journal-pool-files>
>
> > >
>
> > > <journal-device-block-size>4096</journal-device-block-size>
>
> > >
>
> > > <journal-file-size>10M</journal-file-size>
>
> > >
>
> > > <!--
>
> > > This value was determined through a calculation.
>
> > > Your system could perform 250 writes per millisecond
>
> > > on the current journal configuration.
>
> > > That translates as a sync write every 4000 nanoseconds.
>
> > >
>
> > > Note: If you specify 0 the system will perform writes directly to
> > > the disk.
>
> > > We recommend this to be 0 if you are using
> > > journalType=MAPPED and journal-datasync=false.
>
> > > -->
>
> > > <journal-buffer-timeout>4000</journal-buffer-timeout>
>
> > >
>
> > >
>
> > > <!--
>
> > > When using ASYNCIO, this will determine the writing queue depth
> > > for libaio.
>
> > > -->
>
> > > <journal-max-io>4096</journal-max-io>
>
> > > <!--
>
> > > You can verify the network health of a particular NIC by
> > > specifying the <network-check-NIC> element.
>
> > > <network-check-NIC>theNicName</network-check-NIC>
>
> > > -->
>
> > >
>
> > > <!--
>
> > > Use this to use an HTTP server to validate the network
>
> > >
>
> > > <network-check-URL-list>http://www.apache.org</network-check-URL-lis
>
> > > t>
>
> > > -->
>
> > >
>
> > > <!-- <network-check-period>10000</network-check-period> -->
>
> > > <!-- <network-check-timeout>1000</network-check-timeout> -->
>
> > >
>
> > > <!-- this is a comma separated list, no spaces, just DNS or IPs
>
> > > it should accept IPV6
>
> > >
>
> > > Warning: Make sure you understand your network topology as
> > > this is meant to validate if your network is valid.
>
> > > Using IPs that could eventually disappear or be
> > > partially visible may defeat the purpose.
>
> > > You can use a list of multiple IPs, and if any
> > > successful ping will make the server OK to continue running -->
>
> > > <!-- <network-check-list>10.0.0.1</network-check-list> -->
>
> > >
>
> > > <!-- use this to customize the ping used for ipv4 addresses -->
>
> > > <!-- <network-check-ping-command>ping -c 1 -t %d
>
> > > %s</network-check-ping-command> -->
>
> > >
>
> > > <!-- use this to customize the ping used for ipv6 addresses -->
>
> > > <!-- <network-check-ping6-command>ping6 -c 1
>
> > > %2$s</network-check-ping6-command> -->
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > <!-- how often we are looking for how many bytes are being used on
> > > the disk in ms -->
>
> > > <disk-scan-period>5000</disk-scan-period>
>
> > >
>
> > > <!-- once the disk hits this limit the system will block, or close
> > > the connection in certain protocols
>
> > > that won't support flow control. -->
>
> > > <max-disk-usage>90</max-disk-usage>
>
> > >
>
> > > <!-- should the broker detect dead locks and other issues -->
>
> > > <critical-analyzer>true</critical-analyzer>
>
> > >
>
> > > <critical-analyzer-timeout>120000</critical-analyzer-timeout>
>
> > >
>
> > >
>
> > > <critical-analyzer-check-period>60000</critical-analyzer-check-perio
>
> > > d>
>
> > >
>
> > > <critical-analyzer-policy>HALT</critical-analyzer-policy>
>
> > >
>
> > >
>
> > > <page-sync-timeout>36000</page-sync-timeout>
>
> > >
>
> > >
>
> > > <!-- the system will enter into page mode once you hit this
> > > limit.
>
> > > This is an estimate in bytes of how much the messages are
>
> > > using in memory
>
> > >
>
> > > The system will use half of the available memory (-Xmx) by
> > > default for the global-max-size.
>
> > > You may specify a different value here if you need to
> > > customize it to your needs.
>
> > >
>
> > > <global-max-size>100Mb</global-max-size>
>
> > >
>
> > > -->
>
> > >
>
> > > <acceptors>
>
> > >
>
> > > <!-- useEpoll means: it will use Netty epoll if you are on a
> > > system (Linux) that supports it -->
>
> > > <!-- amqpCredits: The number of credits sent to AMQP producers
> > > -->
>
> > > <!-- amqpLowCredits: The server will send the # credits
> > > specified at amqpCredits at this low mark -->
>
> > > <!-- amqpDuplicateDetection: If you are not using duplicate
> > > detection, set this to false
>
> > > as duplicate detection requires
> > > applicationProperties to be parsed on the server. -->
>
> > > <!-- amqpMinLargeMessageSize: Determines how many bytes are
> > > considered large, so we start using files to hold their data.
>
> > > default: 102400, -1 would
>
> > > mean to disable large mesasge control -->
>
> > >
>
> > > <!-- Note: If an acceptor needs to be compatible with HornetQ
> > > and/or Artemis 1.x clients add
>
> > > "anycastPrefix=jms.queue.;multicastPrefix=jms.topic."
> > > to the acceptor url.
>
> > > See
>
> > > https://issues.apache.org/jira/browse/ARTEMIS-1644 for more
>
> > > information. -->
>
> > >
>
> > >
>
> > > <!-- Acceptor for every supported protocol -->
>
> > > <acceptor
>
> > > name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpRece
>
> > > iv
>
> > > eBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AM
>
> > > QP
>
> > > ,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowC
>
> > > re
>
> > > dits=300;amqpDuplicateDetection=true;supportAdvisory=false;suppressI
>
> > > nt ernalManagementObjects=false</acceptor>
>
> > >
>
> > > <!-- AMQP Acceptor. Listens on default AMQP port for AMQP
> > > traffic.-->
>
> > > <acceptor
>
> > > name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveB
>
> > > uf
>
> > > ferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLo
>
> > > wC
>
> > > redits=300;amqpMinLargeMessageSize=102400;amqpDuplicateDetection=tru
>
> > > e<
>
> > > /acceptor>
>
> > >
>
> > > <!-- STOMP Acceptor. -->
>
> > > <acceptor
>
> > > name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiv
>
> > > eB ufferSize=1048576;protocols=STOMP;useEpoll=true</acceptor>
>
> > >
>
> > > <!-- HornetQ Compatibility Acceptor. Enables HornetQ Core and
> > > STOMP for legacy HornetQ clients. -->
>
> > > <acceptor
>
> > > name="hornetq">tcp://0.0.0.0:5445?anycastPrefix=jms.queue.;multicast
>
> > > Pr efix=jms.topic.;protocols=HORNETQ,STOMP;useEpoll=true</acceptor>
>
> > >
>
> > > <!-- MQTT Acceptor -->
>
> > > <acceptor
>
> > > name="mqtt">tcp://0.0.0.0:1883?tcpSendBufferSize=1048576;tcpReceiveB
>
> > > uf ferSize=1048576;protocols=MQTT;useEpoll=true</acceptor>
>
> > >
>
> > > </acceptors>
>
> > >
>
> > >
>
> > > <security-settings>
>
> > > <security-setting match="#">
>
> > > <permission type="createNonDurableQueue" roles="amq,sfuser"/>
>
> > > <permission type="deleteNonDurableQueue" roles="amq"/>
>
> > > <permission type="createDurableQueue" roles="amq"/>
>
> > > <permission type="deleteDurableQueue" roles="amq"/>
>
> > > <permission type="createAddress" roles="amq"/>
>
> > > <permission type="deleteAddress" roles="amq"/>
>
> > > <permission type="consume" roles="amq,sfuser"/>
>
> > > <permission type="browse" roles="amq"/>
>
> > > <permission type="count" roles="amq"/>
>
> > > <permission type="send" roles="amq,sfuser"/>
>
> > > <!-- we need this otherwise ./artemis data imp wouldn't work
> > > -->
>
> > > <permission type="manage" roles="amq"/>
>
> > > </security-setting>
>
> > > </security-settings>
>
> > >
>
> > > <address-settings>
>
> > > <!-- if you define auto-create on certain queues, management has
> > > to be auto-create -->
>
> > > <address-setting match="activemq.management#">
>
> > > <dead-letter-address>DLQ</dead-letter-address>
>
> > > <expiry-address>ExpiryQueue</expiry-address>
>
> > > <redelivery-delay>0</redelivery-delay>
>
> > > <!-- with -1 only the global-max-size is in use for limiting
> > > -->
>
> > > <max-size-bytes>-1</max-size-bytes>
>
> > >
> > > <message-counter-history-day-limit>10</message-counter-history-day-limit>
>
> > > <address-full-policy>PAGE</address-full-policy>
>
> > > <auto-create-queues>true</auto-create-queues>
>
> > > <auto-create-addresses>true</auto-create-addresses>
>
> > > <auto-create-jms-queues>true</auto-create-jms-queues>
>
> > > <auto-create-jms-topics>true</auto-create-jms-topics>
>
> > > </address-setting>
>
> > > <!--default for catch all-->
>
> > > <address-setting match="#">
>
> > > <dead-letter-address>DLQ</dead-letter-address>
>
> > > <expiry-address>ExpiryQueue</expiry-address>
>
> > > <redelivery-delay>0</redelivery-delay>
>
> > > <!-- with -1 only the global-max-size is in use for limiting
> > > -->
>
> > > <max-size-bytes>-1</max-size-bytes>
>
> > >
> > > <message-counter-history-day-limit>10</message-counter-history-day-limit>
>
> > > <address-full-policy>PAGE</address-full-policy>
>
> > > <auto-create-queues>true</auto-create-queues>
>
> > > <auto-create-addresses>false</auto-create-addresses>
>
> > > <auto-create-jms-queues>false</auto-create-jms-queues>
>
> > > <auto-create-jms-topics>true</auto-create-jms-topics>
>
> > > <auto-delete-queues>true</auto-delete-queues>
>
> > > <auto-delete-addresses>false</auto-delete-addresses>
>
> > >
> > > <default-purge-on-no-consumers>true</default-purge-on-no-consumers>
>
> > > </address-setting>
>
> > > </address-settings>
>
> > >
>
> > > <addresses>
>
> > > <address name="DLQ">
>
> > > <anycast>
>
> > > <queue name="DLQ" />
>
> > > </anycast>
>
> > > </address>
>
> > > <address name="ExpiryQueue">
>
> > > <anycast>
>
> > > <queue name="ExpiryQueue" />
>
> > > </anycast>
>
> > > </address>
>
> > >
>
> > > <address name="jms.topic.AtmosphericParameters">
>
> > > <multicast/>
>
> > > </address>
>
> > > <address name="jms.topic.C2SimWS">
>
> > > <multicast/>
>
> > > </address>
>
> > > <address name="jms.topic.C2SimNotify">
>
> > > <multicast/>
>
> > > </address>
>
> > >
>
> > >
>
> > > -----Original Message-----
>
> > > From: Justin Bertram <[email protected]>
>
> > > Sent: Tuesday, March 3, 2026 8:46 AM
>
> > > To: [email protected]
>
> > > Subject: EXTERNAL: Re: help setting broker.xml
>
> > >
>
> > > This mailing list is the proper place to get help. Can you elaborate on
> > > exactly what you need help with?
>
> > >
>
> > > Also, keep in mind that our Slack channel [1] might provide a better
> > > experience. Would you like me to send you an invitation?
>
> > >
>
> > >
>
> > > Justin
>
> > >
>
> > > [1] https://artemis.apache.org/contact#chat
>
> > >
>
> > > On Tue, Mar 3, 2026 at 8:30 AM [email protected]
> > > <[email protected]> wrote:
>
> > > >
>
> > > > I am using Artemis 2.19.1
>
> > > >
>
> > > > I would like some assistance getting the broker xml correctly
> > > > configured.
>
> > > >
>
> > > > I have a great deal working already, but am having issues getting it
> > > > “perfect”.
>
> > > >
>
> > > >
>
> > > >
>
> > > > I do not see a web online portal to ask questions.
>
> > > >
>
> > > > Please help me get the correct support contacts.
>
> > > >
>
> > > >
>
> > > >
>
> > > > George (Gene) Turner
>
> > > >
>
> > > > Space Fence MSS Software Lead
>
> > > >
>
> > > > Lockheed Martin Rotary and Mission Systems (RMS)
>
> > > >
>
> > > > Telecommute:Greenville, TX
>
> > > >
>
> > > > [email protected]
>
> > > >
>
> > > > NIPR: [email protected]
>
> > > >
>
> > > > SIPR: [email protected]
>
> > > >
>
> > > > Office 719-277-4978
>
> > > >
>
> > > > Mobile(Personal) 719-237-0490
>
> > > >
>
> > > >
>
> > >
>
> > > --------------------------------------------------------------------
>
> > > - To unsubscribe, e-mail: [email protected]
>
> > > For additional commands, e-mail: [email protected]
>
> > >
>
> > >
>
> > > --------------------------------------------------------------------
>
> > > - To unsubscribe, e-mail: [email protected]
>
> > > For additional commands, e-mail: [email protected]
>
> > >
>
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: [email protected]
>
> > For additional commands, e-mail: [email protected]
>
> >
>
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: [email protected]
>
> > For additional commands, e-mail: [email protected]
>
> >
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: [email protected]
>
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
