cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
nihalkumar
Level 3

Check-in in case of crash or force shut down

Hello friends,

I am using check-out of a feature. Once the process is closed or disposed then I am calling check-in to return the handle in the pool so that another instance of the feature can be checked-out based on the number of supported feature provided in license file.

Now, In case if the process gets crashed or forcefully closes then the routine will not be invoked and check-in of that feature will not be invoked, then in this case how server comes to know that we have that feature no longer available and new feature check-out is being allowed ?

Please help me to understand how FlexLM server keeps track of features(check-out/check-in)

Thanks

0 Kudos
(7) Replies
jyadav
Flexera Alumni

Hi  @nihalkumar  ,

In FNP we have a concept of heartbeats, Heartbeat exchange is the mechanism by which a FlexEnabled application keeps track of the license server status.

The flexible API attribute LM_A_TCP_TIMEOUT takes care of it ,During normal operation, the license server exchanges heartbeats with FlexEnabled clients to ensure that they are
connected. If a FlexEnabled client disconnects from the license server, the license server will check in all licenses that are associated with the client application.
This attribute is used in situations where the license server stops receiving heartbeats from a client that has not closed the socket connection. This value is used to specify how long the license server waits since it received the last heart beat before
it determines that the client is disconnected and checks in all licenses associated with that client.

 

0 Kudos

Thanks for the quick reply.
But it seems we are not using this attribute. The automatic hearbeats are disabled in our application. Please see :

lc_set_attr(lmjob, LM_A_CHECK_INTERVAL, (LM_A_VAL_TYPE) -1);
lc_set_attr(lmjob, LM_A_RETRY_INTERVAL, (LM_A_VAL_TYPE) -1);
Means our application only checks for the status of license server. The automatic hearbeat is disabled.

So i am little confuse how the server still able to identify that the process is unintentionally shut down without letting the server know and still server allows the next license to be checked-out.

Also, can you please provide a sample code if possible where i can enable the application to send automatic heartbeat to server? 

0 Kudos

Hi @nihalkumar  ,

The manual heartbeat routine returns the number of reconnects over a given time period and the state of the connection to
the license server. Monitor these return values and take appropriate action.
The heartbeat routine performs the following services on behalf of the application:
• It attempts to read the acknowledgement from the previous heartbeat.
• If there is no acknowledgement, it makes one attempt to reconnect to the license server.
• If there is acknowledgement, it sends the next heartbeat message.
• It returns with a status: 0 if there was an acknowledgment or the number of unacknowledged heartbeats. This number
is incremented for each consecutive time a heartbeat was not acknowledged.
• After the fifth (default) consecutive unacknowledged heartbeat (five calls to the heartbeat routine), it causes the
application to exit (via the standard exit system call) with the error message Lost License, cannot reconnect.

These are the attributes used to control it ,LM_A_RETRY_COUNT, LM_A_RETRY_INTERVALS
LM_A_USER_EXITCALL, LM_A_USER_EXITCALL_EX
LM_A_USER_RECONNECT, LM_A_USER_RECONNECT_EX
LM_A_USER_RECONNECT_DONE, LM_A_USER_RECONNECT_DONE_EX

When Connection to license server is lost whether intentional or unintentional and an attempt to reconnect is unsuccessful.  After LM_A_RETRY_COUNT number of reconnect attempts , control automatically transfers to the exit handler, exitcall * which will checkin the license back.

for sample code and more information on how the mechanism works ,Please refer to the Programming Reference guide of FNP which will be available on Product and License Centre.

0 Kudos

Hi,

Here I think you are suggesting that the application should check the hearbeats and take the appropriate action in our client application. But the requirements is a bit different.

Let's take an example.
I have 2 license feature(client application) to be checked-out. So i setup a heartbeat routine. Now if i launch a third client application(or 3rd instance of same application), the server won't allow me to do since it will tell the max number of license feature has reached. 

Now, one of my application is closed(due to any unexpected event). Now,

1. How the server will come to know that there is one client which is down. Does it come t o know because the client is no longer sending any heartbeat signal?

2. Currently we don't have such mechanism. The client is only checking if server is up or not. Then in this case, how the server comes to know that the client application is down? Because I am able to launch the new client application as soon as one goes down and server is allowing me to check-out

0 Kudos

Hi @nihalkumar  ,

1. How the server will come to know that there is one client which is down. Does it come t o know because the client is no longer sending any heartbeat signal?

Yes that's correct , client will  stop sending heartbeats and no acknowledgement will be received .A message will be displayed while checkin the license back and server would know that client is disconnected when the heartbeat stops.

 

2. Currently we don't have such mechanism. The client is only checking if server is up or not. Then in this case, how the server comes to know that the client application is down? Because I am able to launch the new client application as soon as one goes down and server is allowing me to check-out.

Automatic Heartbeat mechanism is the ideal suggested mechanism for seamless flow. If the server is down the 2nd checkout should fail ideally.

So in case automatic is not working for you then please raise a case with support .

0 Kudos
raffie
Level 6

Hi @nihalkumar,

While heartbeats are important and you should be using them, I don't think that they are the accurate answer to what you are asking.

Flex enabled applications keep a port open to the license server.  When that port goes away the server (usually) detects it immediately and releases the keys for the session that was connected.  The heartbeats take longer to detect this.  If you rely on the heartbeats for this, then a key will remain in use for some time and may prevent another instance of the application from getting a key.

The doc for lc_checkin has this statement: "When a license server supplied the licenses, the vendor daemon will detect the fact that the FlexEnabled application exited, and return any licenses that were checked out back to the available pool."

This doesn't specifically refer to the disconnect of a port, but you can probably find something else that says that directly.  I'm pretty sure I've seen some doc or support articles that state this.

You can experiment to see how this behaves.  If you kill your client application you should see the key returned immediately, even if you have heartbeats disabled.

Heartbeats will catch the rare cases where this does not happen (when a network problem happens and the port isn't closed).  But heartbeats also allow for reconnecting and checking out the license again, and they are also a way for the client to detect that the server has gone away.  So be sure to understand and implement the heartbeats.

 

Eric

0 Kudos