General Guidelines for Resolving Stuck Initialization

Overview

Initialization transfers data from one system to another but can sometimes become "stuck" and stop progress due to various issues. This guide provides general troubleshooting steps for addressing stuck initialization in Retail Pro.

Important:

• Never initialize history data (e.g., documents, slips, vouchers, adjustments) from a subordinate system to a POA. History not present in the POA will be processed without affecting on-hand quantities.
• Always use the Resend Data Tool to resend any missing history data to the POA. Contact support via WebTAC for assistance with this tool.

Common Questions and Troubleshooting

Q: Why is a stuck initialization a problem?
A: A stuck initialization pauses day-to-day (day2day) replication. This means all day2day data will back up until initialization is either completed or canceled. Additionally, a stuck initialization can prevent further initialization to the same store and potentially other stores, depending on replication configuration.

Potential Causes and Solutions for Stuck Initialization

Sometimes, initialization can be resumed in the following cases:

1. Network Connectivity Loss
   • If connectivity is restored, initialization may resume.
2. System Reboot or Shutdown
3. Database Stop
   • Initialization might resume if the source has generated all data before the interruption. However, there's no guarantee.

 

Troubleshooting Network Connectivity Issues

1. Check Admin Console Connection Manager:
   • Go to Admin Console > Connection Manager and select the connection being initialized.
   • If you can only see the sending profile but not the receiving one, there's a connectivity issue between the source and destination.
2. Check RabbitMQ Console
   • Access the RabbitMQ console at http://servername:15672.
   • Username: prismguest
   • Password: prismguest

Filter Day-to-Day Queues:

Go to the Queues (or Queues and Streams tab, depending on your Prism version).

• In the Filter field, enter "day" to display only day2day queues.

 

Check Consumer Count:

• Identify the queue in question (e.g., Prism.day2day).
• Click on the +/- hyperlink and select Consumer Count

1. If Consumer Count is Zero:
   • For Local Queue: If the local Prism.day2day queue shows zero consumers, restart the Prism replication service on the local machine.
   • For Remote Queue: If the remote Prism.day2day queue shows zero consumers, restart the remote machine's replication service.
     • If this doesn't resolve the issue, ensure that the remote machine can connect to port 5672 on the local machine.

For more details on required ports, refer to this Knowledge Base article.

Canceling a Stuck Initialization

If initialization cannot resume, cancel it from Admin Console > Connection Manager.

Best Practice: Cancel from the destination side, not the source.

Q: What if the cancel attempt fails?
A: If canceling fails, database records may need alteration to clear the stuck initialization. Below are the relevant database fields:

Database Fields for Stuck Initialization

For Prism to Prism:

• Complete_flag in initialization_status_header
• Status in init_status_connection

For RP9/RIL to Prism:

• Complete_flag in drs.pub_initload_status_header
• Status in drs.pub_initload_connection

These tables connect through header_sid.

Status Codes for Initialization:

• Complete_flag:
  • 0: Data generation incomplete.
  • 1: All initialization data generated.
• Status:
  • 0: Initialization canceled.
  • 1: Initialization in progress.
  • 2: Initialization complete.

Manual Canceling Process:

1. Wait for any active initializations to complete.
2. Change Complete_flag from 0 to 1 and Status from 1 to 0 for the stuck initialization.
3. Commit the changes; the UI should update immediately.
4. Restart the replication service to resume day2day replication.

Final Notes

If additional assistance is needed, contact the support team via WebTAC. Altering database values should only be done if necessary and under guidance.