Caching
When replicating messages from one system to another (i.e. from "Producer" of messages to "Consumer" of messages), Prism caches messages to prevent bottlenecks.
Three modules work together to cache replication messages: PrismMQ.exe, PrismMQProducer.exe and PrismMQConsumer.exe.
| Program | Description |
|---|---|
| PrismMQ.exe | Previously, PrismMQ.exe was the only module used for replication. Now, PrismMQ.exe still runs as a service and in the background 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. Path: Program Files (x86)\RetailPro\Server\Replication |
| PrismMQConsumer.exe | This module monitors the CONSUMER_CACHE table and saves any messages it finds to the Prism database. Path: Program Files (x86)\RetailPro\Server\Replication |
PRODUCER_CACHE, CONSUMER_CACHE tables
Prism uses two special tables to perform caching: PRODUCER_CACHE on the sending side and CONSUMER_CACHE on the receiving side.
On the sending side, PrismMQService saves messages to the PRODUCER_CACHE table. The PrismMQProducer.exe monitors the PRODUCER_CACHE table and sends any records it finds to the appropriate subscribers and then deletes the records from the PRODUCER_CACHE table.
On the receiving side, PrismMQConsumer.exe monitors the message queue. All messages that are received are saved 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.
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. Note: There should never be more than 2,000 messages in a queue at any time.
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).
MSGENCODINGVERSION setting in PrismMQService.ini
As part of the caching feature, Prism 1.14.7 and later uses a different encoding format for compressed messages. The MSGENCODINGVERSION (Message Encoding Version) setting in the PrismMQService.ini file controls which encoding format (new or old) is used. 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."