Using the setIncrement() on CapabilityRequest of features with different versions doesn't renew all features

[ageorge]

Hi there,

I have this setup...

Feature f1, version 6.4, count 3 and expiry date of  31 dec 2019

Feature f2, version 99.9, count 3 and expiry date of  31 dec 2019

I create a capability request asking for version 6.7 of both features f1 and f2  (one count of each). I borrow and acquire these with no problem.

Then I create a new CapabilityRequest with the setIncrement() flag, with the intention of getting both of the features renewed.

The result I get was only feature f2, was being returned in the response despite there being no problems with the count or anything else.

When I changed to explicitly add both features with the versions they were acquired into the CapabilityRequest, that worked fine.

My question - is this expected behaviour?

Thanks.

[jberthold · Accepted solution]

Hi @ageorge ,

I repeated the same test with the CapabilityRequest example in the Java SDK:

I first requested f1 and f2 v6.4 from the server:

options.addDesiredFeature("f1", "6.4", 1);
options.addDesiredFeature("f2", "6.4", 1);
//options.setIncremental(true);

"View" Results:

Features found in trusted storage
f1 6.5 Nov 11, 2019 1 Hostid=ANY NOTICE="LLS TEST" VENDOR_STRING="LLSACTID1" ISSUED="Nov 4, 2019" START="Apr 17, 2019", Valid for acquisition
f2 99.9 Nov 11, 2019 1 Hostid=ANY NOTICE="LLS TEST" VENDOR_STRING="LLSACTID1" ISSUED="Nov 4, 2019" START="Apr 17, 2019", Valid for acquisition

Then sent an empty incremental request to the server:

 //options.addDesiredFeature("f1", "6.4", 1);
//options.addDesiredFeature("f2", "6.4", 1);
options.setIncremental(true);

Both features f1 and f2 were acquired:

Features found in trusted storage
f1 6.5 Nov 11, 2019 1 Hostid=ANY NOTICE="LLS TEST" VENDOR_STRING="LLSACTID1" ISSUED="Nov 4, 2019" START="Apr 17, 2019", Valid for acquisition
f2 99.9 Nov 11, 2019 1 Hostid=ANY NOTICE="LLS TEST" VENDOR_STRING="LLSACTID1" ISSUED="Nov 4, 2019" START="Apr 17, 2019", Valid for acquisition

I wouldn't expect there to be a difference with  in-memory vs file-based trusted storage.  If you could please submit a support ticket so this can be with tracked with your account it would be appreciated. 

Best regards,

[jberthold]

Hi @ageorge ,

You stated you initially requested version 6.7 of both features f1 and f2 without a problem.  The version of feature f1 on the server is 6.4, a request for f1 version 6.7 should not be satisfied as the requested version is greater than the licensed version.  Can you please verify?

Thanks,

[ageorge]

Sorry my error, it was late on Friday! I've extracted and highlighted the corrected info below.

Feature f1, version 6.5, count 3 and expiry date of  31 dec 2019

I create a capability request asking for version 6.4 of both features f1 and f2  (one count of each). I borrow and acquire these with no problem.

[jberthold]

Hi @ageorge ,

No problem!  I figured that was the case.  Which toolkit are you using?  I ran the same test using the .NET Toolbox app and was not able to reproduce your findings.  I requested f1 & f2 v6.4 from a server, then sent an incremental request with no features.  I received both f1 and f2 back with a renewed borrow period.  Screenshot attached.

Best regards,

[ageorge]

 Hi @jberthold ,

I'm using Java Client 2019 R2.

Thanks.

[ageorge]

Also I thought I should add that we use in memory trusted storage.

[jberthold · Accepted solution]

Hi @ageorge ,

I repeated the same test with the CapabilityRequest example in the Java SDK:

I first requested f1 and f2 v6.4 from the server:

options.addDesiredFeature("f1", "6.4", 1);
options.addDesiredFeature("f2", "6.4", 1);
//options.setIncremental(true);

"View" Results:

Features found in trusted storage
f1 6.5 Nov 11, 2019 1 Hostid=ANY NOTICE="LLS TEST" VENDOR_STRING="LLSACTID1" ISSUED="Nov 4, 2019" START="Apr 17, 2019", Valid for acquisition
f2 99.9 Nov 11, 2019 1 Hostid=ANY NOTICE="LLS TEST" VENDOR_STRING="LLSACTID1" ISSUED="Nov 4, 2019" START="Apr 17, 2019", Valid for acquisition

Then sent an empty incremental request to the server:

 //options.addDesiredFeature("f1", "6.4", 1);
//options.addDesiredFeature("f2", "6.4", 1);
options.setIncremental(true);

Both features f1 and f2 were acquired:

Features found in trusted storage
f1 6.5 Nov 11, 2019 1 Hostid=ANY NOTICE="LLS TEST" VENDOR_STRING="LLSACTID1" ISSUED="Nov 4, 2019" START="Apr 17, 2019", Valid for acquisition
f2 99.9 Nov 11, 2019 1 Hostid=ANY NOTICE="LLS TEST" VENDOR_STRING="LLSACTID1" ISSUED="Nov 4, 2019" START="Apr 17, 2019", Valid for acquisition

I wouldn't expect there to be a difference with  in-memory vs file-based trusted storage.  If you could please submit a support ticket so this can be with tracked with your account it would be appreciated. 

Best regards,

[ageorge]

 I must have been doing something wrong.

I will try it again later and see if I can get it to work. If not I will raise the support issue as you say.

Thanks very much @jberthold for the help.

[jberthold · Accepted solution]

Hi @ageorge ,

As one final test I changed the CapabilityRequest example to use in-memory trusted storage.  Following the second empty cap request with the incremental flag enabled both f1 and f2 were still checked out:

-------------------------------------------------------------
Device Name     Feature Registered(Used Count)
-------------------------------------------------------------
JimB_Java_123                  f1(1) f2(1) 

[ageorge]

Hi @jberthold , I found what I was doing wrong. My initial borrow cap request to get F1 and F2 was not correct. I sent separate cap requests without making them incremental so when F2 was borrowed, actually F1 was not in trusted storage hence the renew with the setincrement flag never returned F1 as I expected. I'v change my initial cap request and I'm getting the same results as you describe. 

Thanks.