Retail Pro Prism Replication Troubleshooting - What Not To Do

This is a table of replication troubleshooting provided from the 2022 Retail Pro Prism 2 Workshop.

Kill the Process (PMQ, RMQ/erl.exe, etc.) Killing the task from Task Manager
  • Killing RabbitMQ can cause data corruption in RabbitMQ queues
  • Orphaned initialization
  • Data/message loss
  • Identify root cause or isolate issue first.
  • Restart services using service manager
  • As a last resort, kill the task/process but ensure that it isn't in the middle of some process to avoid/mitigate the issues associated with this.
Restart PrismMQ as defacto solution/resolution Restarting PrismMQ without a clear understanding of the issue or state of the system
  • Lost messages
  • Stuck/orphaned initialization
Identify the root cause or isolate the issue first. Many times, the solution is not related to the application and the restart can be avoided.
Leave closed/inactive stores active in Retail Pro Prism Leaving stores in Retail Pro Prism that are closed or offline for extended periods of time
  • Excessively large locked queues can create strain on the system and prevent online system from getting D2D data.
  • Producer cache tables can grow very quickly get extraordinarily large.
  • Performance can degrade as the table grows.
  • Make sure to remove profiles for stores which are offline for extended periods to avoid accumulating large sets of messages on the producer cache tables.
  • Remove closed stores from the enterprise.
Initialize data just because one item is incorrect or missing Initializing inventory when a small or single set of data is out of sync Adds unnecessary load on system.
  • Verify data isn't in the queue already.
  • Use alternatives such as the compare tool, manually edit the item/customer.
  • Track if the item/items are sent and then determine if there is an issue with replication or the data.
Send data that is not required

Sending data unfiltered to the store that they don't use or need


  • Sales receipts/vouchers/etc. for all stores
  • Customers (potentially)
  • Outslips
  • PO & TO
  • UDFs
Adds overhead to the system for no reason
  • Filter where possible by store
  • Avoid sending documents or customers, etc., if not need.
Send D2D messages too frequently Setting the D2D interval in the PMQ config file too low Sending data such as inventory/customers to frequently with high data volume can overwhelm the system with duplicate messages Generally speaking, set this between 300 and 900 seconds, and in some cases more if bulk loads/updates are an issue.
Replicate messages from POA to RIL Unless data is being created in the POA, you should not be replicating messages from the POA to RIL Increased overhead due to the cost of consuming and then producing the same message you just received Send the message from the store to both RIL and POA.  One message is created and sent to both queues and you only have to create the message once.



Published on Jul 19, 2022 in Data Replication, Errors


Find Another Article