- Revenera Community
- :
- FlexNet Publisher
- :
- FlexNet Publisher Forum
- :
- Re: FlexEnabled application not release license after exited
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
FlexEnabled application not release license after exited
Hi,
I am new to the community and working as application support helping customer to troubleshoot issue.
My customer has FlexEnabled (v11.12) application not releasing license even after it exited, and no orphaned process left behind. This happens intermittently, and they are on all Windows environment. They often have to restart license server to release the license.
The same application works fine in my own environment, it always release license successfully. I have the following questions:
1. How the license release works? Is it possible that the FlexEnabled application exited then releasing the license but the message doesn't get across to license server due to some network configuration issue?
2. I helped them to remove the license with lmremove command, but it immediately went into lingering state (for sure lmstat does not show lingering before I executed lmremove), and no, user did not borrow license at that time as well. Any guess on why lmremove put the license into lingering?
I know some would probably suggest to set TIMEOUTALL, but I would like to find the cause of the issue.
Thank you.
@choongboon , based on the lmstat output, can you confirm if in the client application (before lc_checkout call), is attribute LM_A_BORROW_EXPIRE set?
If so, then that is causing the lingering of licenses. OR the same observation will be noted if LM_A_LINGER is in use through the client application.
To answer your first question, the answer is yes.
if in the client application (before lc_checkout call), is attribute LM_A_BORROW_EXPIRE set?
* That is a difficult question for me, I am application support and has no access to the code. Is there a way (or environment variable) to log these information to a file?
* Put it in another way, is this set because of how the FlexEnabled application coded? As I mentioned, I do not have any issue with the same application.
If so, then that is causing the lingering of licenses. OR the same observation will be noted if LM_A_LINGER is in use through the client application.
* I checked the client license server option file, LINGER is not set.
* And same application in environment doesn't trigger LINGER if I lmremove the same license.
Thank you so much for your information. I am sure I can learn a lot from this alone.
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
* And same application in MY environment doesn't trigger LINGER if I lmremove the same license.
Then it would be worth confirming below details on the client system:
- Is the borrow parameter set? In either case run "lmborrow -clear" once and then re-run the test.
- If possible, either raise a support case (or if you are ok, then share the client sample application code) here, so that we can analyze the same.
- Can this issue only be seen on a particular system?
Thank you for your advice, I will make sure on the borrow side and even restrict the borrow feature as it is not needed in their system.
Myself can't get the code though, will see if development team can do that.
I am not sure what so special about the environment, else I would be able to replicate that. However even on their environment, issue seems to be intermittent, more like an runtime environment issue I would say.
I can re-produce this issue by dropping the network connection before existing the FlexEnabled application.
You can easily check this with a network monitor like Wireshark. If a application exists the operation system will make sure an [RST, ACK] packet is send over to the license server. So the license is immediately released. If the network connection is dropped (or this packet gets lost) the license sever will not notice that the client is gone until it is notified by a flush.