cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ageorge
Level 6

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

Jump to solution

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.

0 Kudos
(2) Solutions
jberthold
Revenera Moderator Revenera Moderator
Revenera Moderator

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,

View solution in original post

0 Kudos
jberthold
Revenera Moderator Revenera Moderator
Revenera Moderator

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) 

View solution in original post

(9) Replies
jberthold
Revenera Moderator Revenera Moderator
Revenera Moderator

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,

0 Kudos

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.

0 Kudos
jberthold
Revenera Moderator Revenera Moderator
Revenera Moderator

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,

0 Kudos

 Hi @jberthold ,

I'm using Java Client 2019 R2.

Thanks.

0 Kudos

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

0 Kudos
jberthold
Revenera Moderator Revenera Moderator
Revenera Moderator

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,

0 Kudos

 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.

0 Kudos
jberthold
Revenera Moderator Revenera Moderator
Revenera Moderator

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) 

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.

0 Kudos