You are correct, and that I think is the biggest part of the problem. With my current configuration. All unrouted counts is "0". So now I have to beat the JBoss vs thick Java app connection logic to death, Because JBoss is going thru a path that gets the prefix added, but the straight Jaba code does not. So I am working thru the code changes now to restore the prefix in all non JBoss code.
-----Original Message----- From: Justin Bertram <[email protected]> Sent: Wednesday, March 4, 2026 9:02 AM To: [email protected] Subject: Re: EXTERNAL: Re: help setting broker.xml Also, it's worth noting that if consumers are doing their job, then the message count for any queue should always be 0 or close to it. This just means that as soon as a message lands on the queue, the consumer receives and acknowledges it. Generally speaking, this is what you want. I previously mentioned the "messages added" and "messages acknowledged" columns because they show activity when the message count is flat, which can be helpful in this situation. Have you tried inspecting these? Justin On Wed, Mar 4, 2026 at 8:28 AM Justin Bertram <[email protected]> wrote: > > In the context of JMS topics, messages are typically unrouted when sent to a > topic without any subscriptions. Can you confirm that the topic has at least > one subscription when messages are sent? On the broker itself, a JMS topic is > represented as an address and the subscription will be a queue on that > address [1]. If an address has no queues when a message is sent to it the > message is simply dropped (i.e. it's not routed) which increases the > "unrouted" message count in the management API. Unrouted messages are not > necessarily a cause for concern. They are expected in many use cases. > > WildFly (and products based on WildFly) use the "jms.queue." and "jms.topic." > prefixes for historical reasons. You can configure standalone Artemis to > handle these prefixes transparently (i.e. using the "anycastPrefix" and > "multicastPrefix" acceptor URL parameters) which means the corresponding > addresses and queues won't need to use the prefixes in their names or you can > simply use the prefixes in the names. > > All you need in broker.xml for a JMS topic name "myTopic" is this: > > <address name="myTopic"> > <multicast/> > </address> > > When a JMS application subscribes to this topic a multicast subscription > queue is automatically created. Therefore, what you're seeing for your > "jms.topic.Clock" address is the expected behavior. According to your > screenshot there are 3 subscriptions on that topic. > > > Justin > > [1] > https://artemis.apache.org/components/artemis/documentation/latest/jms > -core-mapping.html#mapping-jms-concepts-to-the-core-api > > On Wed, Mar 4, 2026 at 7:38 AM [email protected] > <[email protected]> wrote: >> >> 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,br >> oker=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/ma >> nagement.html#message-counters >> >> [2] >> https://artemis.apache.org/components/artemis/documentation/latest/me >> trics.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-dir >> > > ect >> >> > > 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-pe >> > > rio >> >> > > 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;tcpR >> > > ece >> >> > > iv >> >> > > eBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE >> > > ,AM >> >> > > QP >> >> > > ,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpL >> > > owC >> >> > > re >> >> > > dits=300;amqpDuplicateDetection=true;supportAdvisory=false;suppre >> > > ssI >> >> > > 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;tcpRecei >> > > veB >> >> > > uf >> >> > > ferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amq >> > > pLo >> >> > > wC >> >> > > redits=300;amqpMinLargeMessageSize=102400;amqpDuplicateDetection= >> > > tru >> >> > > e< >> >> > > /acceptor> >> >> > > >> >> > > <!-- STOMP Acceptor. --> >> >> > > <acceptor >> >> > > name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpRec >> > > eiv >> >> > > 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.;multic >> > > ast >> >> > > Pr >> > > efix=jms.topic.;protocols=HORNETQ,STOMP;useEpoll=true</acceptor> >> >> > > >> >> > > <!-- MQTT Acceptor --> >> >> > > <acceptor >> >> > > name="mqtt">tcp://0.0.0.0:1883?tcpSendBufferSize=1048576;tcpRecei >> > > veB >> >> > > 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-da >> > > y-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-da >> > > y-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-consumer >> > > s> >> >> > > </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]
