Summary

This article is targeted for specific use cases, where we have the license server and client connectivity issues (not a delay, but failure). This best practice guide is to be followed to make sure that all the official/minimal checks and setup are in place.

1. Ensure that the Server and Client can perform a basic 'ping' to each other.
2. If possible, try including an entry in /etc/hosts file for both against each other - respectively.
3. It is recommended to bind the SERVER and vendor daemon to a specific TCP port (not mandatory), as:
   SERVER <host_name> <HOSTID> 27000
VENDOR demo PORT=56789
4. On server & Client, add both of these ports under the allowed list for 'to ' and 'from' list for internal and external network communication. This should be done for OS firewall as well as any antivirus software if in place.
5. Add the lmgrd, vendor daemon executable, and client application executable (it could be normal lmflex OR TS-based utilities such as appactutil, serveractutil OR lmstat, lmutil) into the exception list for Antivirus, if the option is available.
6. Look into the Power settings and select the option for "sleep" as Never - so that non of the USB (if dongle in use), Hardware, Kernel or I/O operations are put under hold in case of inactivity for a long time - which is common on server systems.
7. On some operating systems (Flavors of windows), there should be an option for "hardware Sleep" settings (Under Edit Plan Setting > Change Advanced Power Setting) - please select that as Never.
   NOTE: A license server should never be put in a sleep mode, as even when there is no client activity on the server, internally there will be a heartbeat mechanism being followed in-between "lmgrd<->vendor daemon" & "client <->vendor daemon" - to ensure that server & Vd are up and still serving the licenses.
   For systems that get under sleep for more than the default (automatic) heartbeat threshold for vendor daemon & lmgrd communication cycle delay i.e. 300 seconds, on revival license server may get shutdown/restart with an error and subsequent statement in debug log as:

            HH:MM:SS (VD_name) Lost connection to lmgrd, heartbeat timeout expired, exiting.
            HH:MM:SS (VD_name) Heartbeat timeout is 300 seconds. Elapsed time is XXXXXXX seconds.
            HH:MM:SS (VD_name) EXITING DUE TO SIGNAL 28 Exit reason 5

   It can be avoided by either making changes in Step-6 & 7. OR,
8. For scenarios of latency:
   Windows Only Solution: To use environment variable "FLEXLM_TIMEOUT":
   Sets the timeout value a FlexEnabled application uses when attempting to connect to a license server. Values are in microseconds, within the range of 200,000 (0.2 seconds) through 20,000,000 (20 seconds). The default value is 3,000,000 microseconds (that is 3 seconds).
   For a more Universal Approach:
   Try using the client attribute 'LM_A_CONN_TIMEOUT'. LM_A_CONN_TIMEOUT attribute defines the maximum time (in seconds) the client would wait to receive a response after sending a single request to the license server. This attribute allows publishers to change the default timeout value if needed.
   NOTE: The timeout should not be increased too much from its default value as this will affect client performance in bad network conditions, and in such scenarios, the publisher may wish to perform some experiments to determine a suitable timeout value. The trade-off is small values results in better client performance but large values result in a decreased probability of clients being timed out.
9. To improve the further performance, kindly have a look at below KB articles as well:
   https://community.revenera.com/s/FlexNet-Publisher-Knowledge-Base/IPv4-and-IPv6-address-prioritization-for-licensing-communication/ta-p/130022
10. If the above steps don't help, then please log a case with support@revenera.com.