Updated: August 5, 2022 10:45am

PrismMQService

1.14.7 PrismMQService PDF

2.0 PrismMQService PDF

This topic has information about the PrismMQService. The PrismMQService and its associated programs manage the replication of Prism data between sender and receiver.
This topic has two main sections

  • Background information about the PrismMQService
  • Configuration settings for the PrismMQservice.ini file

Consult with a certified Retail Pro technician about your specific data replication needs before making any changes to the PrismMQService.ini file.

About the PrismMQService
The settings in the PrismMQService.ini include settings that enable technicians to:

  • Control the outflow of messages from the Producer system during 1) Initialization and separately 2) Day-to-Day replication
  • Control the inflow of messages into the Consumer system
  • Troubleshooting settings
  • Restart/recover when something goes wrong
  • Set timers (e.g., SAVESTATUSINTERVAL, HEARTBEAT_INTERVAL)

There are three modules involved in replication: PrismMQ.exe, PrismMQProducer.exe and PrismMQConsumer.exe.

Data flow from sender to receiver using RabbitMQ

The following table explains the role of each module:
PrismMQService modules

Module Description
PrismMQ.exe PrismMQ.exe runs as a service. In the background, PrismMQ.exe launches the PrimsMQProducer.exe and PrimsMQConsumer.exe processes. When you stop PrimsMQ.exe or kill it in Task Manager, PrimsMQProducer.exe and PrimsMQConsumer.exe are also killed automatically.
Path: Program Files (x86)\RetailPro\Server\Replication
PrismMQProducer.exe This module monitors the PRODUCER_CACHE table and sends any messages it finds there to the appropriate subscriber, placing the message on the corresponding RabbitMQ queue of that subscriber.
Path: Program Files (x86)\RetailPro\Server\Replication
PrismMQConsumer.exe The consumer monitors the corresponding RabbitMQ queue and picks up message that belong to it and places them on the consumer_cache table
Path: Program Files (x86)\RetailPro\Server\Replication

About Message Caching
Prism caches messages before sending and receiving. This enables replication to proceed more smoothly and helps prevent bottlenecks.
Sending side
PrismMQService produces the message and adds it to the PRODUCER_CACHE tables (producer_cache & producer_cache_destination). Producer_cache stores the message and the producer_cache_destination stores relational link to each subscriber (destination).  PrismMQProducer.exe monitors the PRODUCER_CACHE tables, sends records it finds to the appropriate subscribers, placing the message on each of the related RabbitMQ queues that it is destined/subscribed too. Producer deletes the entry from the PRODUCER_CACHE_DESTINATION table once published that message on RabbitMQ queue for that specific destination and the message is delivered to each of the subscribers it will delete the message contents from the PRODUCER_CACHE.
Receiving side
PrismMQConsumer.exe monitors RabbitMQ and saves all received messages to  the CONSUMER_CACHE table. PrismMQ.exe monitors the CONSUMER_CACHE table. If PrismMQ.exe finds any messages, it saves those records to the Prism database and deletes them from the CONSUMER_CACHE table. A single queue, Prism.Day2Day, is used for both initialization and day-to-day replication. The INIT column in the PRODUCER_CACHE/CONSUMER_CACHE tables will indicate if the replication was initialization (1) or Day2Day (0).
PrismMQProducer workflow
The PrismMQProducer creates multiple threads for online and offline messages. The number of online threads is controlled by the D2DTHREADSPERSENDERCNT setting (default=5). The number of offline threads is controlled by the OFFLINE_THREADS_CNT setting (default=3).
The PrismMQProducer checks for any "clogged" queues. A queue is deemed clogged if the number of messages exceeds the QUEUEMESSAGELIMIIT (default=1000). The PrismMQProducer also checks if the queues have any records that also exist in the PRODUCER_CACHE_DESTINATION and PRODUCER_CACHE_OFFLINE tables. The PrismMQProducer will do this check every 60 seconds by default (controlled by the QUEUECHECKINTERVAL setting).
For each existing queue ("online" and "offline" records), a separate thread is created. This separate thread processes the number of records specified by the PRODUCERBATCHSIZE setting (default 1000). Thus, each thread serves its own queue.
REPLICATION_LOCKED_QUEUE table STATUS setting
The STATUS setting of the REPLICATION_LOCKED_QUEUE table indicates what is done with a message from the PrismMQProducer.

Status Description
NORMAL (status 0) PrismMQProducer sends the message same as before.
LOCKED (status 1) PrismMQProducer moves the record to the PRODUCER_CACHE_OFFLINE table and removes the payload. PrismMQProducer checks if the record already exists (same queue name, resource name, resource sid and init flag). If the record already exists, PrismMQProducer does not add the record. Instead, the record is removed from the online table. This is how "offline" duplicates are eliminated.
Offline threads work on the PRODUCER_CACHE_OFFLINE table. A separate thread is created for each queue (up to OFFLINE_THREADS_CNT).
If a queue's STATUS is set to "LOCKED," the PrismMQProducer does not create a thread for the queue.
RESUMING (status 2) If a queue's STATUS goes back to "UNLOCKED" and there are offline records, the queue is marked as "RESUMING" (status 2) and the offline thread starts to send messages from the Offline table.
RESUMED (status 3) Once the offline thread has sent all offline messages, the queue is marked "RESUMED" (status 3).
CLEAR (status 4) When the online thread sees a queue marked "RESUMED" (status 3) it does one "cycle." It moves messages to the offline table and then marks the queue "CLEARED" (status 4), stops moving records to the offline table and skips one cycle. Skipping a cycle serves as an acknowledgement to sync the offline and online threads for a given queue. The online queue then skips one iteration. This allows the offline thread to send any remaining offline messages. Starting with the next iteration, the queue is marked "NORMAL" (status 0) and the online thread starts sending messages normally.

Monitoring Total Messages in Queue
PrismMQProducer.exe also monitors the total messages in the queue. If the queue has more than 1,000 messages, it is deemed "clogged" and PrismMQProducer will stop sending messages to the queue. When PrimsMQProducer stops sending messages to a queue, it marks the corresponding records in the PRODUCER_CACHE table and adds the names of the paused queues to the REPLICATION_LOCKED_QUEUE table.
Single Queue for Initialization and Day-to-Day
There is only a single queue: Prism.Day2Day. This queue is used for both initialization and day-to-day replication. The INIT column in the PRODUCER_CACHE/CONSUMER_CACHE tables will indicate if the replication was initialization (1) or Day2Day (0).

Best Practices
Performance Improvement and Mnesia database size reduction
Disable sending data to systems if they will be offline for more than a few days.
System Stability
One should avoid killing the erl.exe task or abruptly powering off the system. This can cause corruption of the RabbitMQ Mnesia DB and this can only be resolved by dropping all the queue in the Mnesia DB resulting in a loss of some or all of those messages that were in the queue at that time.
Stop/Start PrismMQService after making changes to config settings
After making changes to the V9, Prism, or General sections of the PrismMQService.ini file, stop the service, wait for it to stop, then start the service again. Do not use the "restart" option.

PrismMQService.ini
Configuration information for the PrismMQService are stored in the PrismMQService.ini file.
There are three main sections to the PrismMQService.ini file:

Section Description
V9 The settings in this section only apply if the system replicates data with Retail Pro 9 (or RIL) via initialization or day-2-day.
Prism The settings in this section apply to Prism-to-Prism replication via initialization or day-2-day.
General General settings including Compression, Reconnect Delay and Save Status Interval

V9 Section Properties
Note: The V9 section has settings for communication with V9 DRS (in Prism 1.14.7 and earlier versions)

Property Possible Values Default Description
D2DMAXRETRIES Positive integer 5 Defines the number of times a message will be reprocessed in the event of an error before it is discarded. If there are issues processing a set of messages a high number here could present a performance issue.  However, a low number could result in message being discarded in the event there was some temporary issue such as an Optimistic lock on a record.
MESSAGEBATCHSIZE Positive integer 25 The number of data events that will be processed in one chunk when scanning the data event queue table. Also affects logging, as a log entry is only written as each batch is processed
INITGUARANTEEDMESSAGEDELIVERY False, True True If true, messages in RabbitMQ are flagged as persistent. This will ensure that messages are not deleted in the event RabbitMQ is restarted.  False is not recommend, because any reboot or restart of RabbitMQ those messages residing in RabbitMQ will not be retained.
UPDATEPUBTABLESINTERVAL Positive integer 105 Defines frequency (in seconds) that the DRS.DRS* tables are scanned, and the messages are moved to the DRS.PUB* tables.  The frequency increase here can send data more frequently, but it can also result in duplication of messages that results in more overhead.
PRODUCERSENDERTHREADS Positive integer 1

Defines the number of threads that the producer will use in sending messages from the producer_cache tables to RabbitMQ.  This value has diminishing returns based on the number of logical processors available on the system. Generally speaking, this settings optimal values is between 50% to 75% of the number of logical processors available on the system.
*Note this may vary from individual system setup depending on if you are using V9 & POA replication on the same system and the equvialant Prism setting for this.  One may prioritize V9 over POA or vise versa but the combined value of the two should be in this 50%-75% range.

 

INITSENDTHREADCNT Positive integer 4 Defines maximum number of initialization threads publishing messages on the producer cache. Confirm the max as well as see if we can outline how adjusting this number would provide performance gains and or impact D2D replication.
D2DRECVTHREADCNT Positive integer 5

(V9 and Prism can be defined individually)
This defines the number of threads that PrismMQ and Prism Consumer can use individually.  So if you set the value to 5 that means that Prism Consumer can use up to 5 threads to move messages from RabbitMQ to the consumer cache and PrismMQ will use up to 5 threads to consume messages.  With server mode enabled you can't exceed the number of logical processors and if you do set it to higher Prism will automatically set it to the number of logical processors divided by 2 (half the # of logical processors).

PRESERVESUCCESSRECORDS False, True False Determines whether users will see successful records and errors, or only errors (for both initialization and day to day). The default value is False, meaning that successful records are not preserved. Keeping the default value of False is important for customers with large data sets. If set to true, large quantities of unneeded data (sometimes millions of rows) could be preserved. If set to False, when you run initialization and everything is successful, you will see the completed message in the V9 Status screen but no success records.
INITIALIZATIONFIRST False, True False

By default, this setting is set to False and thus disabled. If set to True , PrismMQProducer will order outgoing messages by the "Init" flag first. If there are any initialization messages, those messages will go first before any day2day messages.
Important! After changing this setting, you must stop the service, wait for it to stop completely, and then start the service again. Do not do a "restart."

Prism Section Properties

Property Possible Values Default Description
Initialization Threads Per Sender
INITTHREADSPERSENDERCNT
Positive integer 5 How many tasks created when populating Producer_cache table (PrimsMQ) - how many messages are written to the table at a time.
Initialization Max Senders
INITSENDTHREADCNT
Positive integer 1 Defines maximum number of concurrent initialization threads publishing messages on the producer cache.
Initialization Max Receiving thread count
INITRECVTHREADCNT
Positive integer 1

Setting is hard-coded to a value of 1 and cannot be adjusted/configured

Initialization Batch Size
MESSAGEBATCHSIZE
Positive integer 25 How many messages to read from the database and process at a time. Also affects the logging or progress, as a log entry is only written as each batch is processed (Set to high and memory issues could occur).
Day-to-Day Threads Per Sender
D2DTHREADSPERSENDERCNT
Positive integer 5 Defines maximum number of D2D threads publishing messages on the producer cache. If system is set to Servermode = True, the limit is controlled by number of logical processors. If Servermode is set to False, the maximum number is 10.
Day-to-Day Max Receivers
D2DRECVTHREADCNT
Positive integer 5

(V9 and Prism can be defined individually)
This defines the number of threads that PrismMQ and Prism Consumer can use individually.  So if you set the value to 5 that means that Prism Consumer can use up to 5 to move messages from RabbitMQ to the consumer cache and PrismMQ will use up to 5 threads to consume messages.  With server mode enabled you can't exceed the number of logical processors and if you do set it to higher Prism will automatically set it to the number of logical processors divided by 2 (half the # of logical processors).

Day-to-Day Max Retries
D2DMAXRETRIES
Positive integer 5 Defines the number of times a message will be reprocessed in the event of an error before it is discarded.  If there are issues processing a set of messages a high number here could present a performance issue.  However, a low number could result in message being discarded in the event there was some temporary issue such as an Optimistic lock on a record
Day-to-Day Producer Interval
D2DPRODUCERINTERVAL
Positive integer 10 Defines how often (in seconds) which the system scans the data event queues (Prism) to publish them to the Producer_cache table.  The frequency increase here can send data more frequently but it can also result in duplication of messages that results in more overhead
Preserve Successful Records
PRESERVESUCCESSRECORDS
True, False False Determines whether users will see successful records and errors, or only errors. The default value is False, meaning that successful records are not preserved. Keeping the default value of False is important for customers with large data sets. If set to true, large quantities of unneeded data (sometimes millions of rows) could be preserved. When you run initialization, and everything is successful, but the property is set to false, you will see the completed message but you will not see success records
Initialization Guaranteed Message Delivery
INITGUARANTEEDMESSAGEDELIVERY
True, False True If true, messages in RabbitMQ are flagged as persistent.  This will ensure that messages are not deleted in the event RabbitMQ is restarted.  False is not recommend, because any reboot or restart of RabbitMQ those messages residing in RabbitMQ will not be retained.
Update Publisher tables interval
UPDATEPUBTABLESINTERVAL
Positive integer 105 (1.14.7 and earlier)
Defines frequency (in seconds) that the DRS.DRS* tables are scanned, and the messages are moved to the DRS.PUB* tables.  The frequency increase here can send data more frequently but it can also result in duplication of messages that results in more overhead
Resume Initialization at Startup
RESUMEINITONSTARTUP
   

If set to TRUE, the Receiving Side (consumer) will resume initialization after the PrismMQ service restarts. Has no affect on sender side. Should always be set to TRUE. This setting only controls the initthreadcount writing messages to the database from the consumer cache table. If set to FALSE, the consumer will not resume initialization upon PrismMQ service restart.

Producer Sender Threads
PRODUCERSENDERTHREADS
Positive integer 1

Defines the number of threads that the producer will use in sending messages from the producer_cache tables to RabbitMQ.  This value has diminishing returns based on the number of logical processors available on the system. Generally speaking, this settings optimal values is between 50% to 75% of the number of logical processors available on the system.
*Note this may vary from individual system setup depending on if you are using V9 & POA replication on the same system and the equvialant Prism setting for this.  One may prioritize V9 over POA or vise versa but the combined value of the two should be in this 50%-75% range

PMQ_PROTECT_ASN    

(only affects ASNs on receiving side)
True - During replication if the system has received a voucher (which used to be ASN), and an ASN already exists, the service consolidates the documents. If an ASN is received in replication but the voucher already exists (which used to be an ASN) an error will be recorded, and the Voucher will remain unchanged.
False - When receiving an ASN or Voucher during replication the already received documents will be overwritten.


General Section
Prism MQ General section

Property Allowed Values Default Description
Receive Timeout (seconds)
RECEIVETIMEOUTSECONDS
Positive integer 5

Defines how long a receive thread will wait before checking to see if PrismMQ is terminating.

Compression Threshold
COMPRESSION
Positive integer

100

The Compression parameter that helps avoid improve performance when replicating large files, such a large Promotions file. The Compression parameter has a default setting of 100. This means that any payload greater than 100KB will be compressed. 
Setting the parameter to "0" will turn off compression.
A typical 10MB file will compress to about 200KB.

Server Mode
SERVERMODE
True, False False Server Mode enables you to bypass some of the default Windows power management settings so servers can make more efficient use of available computing resources.
Enabling Server Mode results in increased CPU usage. Only enable when needed and then disable when no longer needed.
Limitations/Notes
While enabling server mode on a system can improve the performance of replication it can also have a negative impact.  Only set servermode=true if the system has at least 8 or more logical processors. Even on a system with at least 8 or more logical processors, users may need to adjust the number of threads for various settings noted here to see noticeable performance improvement.Use on a temporary basis.
Enabling of server mode is done on a case-by-case basis (depending on the performance of each system). If servermode=true, other integrations or applications on the system may respond poorly or even error out, as this setting prioritizes PrismMQ for CPU processing and other applications can suffer if there aren't sufficient resources available.
Disabling Server Mode will reset thread counts to the defaults. (Five threads for Day to Day, 20 for initialization).
Save Status Interval (D2D Status)
SAVESTATUSINTERVAL
Positive integer 60

PrismMQ service periodically updates day2day replication status so you can see in the Admin Console what is sent/received. If it is set to 60 (default), PrismMQ will update status every 60 seconds. is setting controls how often day-to-day replication status will be updated for each connection. PrismMQ updates this status data (number of sent, received and errored messages) in memory and, periodically, starts a background thread that will save those accumulated status updates to the records in the database.

Message Encoding Version
MSGENCODINGVEERSION
0, 1 1 Used when consuming messages that are compressed. If any system in the enterprise is using old compression method (like 1.14.6 or early version of 1.14.7 the MSGENCODINGVERSION must be set to 0. This facilitates upgrading to 1.14.7 in a gradual manner. By keeping all servers on the old encoding format, day-to-day replication can continue uninterrupted even if some servers are on 1.14.7 and some are on 1.14.6. To use the old encoding format, set MSGENCODINGVERSION to 0 and restart the PrismMQService. After finishing upgrading all the company's servers, change MSGENCODINGVERSION back to 1.
REPLICATIONVERSION     Most users should leave this at the default setting. However, there are cases where it is usefult to use this setting. Prism does not guarantee backwards compatibility between versions; thus, RabbitMQ messages may or may not be consumed after upgrade to a newer version of Prism. REPLICATIONVERSION allows users to set a version number on those systems which have been upgraded and leave those on the prior version number until all have been upgraded.  This version number is stamped on each message sent and compared at the receiving system with the configuration locally. A system on a lower version number will not process a message stamped with a higher version. Those messages will be stored in the consumer cache until such time the local system was updated and the version number in that configuration file matches or is newer than that stamped on the message.
REPLICATIONVERSION could be used to upgrade a number of system over several days to prevent the loss of messages when the user knows the messages aren't compatible.
1=service gets version from the .ini file. If set to a higher value on sender side and kept at "1" on receiving side, all messages go to receiving-side cache and remain until version on receiving side is equal (or greater).
Host Name
HOSTNAME
string system Computer machine name (RabbitMQ Host)
Reconnect Delay
RECONNECTDELAY
Positive integer 5 Defines in RabbitMQ the reconnect delay for all federated queues. Leave this setting at the default value of 5 or less if remote connections are stable and response time is fast.
Typically set to 300 if above is not true
RECORDSENDDELAY Positive integer 0 Leave this setting at the default of 0. This was implemented for troubleshooting an issue and has no value at this time to be adjusted.
QUEUEMESSAGELIMIT Positive integer 1000 Sets the message cap allowed per queue in RabbitMQ.  When that message cap is reached, PrismMQ will lock the specific queue in the producer cache table.  
Default is 1000 and generally speaking this is too low.  This setting was hard coded to 1000 in versions prior to 1.14.7.2080.
Should be set to 100,000 or greater generally. Locked queues that get large in the producer_cache can create serious performance issues and it is critical to limit locked queue for any length of time. Unlocking queues can take a long time under many circumstances and if the threshold is to low here it could unlock then saturate the queue and then lock the queue again. Additionally because the oldest messages are sent first after unlocking a queue it will send those messages first and if there is a significant number of messages it could delay Day-to-Day messages for the remaining stores impacting every store
INITIALIZATIONFIRST True, False False

Enables Initialization to have priority over day2day. By default, this setting is set to False and thus disabled. If set to True , PrismMQProducer will order outgoing messages by the "Init" flag first. If there are any initialization messages, those messages will go first before any day2day messages. Important! After changing this setting, you must stop the service, wait for it to stop completely, and then start the service again. Do not do a "restart."

REPLICATECORERESOURCES True, False True

Warning: The REPLICATECORERESOURCES parameter should only be used during initial system setup. Setting REPLICATECORERESOURCES to FALSE on an existing production system will jeopardize the integrity of all enterprise data. After the initial join/initialization is complete, it is important to change REPLICATECORERESOURCES back to TRUE (default).
The REPLICATECORERESOURCES parameter enables retailers to turn off the replication of Core Resources when needed for specific installations/links. The REPLICATECORERESOURCES parameter is set to TRUE by default. Setting REPLICATECORERESOURCES to FALSE before a server joins the enterprise can help avoid accidental overwriting of data in certain situations.
Restart the PrismMQService after changing settings for the changes to apply!
The REPLICATECORERESOURCES parameter controls replication of the following Core Resources: tenant, subsidiary, customschema, transformdesign, season, taxcode, pricelevel, currency, taxarea, storetype, store, usergroup, employee, sublocationsegpref, sublocation, controllerstore. Note: The controller resource is also one of the core resources; however, it is omitted from the list above because the controller resource is ALWAYS sent (even if REPLICATECORERESOURCES is set to FALSE.)

Log File Settings in PrismLogging.ini
Note: By default, log settings for all Prism services, including PrismMQService.ini are pulled from the PrismLogging.ini file. If you modify the log settings for PrismMQService, the changes will override the global settings defined in PrismLogging.ini. Edit log settings for PrismMQService in Tech Toolkit Service Manager. When you override the global settings by editing service-specific settings in Service Manager, a [LOG] section is added to the PrismMQService.ini file with only the settings that were overridden. See the Prism Logging topic for more information.

Factors that affect PrismMQService performance

Feature Notes
Anti-virus and Windows defender Add C:\ProgramData\Retailpro folders to the list of exceptions (with sub-folders).
O/S optimization If you change the optimization to "Background services" on the computer that runs the Prism server it will give background services more CPU time and distribute access more evenly. If you are running only Prism Proxy and browser - keep it set to "Programs."
Number of CPU cores and number of background threads

The rule of thumb is  "no more consumer threads than you have CPU cores"; however, this rule applies only to CONSUMER THREADS because they are CPU-intensive. Background threads (like reader threads or sender threads) are different. Background threads (like reader threads or sender threads) can tolerate a higher number of threads than there are CPU cores because those threads use very little CPU processing time. Background threads mostly wait for a response from a database server or from RabbitMQ so running 16 threads on an 8-core server is not a problem; however, eventually you will reach a point of diminishing returns. Therefore, at a maximum set the number of sender threads to 1 or 2 times the number of CPU cores. The total number of sender threads is limited to 16.
Regarding CONSUMER threads, quite often FEWER consumer threads can process messages just as quickly as more. Sometimes TWO consumer threads can even be on par with 8 consumer threads on an 8-core CPU (although it varies from machine to machine). This is because the more CPU-hungry threads are running the more they contend with each other for access to data in memory instead of doing useful work.

Batch Size The batch size affects how the number of reader threads work. Reader threads work on the entire batch, so if your batch size is 20 and the number of reader threads is five, PrismMQ processes five items in parallel (Four groups of five records each). But if your batch size is two while the number of reader threads is five, PrismMQ will be able to utilize only TWO threads (because there are not enough records in the batch to occupy all five threads). On the other hand, setting batch size to some high number will cause problem because it will make PrismMQ to use more memory (the more records are in the batch - the more memory it will take to hold it in memory while those records are getting sent).
Server Mode Increasing the number of background threads will have no effect unless the system has more than two CPU cores and Server Mode is enabled. If the system has fewer than two CPU cores and Server Mode is disabled, little improvement will be gained from increasing the number of background threads.
Number of connections to other Prism systems If there are only a few connections you do not need to change the number of background threads. If there are 10+ connections, you might want to consider using more than one reader and sender threads.
Hard drive write caching policy For drives that hold the C: partition and that host your Prism database. (If you right-click on the DRIVE name in the disk management console and select Properties you will be able to get to the Policies tab. If write caching is enabled it improves hard drive performance which makes RabbitMQ and the database server become more responsive. Warning! This comes with risk. A power failure could result in data loss. We recommend you leave the hard drive write caching policy as is.

RabbitMQ Management Plugin

 

The rabbitmq-management plugin provides an HTTP-based API for management and monitoring of your RabbitMQ server, along with a browser-based UI and a command line tool, rabbitmqadmin. Features include:

  • Declare, list and delete exchanges, queues, bindings, users, virtual hosts and permissions.
  • Monitor queue length, message rates globally and per channel, data rates per connection, etc.
  • Send and receive messages.
  • Monitor Erlang processes, file descriptors, memory use.
  • Force close connections, purge queues.

 Launch RabbitMQ Management Plugin

  1. In the browser address area, switch from "https" to "http". Clear the port information and anything after. Enter 15672 as the port. Press the Enter key.    
  2. Enter the following login information and then tap or click the Login button: Username: prismguest Password: prismguest    
  3. Select the tab for the area you want to work with.     
  4. When finished, click the Log out button.     

Refer to the following table for a description of the tabs on the RabbitMQ Console:

Tab Description
Overview This tab enables you to see how message processing is progressing over time. The data is displayed in a line chart format. One line chart shows queued messages (Ready, Unacknowledged, Total).
Another line chart shows message rates (Publish, Deliver, Acknowledge, Deliver - no ack).
Connections This tab shows connections. You can filter the list.
Click the HTTP API or Command Line links to display information about using the API.
Channels This tab shows current channels. You can filter the list.
Click the HTTP API or Command Line links to display information about using the API.
Exchanges Select an Exchange in the Name column to view details for the Exchange. The displayed info includes message rate in and message rate out.
Queues View messages and message rates . Messages: Ready, unacknowledged, total; Message rates: (messages per second) Incoming, deliver(get), ack

PrismMQ/RabbitMQ File List

The following files used by PrismMQ are included in the full Prism installation:

File Location Description
RabbitMQ Server …\Program Files (x86)\RabbitMQ Server RabbitMQ is the messaging service upon which PrismMQ is based.
Erlang …\Program Files (x86)\erl6.3 Erlang is the programming language in which RabbitMQ is written. Erlang is required for RabbitMQ.
PrismMQ.exe …\Program Files (x86)\RetailPro\Server\Replication PrismMQ service executable.
PrismMQProducer.exe …\Program Files (x86)\RetailPro\Server\Replication Sending side: PrismMQService saves messages to the PRODUCER_CACHE table. PrismMQProducer.exe monitors the PRODUCER_CACHE table, sends records it finds to the appropriate subscribers and then deletes the records from the PRODUCER_CACHE table. If the queue has more than 1,000 messages, PrismMQProducer stops sending messages to the queue. PrimsMQProducer stops marks the corresponding records in the PRODUCER_CACHE table and adds the names of the paused queues to the REPLICATION_LOCKED_QUEUE table.
PrismMQConsumer.exe …\Program Files (x86)\RetailPro\Server\Replication Receiving side: PrisMQConsumer.exe monitors the message queue and saves all received messages to  the CONSUMER_CACHE table. PrismMQ.exe monitors the CONSUMER_CACHE table. If PrismMQ.exe finds any messages, it saves those records to the Prism database and deletes them from the CONSUMER_CACHE table. A single queue, Prism.Day2Day, is used for both initialization and day-to-day replication. The INIT column in the PRODUCER_CACHE/CONSUMER_CACHE tables will indicate if the replication was initialization (1) or Day2Day (0).
PrismMQService.ini …\ProgramData\RetailPro\Server\conf Contains configuration information for PrismMQ.
PrismMQ.Init.json …\ProgramData\RetailPro\Server\conf Json package file. It is important that you do not modify this file.


ProgramData\RetailPro\Server\RabbitMQ\db

Folder Description
rabbit@[workstation_name]-mnesia Mnesia is a distributed NoSQL database used by RabbitMQ to store information about users, vhosts, exchanges, queues, bindings, index files (the position of messages in queues), and cluster information. RabbitMQ provides its own persistent storage for messages. Persistent messages are stored in the msg_store_persistent directory (both when they are persisted when received on a queue or when memory consumption grows beyond a specific threshold); on the other hand, non-persistent (transient) message are persisted in the msg_store_transient directory (when memory consumption on a queue grows beyond a specific threshold).
rabbit@[workstation_name]-plugins_expand Working directory used to expand enabled plugins when starting the server.

 
ProgramData\RetailPro\Server\RabbitMQ\db rabbit@[workstation_name]-mnesia

Folder Description
msg_store_persistent Messages saved to storage
msg_store_transient Message that have not yet been consumed. 
queues These are the RabbitMQ server components that buffer messages coming from one or more exchanges and send them to the corresponding message receivers.