Salesforce

Floating License Support (Magic xpi 3.x)

Printable View
« Go Back

Information

 
Created ByKnowledge Migration User
Approval Process StatusPublished
Objective
Description

Floating License Support (Magic xpi 3.x)

Magic xpi's default behavior is that you have to define the number of licenses that each Server uses during the execution of a project (in the Assigned License Threads setting or in the mgrb.ini file’s MaxConcurrentRequests setting). This number is checked across all the Servers in a multi-project environment to ensure that it is within the license limitation. For example, if you have a license with 20 threads, and you have two projects running in a multi-project environment, you have to distribute the threads in advance. Project A might receive 15 threads, while Project B receives 5.

In a multi-project environment, each Server is related to a project. This means that the capacity of each Server (project) is a key issue, and the ability to share licenses (threads) is very important.

Magic xpi's floating license mechanism lets you make optimum use of these licenses in a multi-project environment, by sharing licenses between Servers. You activate this functionality by setting the mgrb.ini file’s FloatingLicense flag to Y for each project in the multi-project environment.

Common License Approach

In this approach, each project is assigned a set number of licenses in the Assigned License Threads setting. When multiple projects are run, they share their licenses. Therefore, when a particular project is idle, other projects can utilize its licenses.

Because the Magic xpi Broker controls the Servers and their capacity, it needs to know the total number of licenses that are available for its Servers. The broker adds up the total number of license threads belonging to each Server, except for Servers whose number of threads are defined as -1 (see the Fixed Pool Approach section below). The broker uses this figure as the total number of available threads. If the broker sees that a particular Server is not using its allocated number of threads, these threads can be used by other Servers.

To use this functionality, follow these steps for each project:

  1. Set the required thread value in the Assigned License Threads property (under Project > IFS Settings) or in the ifs.ini file’s MaxConcurrentRequests setting.

  2. Add the FloatingLicense flag to the mgrb.ini file, and then set the flag to Y. The default for this flag is N.

The following are two examples of this approach:

Scenario 1

Project A

MaxConcurrentRequests = 5

Project B

MaxConcurrentRequests = 7

Project C

MaxConcurrentRequests = 8

  • Project A checks out the full 5 threads from the license.

  • Project B checks out the full 7 threads from the license.

  • Project C checks out the full 8 threads from the license.

  • All three projects can consume up to 20 threads from the pool.

  • If one of the projects is stopped, the amount of threads that were checked out by this project will be subtracted from the pool. For example, if project B is stopped, the available pool for projects A and C will be 13 (5+8)

Scenario 2

Project A

MaxConcurrentRequests = 15

Project B

MaxConcurrentRequests = 5

Project C

MaxConcurrentRequests = -1

Note: -1 means that they will share the license with the engine(s) that already checked out a number of threads.

  • Project A checks out 15 threads from the license.

  • Project B checks out 5 threads from the license.

  • Project C does not check out any threads from the license.

  • All three projects can consume up to 20 threads from the pool.

  • If one of the projects is stopped, the amount of threads checked out by this project will be subtracted from the pool.

  • If project B is stopped, the available pool for projects A and C will be 15.

  • If project C is stopped, the available pool of threads for projects A and B will remain as 20.

  • When both projects A and B are stopped, there will be no more threads available for project C to consume from the pool.

Fixed Pool Approach

In this approach, all of the licenses are held by one project, but any project can consume the available license.

To use this functionality, follow these steps:

  1. Set the required threads value in the Assigned License Threads property (under Project > IFS Settings) or in the ifs.ini file’s MaxConcurrentRequests setting. Enter 0 (or any other number, except -1). Click OK. This setting is done because at least one of the Servers has to check out a number of licenses. A value of 0 means that the engine will check out all of the threads that are defined in the license.

  2. In all other Servers, set the Assigned License Threads field to -1. This means that they will share the license with the engine(s) that already checked out a number of threads.

  3. Add the FloatingLicense flag to the mgrb.ini file, and then set the flag to Y. The default for this flag is N.

The following is an example of this approach.

Scenario 3

Project A

MaxConcurrentRequests = 0

Project B

MaxConcurrentRequests = -1

Project C

MaxConcurrentRequests = -1

  • Project A checks out the full 20 threads from the license and adds them to the license pool.

  • All three projects can consume up to 20 threads from the pool.

  • If project A is stopped, projects B and C will have no threads in the pool to consume until project A is started again.

  • In this scenario, project A is a dummy project. It does not consume any threads, and is only used for the thread check out process.

  • Projects B and C can be stopped or started without influencing the license pool's maximum capacity.

Since version:

V3

Reference
Attachment 
Attachment