After migration from EMS 5.x/6.x to EMS 7.x version, the EMS server reported "Error occured while processing Message record" errorand failed to start up.
Article ID: KB0089981
Updated On:
| Products | Versions |
|---|---|
| TIBCO Enterprise Message Service | - |
| Not Applicable | - |
Description
Resolution:
Description:
=================
After migration from EMS 5.x/6.x to EMS 7.x version, EMS 7.x reported the following error and failed to start up, while EMS 5.1.5 server was able to start up without any issue:
2013-03-19 16:16:17.620 Recovering state, please wait.
2013-03-19 16:16:32.143 SEVERE ERROR: Error occured while processing Message record id=2880132 (get record) - Unable to reconstruct message: 74 - IO failed
2013-03-19 16:16:32.143 FATAL: The recovery process stopped while processing a 'Message' record (id=2880132), error: 74 - IO failed. Check the section 'Error Recovery Policy' from chapter 'Running the EMS Server' in the User's Guide before attempting to restart the server
2013-03-19 16:16:32.164 FATAL: Exception in startup, exiting.
Resolution:
=========
EMS 5.x/6.x server will not report an error for the old-style store parameters: store_crc, store_minimum, store_minimum_async, store_minimum_sync, store_truncate defining in main conf file for backward-compatibility for customers coming from EMS 4.x and earlier. However we have documented that these parameters were obsolete since version 5.0. When something is marked as obsolete, it is expected that after a while it will simply be removed.
If you define store_crc to disabled in EMS main config file, the EMS 5.x/6.x server will not validate CRC checksum data when reading the store files, so it will not report the error when detecting a message with bad CRC checksum.
Since EMS 7.0, we dropped the backward-compatible old-style syntax but still support the behavior with multiple store syntax. So EMS 7.x will report errors for those old-style store parameters when starting up. If you set startup_abort_list to contain CONFIG_ERRORS, the server will not even start because of the presence of "store_crc" (and others) as this is considered a configuration error. If startup_abort_list does not contain CONFIG_ERRORS, EMS 7.x starts up with errors for old-style store parameters. As its default behavior, the EMS 7.x server will validate CRC checksum when recovering the store files. So EMS 7.x will report error and fail to start up when detecting a message with a bad CRC checksum.
Before migrating to EMS 7.x , you need to modify the configuration files to define the default db files as multiple store syntax. If you do not want the EMS server to validate CRC checksums when recovering the store files, you need to set file_crc to false for the store file. See the EMS User Guide: “Store Messages in Multiple Stores” chapter for details.
Description:
=================
After migration from EMS 5.x/6.x to EMS 7.x version, EMS 7.x reported the following error and failed to start up, while EMS 5.1.5 server was able to start up without any issue:
2013-03-19 16:16:17.620 Recovering state, please wait.
2013-03-19 16:16:32.143 SEVERE ERROR: Error occured while processing Message record id=2880132 (get record) - Unable to reconstruct message: 74 - IO failed
2013-03-19 16:16:32.143 FATAL: The recovery process stopped while processing a 'Message' record (id=2880132), error: 74 - IO failed. Check the section 'Error Recovery Policy' from chapter 'Running the EMS Server' in the User's Guide before attempting to restart the server
2013-03-19 16:16:32.164 FATAL: Exception in startup, exiting.
Resolution:
=========
EMS 5.x/6.x server will not report an error for the old-style store parameters: store_crc, store_minimum, store_minimum_async, store_minimum_sync, store_truncate defining in main conf file for backward-compatibility for customers coming from EMS 4.x and earlier. However we have documented that these parameters were obsolete since version 5.0. When something is marked as obsolete, it is expected that after a while it will simply be removed.
If you define store_crc to disabled in EMS main config file, the EMS 5.x/6.x server will not validate CRC checksum data when reading the store files, so it will not report the error when detecting a message with bad CRC checksum.
Since EMS 7.0, we dropped the backward-compatible old-style syntax but still support the behavior with multiple store syntax. So EMS 7.x will report errors for those old-style store parameters when starting up. If you set startup_abort_list to contain CONFIG_ERRORS, the server will not even start because of the presence of "store_crc" (and others) as this is considered a configuration error. If startup_abort_list does not contain CONFIG_ERRORS, EMS 7.x starts up with errors for old-style store parameters. As its default behavior, the EMS 7.x server will validate CRC checksum when recovering the store files. So EMS 7.x will report error and fail to start up when detecting a message with a bad CRC checksum.
Before migrating to EMS 7.x , you need to modify the configuration files to define the default db files as multiple store syntax. If you do not want the EMS server to validate CRC checksums when recovering the store files, you need to set file_crc to false for the store file. See the EMS User Guide: “Store Messages in Multiple Stores” chapter for details.
Issue/Introduction
After migration from EMS 5.x/6.x to EMS 7.x version, the EMS server reported "Error occured while processing Message record" errorand failed to start up.
Feedback
Yes
No
Powered by
