Thanks Adnan.
To clarify request 1, printing both AllowedUses and TotalUses in the log would be helpful so that when parsing the log you don’t need to also query the server to find AllowedUses.
One extra request for the log. We write the user’s name into the activation metadata because it is useful to some of our customers to track who is using particular entitlements. We can extract this custom metadata from the cloud license logs, but it doesn’t appear in the LexFloatServer log output. It would be helpful to us if SetFloatingClientMetadata generates a log entry that prints out the metadata (referenced by the activation uuid so that we can match it to a specific activation).
There could be a lot of activation metadata fields, and logging every field with the log is not practical.
Any news on the two enhancements you thought were sensible?
Both of these features will be incorporated into LexFloatServer by the end of this month.
Brilliant, thank you!
Can you share a development progress update? Are you on target for the end of September?
Thanks,
Gary
It’s a bit naughty to send this so late, but these are the kind of API calls that would let us query everything we need from the server.
-
<api>/metadata- return json blob of all metadata keys and values. Bonus feature would be the ability to query an individual metadata item by adding?id=uuidor?key=<metadata_key_name> -
<api>/meter-attributes- return json blob of all meter attributes and values. Bonus feature would be the ability to query an individual meter attribute by adding?id=uuidor?name=meter_attribute_name -
<api>/activations- return json blob of all activations, with all the data that the web view shows plus any custom metadata the activating program has provided. The web view should be fixed to show the latter as well because currently it does not (v4.9.2). The activation data should also track the meter attribute increments owned by each activation so that we have the ability to find out who is using particular license features.
Hi Gary,
We are pleased to inform you that we have successfully implemented the requested features, and we’re excited to share the beta release with you tomorrow. We’ve been diligently working to ensure that these enhancements align with your needs and expectations.
We already have an endpoint /api/floating-licenses which serves the same purpose as requested in 3 except that it does not include the meter attribute count.
Regarding your recent message about the additional API calls and feature requests, we greatly appreciate your continued engagement and valuable input. While we understand the importance of these requests, we want to be transparent and acknowledge that they may not be feasible with the current iteration. Rest assured, we are actively taking note of these suggestions for consideration in our next development cycle.
Your feedback is invaluable to us, and we remain committed to delivering the best possible solutions for your requirements.
Regards,
Ahmad.
Thank you. I very much look forward to trying out the beta. Assuming it all works, we can let you know whether we really need the additional stuff.
Can you confirm whether the beta also addresses the license expiry issue I reported?
Can you confirm whether the beta also addresses the license expiry issue I reported?
I assume you are referring to this post where you mentioned that some(a few hundred out of 7000) clients failed to renew the license.
It is important to convey that the remedy for this issue has been incorporated into the beta build. However, it is worth noting that comprehensive testing for certain specific scenarios remains pending. We will ensure to keep you updated on this.
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.
This build includes the /api/server/license-meter-attributes endpoint for retrieving license meter attributes.
Also, the logging has been improved as well.
Regards,
Ahmad.
Thank you Ahmad. We will try to test this as soon as possible.
We need to make an internal build with the new client libraries which I hope we can get done within the next two weeks. Then we can do some serious testing, including the license expiry issue. But I did a quick test today with the beta server and apps built with LexFloatClient 4.5.3. I see the log telling me the names of meter attributes that have been incremented and decremented, which is exactly what I asked for. What is not so helpful is reporting allowedUses for meters; I would prefer to see a calculated remainingUses so that I don’t have to work it out for myself.
The license-meter-attributes endpoint works as requested. Here again I will have to calculate remaining meter allowances myself but here it’s easy because I have the two numbers I need right next to each other.
Regards,
Gary
Thanks for your feedback. We will take your suggestions into consideration and incorporate the remainingUses information into the logs.
We are now in a position to do the robustness check (seeing if the unwanted license expiry problem has been fixed). It will most likely be done in tomorrow night’s test run (October 17th). I will report findings as soon as we have them.
On a separate note, I was looking again at what we can extract by querying the LexFloatServer rest api. The floating-licenses endpoint is the one of interest. I see that it currently returns None for both the metadata and meterAttributes attributes. What would make these two attributes of value would be to return the following:
metadata: [ list of all custom metadata keys written to the activation ]
meterAttributes: [ list of all meter attribute ids that this activation currently has incremented ]
The second one of these is more valuable than the first, but we do write custom metadata that is useful to us, eg user name and program name so the first would also help us.
Is either of these possible?
Thanks,
Gary
Finally we have builds in place and have run a night’s testing on the LexFloatServer beta version. So far I see only one HTTP error, where previously we had several hundred. So clearly things look better, we don’t seem to have activations expiring when they shouldn’t.
We still have nearly half the test suite to execute as I write this so I will have to look into the timing. I think we’re usually further ahead at this time of day when we’re using Flex licensing.
I will leave our tests running on this server for a few days now to give it a good workout.
Further to the previous comment, there are no activations showing on the LexFloatServer but we still have quite a few meter increments. I assume we must have had a network failure that prevented the running programs from cleaning up their increments. I was expecting that the increments would be automatically undone when the server expired the activations that made them (isn’t this what the “floating” attribute does if the license is hosted-floating?). Is there a way to undo these increments that doesn’t involve writing a program that will contact the server and explicitly find and decrement them?
Our tests ran properly last night. There is no timing issue, and there were no failures due to expiring activations so all looks well.
Glad to hear that the activation-related issue was resolved. Related to the floating meter attributes, yes they should automatically be reset once the floating client activation is dropped.
To provide more accurate assistance, could you please share details on how you checked the meter attribute count after the activation was dropped?
We recommend continuing this conversation via our support email at support@cryptlex.com.