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

[SimonF]

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

[raffie · Accepted 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

[SimonF]

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.

[baudewijn_verm]

This bug looks similar to issue with feature versions as well. If license server has features with different versions, it can happen that license server lmgrd/daemon fails to support a feature when you request feature of high (existing) version. This bug started to popup from FNP 11.12.x onwards; not before.