jcheng1.5524898975815227E12 asked a question.
We understand that this is the same as lc_init() + lc_userlist(), however is there a way for us to get the list of vendor names from lmgrd. Otherwise we will still be required to call lmstat at least once to get this information. Or, alternatively, remove the restriction altogether so we can simply specify the feature name, like lmstat -f .
-Johnson
Are you sure you want to cancel the case creation?
Activity: Status change: 2 hours ago
Are you sure you want to close this case
| Products | Region | Phone Numbers |
|---|---|---|
| FlexNet Operations FlexNet Embedded FlexNet Publisher FlexNet Connect FlexNet Code Insight InstallAnywhere InstallShield |
North America * |
+1 630-332-2513 (toll) +1 877-279-2853 (toll-free in North America) |
| Europe * |
+44 1925 944367 (toll) +44 800 047 8642 (toll-free in Europe) |
|
| Japan * | +81 3-4540-5335 (select option 2) | |
| Australia * |
+61 3 9895 2177 +61 1800 560 603 (toll-free in Australia) |
|
|
Usage Intelligence (formerly
Revulytics) Compliance Intelligence |
Please use the Case Portal to submit your support ticket or reach out to your Revenera contact. | |
What has been supplied requires us to have a complete mapping of vendor daemon to feature line which we don't currently require our users to supply.
We are hoping this is something that can be handled for two reasons:
1) "lmstat -f " does not require to specify the vendor daemon
2) Our previous alternative to lmstat based on the lc_userlist() also worked on multiple vendors while only calling lc_init with a single vendor daemon name (dummy effectively).
Therefore we don't believe the restriction needs to exist and it may represent serious impact if it does.
We would like to understand MV take on this.
Greg
Greg
All requests from lc_userlist, lmstat, and flxStatGetUserlist go through lmgrd, and lmgrd must know which vendor daemon to dispatch the request to.
For lc_userlist, a vendor name is hardcoded into the object (because lc_userlist is built into the same object as lc_checkout/lc_checkin) and this hardcoded vendor name is passed to lmgrd. To support multi-vendor stat, we had to eliminate this hardcoding.
For lmstat, it has no hardcoded vendor name. Instead it communicates with lmgrd to find all the vendor daemons supported by lmgrd and asks each of these vendor daemons for the feature(s) is it looking for. This extra communication (one to list all the vendor daemons and two to ask each vendor daemon regardless of whether it supports the specific feature) contributes to the performance overhead of lmstat that we are trying to avoid.
For flxStatGetUserlist, we could not hardcode and did not want to do a vendor daemon discovery and iteration. Therefore, the only choice was to have the vendor name as a parameter.
Clearly this is different from the data required by lmstat or lc_userlist. However, I recall an early conversation in which we agreed that Macrovision could assume that Platform knew the features that were managed by LSF. Since a feature name is not enough to identify a feature (feature name and vendor name is), we felt that Platform would have this information easily available at the time flxStatGetUserlist needed to be called.
David
"If [the vendor name] is NULL, just return user list without considering vendor name which would be consistent with lmstat -f"
The implication of this suggestion is that lmstat -f will stop querying the remaining vendor daemons once it finds the first vendor daemon that has status for the feature specified by -f. However, I tested lmstat and determined that it iterates over all of the vendor daemons supported by lmgrd, even if the first vendor daemon has status for the feature specified by -f. I tested this by having one lmgrd start two different vendor daemons, each serving the same feature name (davidz:f1 and davidz2:f1). I found that lmstat -f f1 queries both servers, it does not stop upon finding davidz:f1.
By flxStatGetUserlist specifying a vendor name, lmgrd can dispatch the request directly to the appropriate vendor daemon.
We agree that lmstat does not require a vendor name, but its performance overhead for that privilege is too high.
Our hope lied in the fact that lc_userlist() back in v6 was returning features from other vendor daemon taking only "lm_job" and the feature. Although lm_job was initiallized with a specific vendor daemon, lc_userlist() ignored it and could return for any vendor daemon. Further this use did not incurr the overhead of lmstat therefore we concluded that vendor daemon was not fundamentally required for the lc_userlist() call and was only a limitation for security considerations.
Obvious much could have changed from v6 to the current v10 but we wanted to ensure that all the possibilities were examined. Are we certain we have explored all the options?
Last point, we are flexible when it comes to what the behaviour is when there are two features with the same name from different vendors. This rarely in our experience and I believe we could deal with it in whatever way the data was provided (special case).
We can discuss this further in todays meeting and try to reach a conclusion.
Greg
Greg, I agree with this point. The test I mentioned which used the same feature name from two different vendors was done, not because I thought this is a common case, but it was the only way I knew to show that "lmstat -f f1" continues to query all servers, even though it finds status for f1 in a server prior to the last server.