haflip-detect-timeout
Section: general
Default Value: 10
Valid Values: -1, 10–2147483647
Changes Take Effect: Immediately
Specifies the time interval, in seconds, for which Solution Control Server detects the flipping of the monitoring applications from Primary to Backup to Primary or vice versa, and prints the following standard log messages depending on the state of the applications or SCS:
- 10327—Indicates that the operation mode (primary or backup) of the application has changed frequently.
- 10328—Indicates that the application is in a stable state.
- 10329—Indicates that "split brain" condition may have occurred for SCS.
- 10330—Indicates that SCS has recovered from the split brain state.
- 10331—Indicates that SCS is operating without a backup.
When set to -1, this timeout is disabled.
Known Issues and Recommendations
Solution Control Server
The Known Issues and Recommendations section is a cumulative list for all 8.5.x releases of Solution Control Server. This section provides the latest information on known issues and recommendations associated with this product. It includes information on when individual items were found and, if applicable, corrected. The Resolved Issues section for each release describes the corrections and may list additional issues that were corrected without first being documented as Known Issues.
See also Internationalization Issues.
SCS version 8.5.100.56 shuts down unexpectedly if a large string (length > 1024) passes as a log message description by any application, while raising alarms.
Workaround: Disable the detailed alarm logging option by configuring detailed-alarm-log = false in the general section of the SCS option and restart SCS.
| ID: MFWK-24157 | Found In: 8.5.100.56 | Fixed In: 8.5.100.57 |
When the haflip-detect-timeout option in the general section is set to -1 and the SCS primary disconnects from backup, the primary SCS updates the backup status as STOPPED. But when the connection is restored, the SCS primary fails to update the backup to RUNNING status.
Workaround: Set the haflip-detect-timeout option to any other valid values mentioned in the Configuration Options Reference Manual.
| ID: MFWK-23315 | Found In: 8.5.100.46 | Fixed In: |
In a distributed Solution Control Server (SCS) environment, if the port of any of the Host objects is modified, all the SCSs in the system will try to connect to that host.
Workaround: To avoid this:
- Don't change the LCA port after the system is up.
- Restart the SCS after changing the port. This stops SCS from connecting to the LCA of the host that the SCS is not controlling.
| ID: MFWK-23087 | Found In: 8.5.100.21 | Fixed In: |
If the haflip-detect-timeout option is set to a value above 15, SCS cannot detect the split brain condition of its peer when it is operating in distributed mode.
| ID: MFWK-21604 | Found In: 8.5.100.39 | Fixed In: 8.5.100.40 |
SCS terminates unexpectedly when the Alarm for the log event (43-)10401: SC Interface [app name] disconnected, socket=[socket number], client's host=[client's host] client's tenant=[client's tenant] is created.
| ID: MFWK-24157 | Found In: 8.5.100.56 | Fixed In: 8.5.100.57 |
If one or more secure (using TLS) connections between LCA and SCS are configured incorrectly, SCS might stop responding if a connection cannot be upgraded in secure mode.
| ID: MFWK-17437 | Found In: 8.5.100.08 | Fixed In: 8.5.100.16 |
If SCS is unable to connect with a management port configured on any server (Configuration Server, DB Server, or T-Server), it generates the MNGM exception error and tries to reconnect. This error condition is known to have a memory leak, which causes SCS to consume an ever increasing amount of memory.
Workaround: To avoid this condition, configure a management port on each server where required.
| ID: MFWK-17342 | Found In: 8.5.100.05 | Fixed In: 8.5.100.13 |
SCS does not always send e-mail notifications as Alarm Reactions if one or more addresses in the To: field are invalid.
| ID: MFWK-16644 | Found In: 8.5.100.04 | Fixed In: |
SCS might terminate unexpectedly when running in multi-threaded mode.
Workaround: If you are using SCS 8.5.100.04 or later, do not switch the server to enable multi-threaded mode. If you are using previous versions of SCS 8.5, disable multi-threaded mode by setting the environment variable GCTI_SCS_CONN_STARTUP_DEFAULT to 1 (one) before starting SCS.
| ID: MFWK-16614 | Found In: 8.5.100.04 | Fixed In: |
If SCS has network logging enabled, and is connected to the Log Message Server, it might use additional memory (up to 2.5 GB) for internal log buffer usage.
| ID: MFWK-16612 | Found In: 8.5.100.04 | Fixed In: |
Configuration Server Proxy is not restarted automatically when the backup master Configuration Server is working in primary mode.
Workaround: When the backup master Configuration Server is working in primary mode, stop and start Configuration Server Proxy from the Management Layer.
| ID: MFWK-16980 | Found In: 8.5.000.18 | Fixed In: 8.5.100.08 |
If SCS was started from the command line on Windows, it does not stop when you press CTRL+C in the command window.
| ID: MFWK-15803 | Found In: 8.5.000.18 | Fixed In: |
SCS might terminate unexpectedly and generate a core file if a Data Write Error alarm is configured on the SCS Application, and one of the clients of SCS was disconnected.
Workaround: Remove the SCS Application type from Data Write Error Alarm Conditions. Instead, rely on the Host's disconnection and application failures Alarm Condition instead of generic Write failures. If a Data Write alarm must be created, Genesys recommends that you exclude SCS from this Alarm Condition's detection Application list, to avoid this recursive error scenario causing the termination.
| ID: MFWK-16541 | Found In: 8.5.000.15 | Fixed In: 8.5.100.05 |
The Application metadata for Management Framework Application Templates contains an incorrect spelling of the message_format option. The correct spelling is message-format. The option will not take effect for Application objects created from one of these templates unless the spelling is changed.
Workaround: Manually update the name of the application option, either in the Application Template object itself, or in the Application objects created from the template.
| ID: MFWK-15683 | Found In: 8.5.000.15 | Fixed In: 8.5.000.18 |
No error message appears in SCS logs if SCS is unable to connect to Configuration Server because multiple instances of SCS are running and using the same application.
Workaround: Check the Configuration Server log to identify the reason why SCS did not start.
| ID: MFWK-15564 | Found In: 8.5.000.15 | Fixed In: 8.5.100.22 |
SCS is unable to complete a switchover of an HA Application, running in backup mode, into primary mode, in the following scenario:
- The second Application in the HA pair terminated and could not be re-started; it reported an error message to SCS, such as LCA_ERROR_APP_NOT_READY_TO_WORKS, before terminating.
- The disconnect-switchover-timeout option is configured on SCS to delay switchover.
| ID: MFWK-16629 | Found In: 8.1.300.18 | Fixed In: 8.5.100.06 |
SCS might consume 100% of the CPU when encountering the broken TCP socket pipe scenario when using the remote application on Linux. SCS is still operational in this situation. The CPU should return to normal operation when the affected TCP connections finally close on both sides.
| ID: MFWK-16185 | Found In: 8.1.300.14 | Fixed In: 8.5.100.04 |
In some cases, a race condition might occur between SCS running in primary mode and SCS running in backup mode when they handle a network outage between each other. As a result, the servers might change their modes; SCS running in primary mode might become backup, whereas its peer might become primary. SCS that is newly promoted to primary, while continuing to operate as primary, does not clear up some of its internal state and continues to probe its peer, which it cannot contact due to the peer being in backup mode. As a result, the customer interface, connected to SCS running in primary mode, might display the peer SCS (running in backup mode) as stopped.
| ID: MFWK-16904 | Found In: 8.1.200.13 | Fixed In: 8.5.100.08 |
In an environment with an HA SCS configured and running, with a Java-based application that has Autostart enabled and is configured to start by a special startup batch file (.bat or .sh), when the host on which the application is running is restarted, the status of the application fluctuates continuously between Initializing and Started.
Workaround: In the options of the Application object, set autostart=false in the [sml] section, and stop the application before the host is restarted. After the host has restarted successfully, manually start the application.
| ID: MFWK-17379 | Found In: 8.1.200.11 | Fixed In: 8.5.100.13 |
Solution Control Server retrieves the incorrect SNMP metric (number of clients of the Application) for an Alarm Condition instead of the number of calls being handled by T-Server or SIP Server.
| ID: MFWK-16331 | Found In: 8.1.200.11 | Fixed In: 8.5.100.05 |
When a large number of applications are configured and launched on the same host, SCS might display some of them as having an Unknown state after it has been connected to the host for the first time or to restore a connection that had been lost. The correct status of an affected application will be displayed after any change in the runtime status or mode of the application occurs.
| ID: MFWK-17021 | Found In: 8.1.200.05 | Fixed In: 8.5.100.10 |
Internationalization Issues
Information in this section is included for international customers.
There are no internationalization issues for this product.