Recovering from a Messaging Error
The Change Management Service is stopped when a nonconforming message is received. When CMS is stopped due to a messaging error, all incrementally maintained caches are marked as Disabled, and subscription failure messages with content of “<ops/>” are sent to all subscribed clients.
The cs_server.log should be checked for an exception message like the following example:
Exception: java.lang.Exception: Invalid message element: expecting 'before' element, got 'missing'...
Invalid message element indicates that the messaging format was broken and outside of schema requirements. CMS issues “<ops/>” messages to subscribing clients, invalidates caches, and stops so that CMS and messaging can be restarted from a configured state.
If the exception is a data type mismatch, it is likely that the source of the error was not the Oracle GoldenGate process, and so those processes do not need to be recreated. However, queues and topics might still have to be purged to clear the system of corrupt data.
To resolve messaging issues
1. Check the Oracle GoldenGate configuration parameter file in the /dirprm subdirectory where Oracle GoldenGate is installed. Make sure that the parameters GETUPDATEBEFORES, NOCOMPRESSUPDATES, and NOCOMPRESSDELETES (and any other relevant parameters) are set up to create messages that are compatible with CMS.
2. Stop the “extract” and the “JMS Pump” processes.
3. Delete the GoldenGate extract and JMS Pump processes.
4. Remove the trail files defined in the two related *.prm files. The trail files are typically in the dirdat folder of the GoldenGate home directory, $GGHOME/dirdat, and the files all begin with the two-character prefix specified for the name of the exttrail filename group. (See
Installing and Configuring Oracle GoldenGate.)
5. Make corrections to the configuration parameters.
6. Recreate the GoldenGate extract and JMS Pump processes using the .obey file.
7. If the TDV-Managed Destinations configuration parameter is set to false, use a TIBCO EMS utility to purge queues and topics named under Change Management Service > Central Function > Messaging > Internal EMS, as follows:
— Use purge queue <queue_name> to purge the queue named in In Transit Event Queue.
— Use purge topic <topic_name> to purge the topic named in Transient Cache Buffering Topic.
8. Use TIBCO EMS utility purge topic <topic_name> to purge the input EMS topics specified on the Change Notification panels of all data sources configured for incremental caching.
9. Restart the TDV Change Messaging Service on the Central Events Server.
10. Restart all disabled caches with the following for each incrementally maintained cache.
a. Clear the Incrementally Maintained check box on the Caching tab of the view.
b. Save the view.
c. Select the Incrementally Maintained check box and then save the view again. Wait a few moments while the cache re-initializes itself by creating a materialized view based on the SCN timestamp reported by the GoldenGate monitoring utility.
Incrementally maintained caches that were marked as Disabled should then show a status of Up, and those caches will be kept in sync, mirroring all changes made to the watched data sources.
Outbound EMS topics with subscribers listening for change notifications on subscribed views automatically begin receiving change notification messaging when changes to the watched sources are reported.