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

Multiple instances of client application running on the same machine checking out from same Local License Server

Hi,

I'm using Java Client 2019.2.

Say I have 1 count each of licenses F1 and F2 on my local license server.

Scenario 1

on 1st run of my client application, I send a capability request to get 1 count of F1. 1 count of F1 is successfully acquired. I leave client application still running - so still holding onto F1.

I launch another instance of my client application from the same machine, again requesting 1 count of F1. I would expect it to fail with no licenses available but it doesn't. It successfully returns 1 count of F1.

 

Scenario 2

on 1st run of my client application, I send a capability request to get 1 count of F1. 1 count of F1 is successfully acquired. I leave client application still running - so still holding onto F1.

I launch another instance of my client application from the same machine, but this time I send a capability request only for 1 count of F2. It successfully acquires 1 count of F2 but I notice on my license server manager that license F1 now has 1 count available and 0 in use. Looks like the 2nd application's request for just F2 made F1 be checked back in.

 

So in both scenarios, it seems the server treats the multiple instances coming from the same machine as one. How do I make sure that each instance is treated separately?

Thanks.

0 Kudos
(16) Replies
ejohnson1
Flexera Alumni

Hi @ageorge ,

Trusted storage access depends mainly upon the hostId (and feature, version, date and count that I'll get to later), so as long as you bring the same hostId, each application instance launch will see the trusted storage contents as fresh or new, like a reflective mirror. 

A suggestion - upon launch, can you check trusted storage, see that it's 1, increment the count (2) and access trusted storage again? Access should fail not because of the hostId, but instead the count, which is related directly to multiple instances.

I'm still noodling on scenario 2.

BR,

Eric

 

0 Kudos

Hi @ejohnson1,

Thanks for the reply.

Yes, I have tested that scenario already and found it returns no feature but status of FEATURE_COUNT_INSUFFICIENT - which is understandable. Especially as I don't set the partial flag on the capability request.

If the server treats each request from multiple clients from the same machine as the same request that will represent a potential loophole because a client application can then be deployed on a "server machine" for use by as many users as possible from that server. In effect, buy one count of a license and use many times.

Thanks.

 

0 Kudos

Hi @ageorge ,

I believe you've successfully utilized the increment flag to count the desired count when requesting from the license server in another thread. Is that correct?

The server component controls the concurrent count, not trusted storage.

Thanks,

Eric

0 Kudos

Hi @ejohnson1 , sorry but I don't quite follow what you mean.

0 Kudos

Hi @ageorge ,

Thanks for sharing the trusted storage configuration is in memory.  Below is taken from the documentation, which hopefully more articulately described trusted storage behavior.

+++++++++++++++++++++++++++++++++++++++++++++

Any previous license rights in trusted storage are overwritten with the data from the new capability response. For this reason, trusted storage rights are sometimes called regenerative license rights or replacement license rights.

+++++++++++++++++++++++++++++++++++++++++++++

@maximilianhense  correctly noted using different paths for trusted storage (if it's persisted to file / disk), but then you noted memory, which makes it trickier because memory is utilized as a singleton by the FNE stack.

Edit:  double-checking on the memory singleton, although it seems to align with your results.

 

 

0 Kudos

Hi @ejohnson1 , I have tried using the increment flag with all capability requests now as you hinted and I'm getting mixed results.

Now each client application instance running consumes 1 count. So I have 3 counts of license F1.

First client borrows and acquires 1 count, same for second and third clients (all running from the same host machine). On my license server manager it does indeed show that the same device has 3 counts of license F1 served to it. All good to this point.

However when I start fourth and fifth instances of the client, they are also able to still seemingly borrow and acquire a count each of license F1. Should this not fail with the FEATURE_COUNT_INSUFFICIENT status?

0 Kudos

Hi @ageorge ,

>> they are also able to still seemingly borrow and acquire a count each of license F1. Should this not fail with the FEATURE_COUNT_INSUFFICIENT status?

What's the total count of F1 on the LLS?

0 Kudos

Total count of F1 on LLS is 3.

0 Kudos

Hi @ageorge ,

Please find a test correctly showing the desired result using the DotNetDemo.exe utility. It appears there might be leakage as you've reported yet, using the utility upon clicking into the "Response Details", do we see the notification as you expected and is shown.

I think you have access to this tool, which using the IdentityClient.bin to run.

Edit: on the right-part, also click on the 'Status' tab.

 

 

0 Kudos

Hi @ejohnson1 , I just used my IDE to debug and found these results.

The response does contain the 2 features i.e. calling ICapabilityResponseData.getFeatures() returns the 2 licenses with the correct expiry date (i.e. expiry date in line with the borrow duration specified). However an inspection of the status shows as FEATURE_COUNT_INSUFFICIENT. I would expect that with that status, the getFeatures() should return no licenses.

 

AcquiredFeatures.png

0 Kudos

Hi @ageorge ,

The status indicates the count requested from the LLS cannot be met (and without disruption to previous capability exchanges - appInstance1, appInstance2, etc.), so processing of the response received from from the LLS should also fail.

Question, is the expiry date different in the status than it is currently in trusted storage (in memory)?

BR,

Eric

 

 

0 Kudos

Also, can you confirm the capability exchange fails (FEATURE_INSUFFICENT_COUNT)...but...then getFeature succeeds?

The reason getFeature succeeds is because it's accessing local (in-memory) trusted storage. This memory is shared across all your run applications.

Also, if you process the response, it will "renew" the borrow time for the features the server could satisfy. If you don't process the response, the expiry time in trusted storage will not change.

 

 

Ok, I think I understand a bit better what is going on.

That said, I find it a bit confusing to get a status of insufficient count but still get feature(s) returned.

I believe the concept of shared/singleton trusted storage memory also explains the results I was seeing in scenario 2 in my original post.

Thanks for the help.

0 Kudos

Thanks for the feedback @ageorge .

FlexNet Licensing typically favors usability over security (or stoppage),  hence the LLS returning what it can satisfy.  If (hypothetically) instead a denial and no features (for the same host/user/etc), processing would obliterate the run-time associated licensing for the other instance checks on getFeature, etc.

0 Kudos
maximilianhense
Level 4

Have you tried to generate different Trusted Storages within each instance?
So that each instance generates its own Trusted Storage file.
0 Kudos

@maximilianhense The client application uses in memory trusted storage. I would have thought that should mean trusted storage is not shared between the different instances.

0 Kudos