This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- FlexNet Publisher
- :
- FlexNet Publisher Forum
- :
- Network connection issues
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 03, 2009
12:10 PM
Network connection issues
Hi
When there is network disconnection for a while and gets re-connected, the heartbeat still fails.
Following are the parameters which I am using:
Manual Heartbeat interval - 30 seconds
Retry interval - 30 seconds
LM_A_TCP_TIMEOUT - 10 minutes
Server TIMEOUT - 15 minutes
Assume the following scenario:
1. A Client checked out a license L from the license server
2. The heartbeats are exchanged regualrly.
3. There is a network problem and the heartbeat failed.
4. The network connection got restored immediately but the heartbeats are still failing.
5. Until the server reaches TIMEOUT (15 minutes), the license is not usable by the client. The server checks in the license only after 15 minutes.
Is there any way that the client can access the license before the server reaches the TIMEOUT since the license is already checked by the client and the network problem was only for a minute; why should it wait till the server reaches its TIMEOUT?
When there is network disconnection for a while and gets re-connected, the heartbeat still fails.
Following are the parameters which I am using:
Manual Heartbeat interval - 30 seconds
Retry interval - 30 seconds
LM_A_TCP_TIMEOUT - 10 minutes
Server TIMEOUT - 15 minutes
Assume the following scenario:
1. A Client checked out a license L from the license server
2. The heartbeats are exchanged regualrly.
3. There is a network problem and the heartbeat failed.
4. The network connection got restored immediately but the heartbeats are still failing.
5. Until the server reaches TIMEOUT (15 minutes), the license is not usable by the client. The server checks in the license only after 15 minutes.
Is there any way that the client can access the license before the server reaches the TIMEOUT since the license is already checked by the client and the network problem was only for a minute; why should it wait till the server reaches its TIMEOUT?
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 03, 2009
02:01 PM
Item 4 is surprising: if the connection is restored, the heartbeat should be able to get through... In any case, the lmremove utility or lc_remove function or suchlike can restore a license to the server pool in this kind of situation.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 04, 2009
03:15 AM
Yes, the license can be freed using the lmremove utility from the server. But the problem comes when our customers are running a batch files for 10-12 hours. When a heartbeat fails during a batch run, it doesn't automatically recover.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 25, 2015
05:52 AM
Hello, i know that this is an old thread but we have run into the same problem, so we would like to ask a few things.
Our customer have network changes/disconnection (e.g. moving from LAN to WiFi) while licenses have been checked out and this cannot be avoid since the runs are too long.
So the story is the same, unsuccessful heartbeat and then goes to reconnection phase and checks-out a new license while the old one is becoming available again after 2 hours (we have the defaults for LM_A_TCP_TIMEOUT and all others parameters).
After doing some tests we are considering to adjust the LM_A_TCP_TIMEOUT param to 7 min (2-4 min to recognize a heartbeat failure + 5 mins for the 5 reconnection attempts, one per minute) in order to totally avoid the above mentioned problem.
Are there any side effects by doing this that we are unaware off ?
Is there any case of license abuse ?
Is there any reason for the LM_A_TCP_TIMEOUT to be so high by default (2 hours) that we cannot see ?
Thank you in advance.
Our customer have network changes/disconnection (e.g. moving from LAN to WiFi) while licenses have been checked out and this cannot be avoid since the runs are too long.
So the story is the same, unsuccessful heartbeat and then goes to reconnection phase and checks-out a new license while the old one is becoming available again after 2 hours (we have the defaults for LM_A_TCP_TIMEOUT and all others parameters).
After doing some tests we are considering to adjust the LM_A_TCP_TIMEOUT param to 7 min (2-4 min to recognize a heartbeat failure + 5 mins for the 5 reconnection attempts, one per minute) in order to totally avoid the above mentioned problem.
Are there any side effects by doing this that we are unaware off ?
Is there any case of license abuse ?
Is there any reason for the LM_A_TCP_TIMEOUT to be so high by default (2 hours) that we cannot see ?
Thank you in advance.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 24, 2017
05:31 AM
vasilis.poiklis wrote:
Are there any side effects by doing this that we are unaware off ?
Is there any case of license abuse ?
Is there any reason for the LM_A_TCP_TIMEOUT to be so high by default (2 hours) that we cannot see ?
Thank you in advance.
+1 for getting answers
We use 11.14, our customer has a laptop on a docking station. He disconnected - client was killed and license keys were still locked.
