cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
SimonF
Flexera beginner

LM_A_CHECKOUTFILTER leads to "-5,346 No such feature exists"

Jump to solution

I am looking to add some additional checks  for future use cases and have run across a problem that occurs is this simplified setup when either LM_A_CHECKOUTFILTER or LM_A_CHECKOUTFILTER_EX are used.

On the license server there are 3 INCREMENT lines for a feature f1 with varying serial numbers (SN=1 SN=2 SN=3) in that order.


lic file:

#comment#
SERVER this_host ANY
VENDOR demo demo/demo
INCREMENT f1 demo 1.0 permanent 10 SN=1 SIGN="..."
INCREMENT f1 demo 1.0 permanent 10 SN=2 SIGN="..."
INCREMENT f1 demo 1.0 permanent 10 SN=3 SIGN="..."

LM_A_CHECKOUTFILTER is set to a function that checks the serial number in the passed Config conf


If the function returns 0 when conf->lc_serial matches "1" and 1 for all other cases:
- The filter function is invoked for the first feature line and returns 0
- The checkout is attempted and completes as expected
(0, There was no error)

If the function returns 0 when conf->lc_serial matches "42" and 1 for all other cases:
- The filter function iterates over all the feature lines and since it returns 1 for all of the the checkout fails eventually
(-73, Local checkout filter rejected request)

These 2 cases are consistent with the operation described in the documentation, however:

If the function returns 0 when conf->lc_serial matches "2" and 1 for all other cases:
- The filter function is invoked for the first line and returns 1. Since it failed, the function is invoked again for the next line.
- Here, the filter function return 0. Instead of proceeding with the checkout the function is invoked again with the next line.
- For the third line, the function returns 1.

- The checkout fails eventually despite one feature line passing the filter
- The error produced is (-5, No such feature exists) which is also logged in the vendor daemon log

- In the same case, when the feature lines in the lic-File are manually reordered so that they read (SN=2 SN=1 SN=3) the checkout succeeds, however


Is my understanding of LM_A_CHECKOUTFILTER flawed or does is not support cases where only some feature lines satisfy the added requirement in the filter function? I also tried to do similar checks with the vendor string as described in the KB article "How to use LM_A_CHECKOUTFILTER" with the same result.

As soon as the allowed license feature line is not the very first one examined no checkout is performed

0 Kudos
1 Solution

Accepted Solutions
raffie
Active participant

Re: LM_A_CHECKOUTFILTER leads to "-5,346 No such feature exists"

Jump to solution

This is likely because of license pooling.  Flexnet will pool those increment lines as if they were one line.  This means that you can only get the SN= data for one of those.  The way around it is to force pooling to not happen.  Look in the doc for the specifics on how to do that.  I think having unique vendor_strings might be enough to do that.  Of course disabling pooling has some drawbacks, too, so make sure you understand the trade offs when deciding on this.

Eric

View solution in original post

2 Replies
raffie
Active participant

Re: LM_A_CHECKOUTFILTER leads to "-5,346 No such feature exists"

Jump to solution

This is likely because of license pooling.  Flexnet will pool those increment lines as if they were one line.  This means that you can only get the SN= data for one of those.  The way around it is to force pooling to not happen.  Look in the doc for the specifics on how to do that.  I think having unique vendor_strings might be enough to do that.  Of course disabling pooling has some drawbacks, too, so make sure you understand the trade offs when deciding on this.

Eric

View solution in original post

SimonF
Flexera beginner

Re: LM_A_CHECKOUTFILTER leads to "-5,346 No such feature exists"

Jump to solution

In the real world use case the vendor strings would have been different as well.

I suspected as much and had previously tried to use it as the filter criteria but received the same results.

But indeed, as soon as ls_compare_vendor_on_increment is set to a non-zero value (and the vendor string is different for lines) the behavior is as expected.

While this isn't a perfect solution for our use case it might be worth the drawbacks, especially once the vendor daemon is due for various updates anyway.

0 Kudos