Because the license limits the number of concurrently logged in users, it may happen that this limit is reached and additional logins must be rejected. This is done on a first come, first served basis: whoever logs in first is granted permission, later attempts may fail. When you use CoreMedia CMS to manage the content of a single enterprise, this is normally the desired behavior. When it is important that a new connection is opened, there is always the possibility to ask other users to log out, thereby freeing concurrent licenses.

When hosting multiple content applications in a single Content Management Environment, you might want to control the logins more closely. You may have legal or operational requirements that a login is possible for certain users. Because it is not generally possible to free already assigned licenses, the server must take care to reserve licenses when they are still available.

For example, you might want to ensure that each of your five content applications is granted at least one login. Other licenses should be freely distributable. If you have bought eight concurrent licenses, there must not be two content applications that lock up three session each, because there are only two concurrent sessions for three content applications left. Still, there is nothing wrong with one content application that reserves three or even four concurrent sessions.

To facilitate the controlled distribution of concurrent licenses, a so-called login bouncer can be enabled. Picture it as guarding the entry to the server based on owner-defined rules. In order to enable a bouncer, set the property cap.server.login.bouncers to the location of an XML file that describes the bouncer's configuration. Typically, such files are placed in the directory properties/corem below the installation directory.

The bouncer grants licenses from a number of pools and enforces certain limits to the number of logged in users. Both pools and limits apply to that set of users whose names match a given regular expression and who directly or indirectly belong to certain groups.

A limit sets the maximum number of licenses that is granted to those users that are subject to the limit. A user may be subject to multiple limits. If even one limit is reached, the user is not allowed to log in.

A pool is controlled using two parameters: a minimum size and a maximum size. Given that the limits are respected, the bouncer will try to distribute the users and the available concurrent logins among pools in such a way that:

Upon every login attempt it is checked whether a new license can be allocated to the pools, possibly reassigning licenses across pools for users that are already logged in.

Minimum sizes guarantee that a certain number of users whose name matches the pools pattern can login. No matter which other users try to log in, these licenses are set aside until a user of that pool demands a license. Maximum sizes allow the number of licenses provided to grow as needed. Contrary to limits, additional users that match a pool's pattern may login after the pool has been exhausted. However, in this case there must be some other applicable pool with free licenses. One notable exception is the user admin(0), who is always permitted to login regardless of the set of currently logged in users. The super admin is only controlled by the license itself, not by the bouncer.

In the XML configuration, you may install bouncers for each individual service by inserting a <LoginBouncer> elements below the <LoginBouncers> document element. Normally, only the service editor is restricted, because other services are used by scripts and other servers in a more deterministic way.

For every bouncer, you can add an arbitrary number of <Limit> and <Pool> elements. Three attributes define the set of users to which a limit or pool applies. At least one of the three attributes should be given. When more than one is given, the set of users is restricted further.

For a limit the following additional attribute applies:

For a pool the following additional attributes apply:

A sample configuration might contain XML elements as shown in Example 3.50, “A sample login bouncer configuration”:

<LoginBouncers>
 <LoginBouncer service="editor">
 <Limit pattern=".*@(domain1|domain2)" max="80" />
 <Pool pattern=".*@domain1" min="5" max="50" />
 <Pool pattern=".*@domain2" min="5" max="50" />
 <Pool pattern=".*@domain3" max="50" />
 <Pool pattern=".*@domain4" max="50" />
 <Pool directgroup="administrator@domain1" min="1" />
 <Pool directgroup="administrator@domain2" min="1" />
 <Pool directgroup="administrator@domain3" min="1" />
 <Pool group="administrator@domain4" min="1" />
 </LoginBouncer>
</LoginBouncers>
        

Assume that a total of 100 licenses is available. The limit line states that at most 80 of these 100 licenses may be acquired by users from either domain1 or domain2. The pools for domain1 and domain2 allocate between 5 and 50 licenses. Unless 5 users from one of these domains are already logged in, there are still free licenses to allow another login. The pools for domain3 and domain4 do not specify minimum sizes. It is therefore possible that, for example, no user from domain4 is able to log in to the system, because users from the three other domains are locking up all available licenses.

Finally, the last lines indicate that some licenses should be put aside for the members of the administrator groups of any domain, to be used in emergency cases. For domain4 you add indirect members of the administrator group to the pool.

Normally, a careful assignment of licenses to pools should suffice for most setups, with limits being used in exceptional cases. The number of pools and limits should be kept relatively low, preferably not exceeding 100 in total, lest the processing time gets significant. Note that groups cannot be indicated by regular expressions as this would lead to a significant reduction in performance.