We have started testing LexFloatServer under load. Our test system generates several thousand licensed processes over several hours. We have 4 machines each running multiple simultaneous testcases. According to the most recent log collected, the maximum number of concurrent license activations was 78.
We are seeing a lot of HTTP errors (many hundreds of failed tests):
“HTTP error 400: INVALID_FLOATING_CLIENT_TIME Invalid request!” following license activation requests.
“HTTP error 404: Floating license does not exist!” following license renew or meter attribute update requests.
I have logged in to the machine serving the licenses and the test machines and their clocks are in sync so time differences do not seem to be the problem.
How can I go about debugging this? Will setting the debug level in config.yml to zero give me any extra information that will actually help?
Hi Gary,
It seems that there might be a network delay due to which the error INVALID_FLOATING_CLIENT_TIME is thrown. By default, the allowed clock offset value is set to 60 seconds. To address this issue, we recommend considering an adjustment to the config file of the LexFloatServer by increasing the allowed clock offset value. This adjustment can help accommodate any potential network delays.
Regards,
Ahmad.
Thanks Ahmad. I will try setting a big offset and see what happens.
I haven’t had time to change this value yet. We discovered that we had firewalls on the test nodes that were causing other problems, so we have turned them off and my first re-run with LexFloatServer was just to see if the firewalls made a difference. They did not. So I will try changing the clock offset setting next. But rather than mess about with different offset values, will it be more effective to initially try setting Disable clock validation to True in the license itself?
And that leads me to a second question, about sync with the cloud server. I can tell from a “License will expire” message that the LexFloatServer has not synced with the cloud server, because I extended the license in the cloud but LexFloatServer still thinks expiry is imminent. We have Server sync interval set ridiculously short in the license at 300s. Is this, and a correct cryptlexHost value in the config.yml, what determines syncing with the cloud server? I found an old post asking about the ServerCheckInterval setting (I presume in config.yml). Is this now a hidden feature that I can try setting? In the meantime will check internally to try to find out if we ourselves are somehow blocking traffic between the LexFloatServer and the cloud server.
Thanks, Gary
Hi Gary,
The on-premise floating license you configure in the dashboard, configures the license settings for LexFloatServer activation not the end user activation. So disabling clock validation will affect the clock between LexFloatServer and Cryptlex server. It has nothing to do with the error you are facing.
LexFloatServer may need a restart for server sync changes to apply as it caches some info for performance reasons. So, if license for lexfloatserver has expired, and you have extended the license in Dashboard, you may need to restart the lexfloatserver for changes to reflect.
Also, can you share the configuration of the servers (number of cpus and memory) you are using for hosting LexFloatServer at support@cryptlex.com
We adjusted the allowed clock offset as suggested, and also lengthened server sync periods because we’d originally set them far too short. However, we still get too many HTTP errors (a few hundred out of 7000 client activations). It was suggested that our client code could simply re-activate its license if it gets one of these errors. While I’m sure this will be a good workaround, it is not an ideal solution. We want to be able to count activations in the log to understand the end-user’s usage patterns. But if each run of one of our programs could result in any number of activations, it will be impossible to produce sensible usage counts. We might be able to work around this if we could send a custom message or custom piece of metadata to the log to indicate that this activate call is a re-activation, but that feature is not available.
Hi Gary,
We are planning to implement a behavioural adjustment within the LexFloatServer. These changes will enable LexFloatServer to accept seat renewal requests for floating clients, even in cases where renewal fails due to time-related errors, provided that the seat is available.
Thank you. We will be happy to beta test it when it is ready, if that will help you.
Hi Gary,
Please download the LexFloatServer beta build from the link below:
This build addresses the issue of license renewal failure. Please make sure to add leaseDurationGracePeriod in the config.yml file. This can have values between 15-60 (secs). For your use case set its value to 60.
In case you are sending requests to LexFloatServer using the LexFloatClient make sure to update the LexFloatClient to the latest version as well.
Regards,
Ahmad.