The ServerSpecifiedConcurrentUserLimit constant in the LicensePoolManager is not actually used to enforce this limit on the server. It is used to make sure that the sum of all the specified concurrent user limits per pool do not exceed the server's limit. In other words, if you have a server limit of 5 concurrent users, it won't allow you to set two pools to a limit of 3 concurrent users each for example. (This is done through a BCo validation microflow of the LicensePool object)
The actual enforcing of the server's limits however, is left to licensing mechanics in the Mendix software. It's assumed that the ServerSpecifiedConcurrentUserLimit is set to this limit, or if there is no enforced concurrent user limit, the ServerConcurrentUserLimit is set to false.
I suspect what happened in your case is that you did not specify concurrent user limits for at least one license pool. As a result the application allowed you to log on until the likely non-existent enforced concurrent user limit was reached.
So to recap, the constant is used to make sure that license pools do not get assigned a higher total concurrent user limit than the server's limit, not to enforce the server limit itself.
Regarding Named vs Concurrent users I think you might have the wrong expectation of the definition of a Named user in the LPM. The License Pool Manager follows the definition which is/will be used in the Mendix license mechanic:
I just recalled your initial request for an LPM-like mechanic, so I suspect you see a Named user as a license which is reserved for someone so he can always log in. This is not quite how it works in the LPM, where a named user is an Account (or specialization of it) which is committed to the database and in a licensepool (I'll make some adaptations in future LPM versions to account for named users not in a licensepool and how they affect server limits) Basically a named user limit in other words is essentially a user limit on the server, or a limit on the amount of users you can add to a licensepool.
To achieve the situation which I recall you asked for I'd suggest the following:
For example, say you sign a contract with Profits 'r Us in which you agree that they will have a maximum of 30 named users, 15 concurrent users, of which 4 are reserved accounts. I'd suggest making the following:
Any sort of mechanic where if your application exceeds its limits on concurrent users it then allows additional to log in with reduced privileges is not planned to be implemented for Mendix though to my knowledge.
I suppose your current implementation uses unlimited concurrent users and limited named users, which indeed will work fairly well for that licensepool. However since there is no concurrent user limit counting towards the server limit (ie, no concurrent user slots being reserved for this pool), you could run into issues of the server having less concurrent user slots available than named users in that pool.
Thanks Sjoerd, I think I have been confused with the way the limits work. I have the server limits all back to the same values there were initialy, and am still trying to make sure that a particular licence that I have set only allows 3 users to login at one time. What's the best way to achieve this?
On the front-end I have set the licence with named users set to unlimit, and the concurrent users set to 3. Isn't this number supposed to limit that number of logged users at one time for the relevant licence? I'm not able to see any details on the active sessions either, even though I have logged 4 users on the server. Is there any other setting that I am missing?
I've made sure the As_listener runs when I login, and set flag on server for persistencesessions = true. Not sure what else I need to do to inforce concurrency, and view session details. LR.
If you want three users to be able to login maximum, you could achieve this by putting them in the same license pool and setting its concurrent user limit to 3. This should mean that 3 users from this license pool can login at once at the most. Should you (using 4 different browsers) be able to login 4 or more users at once, something is going wrong. Please let me know in that case.
To give you an overview of the limits/constants and their working:
ServerConcurrentUserLimit and ServerSpecifiedConcurrentUserLimit as mentioned before are used in BCo microflows when saving a licensepool to enforce the server's limits to the licensepool and make sure you do not exceed these. They should reflect your server's limits if it has any, or set to unlimited if your server does not have limits.
ServerNamedUserLimit and ServerSpecifiedNamedUserLimit do the same, but for named users.
The named user limits you define in the application for a license pool are enforced by microflows which will prevent you or any Pool admin from creating additional users if the named user limit has been reached.
The concurrent user limits of the licensepool are enforced by the login listener, which will check for the current users from the licensepool who are online and check if there is still room for the person trying to log onto the server.
Any server limits for named and concurrent users will be enforced by the Mendix software, assuming you are using a Mendix version for which this is already implemented. If this is not the case, the server limits are effectively unlimited for the purposes of the LPM, and defining any server limit in the constants will not have any effects aside from not letting the sum of the specified licensepool limits exceed these numbers.
I assume btw when you mention license, you mean licensepool? considering the application will be running on a single license and the LPM will then let you essentially partition that license if you have multiple customers using the same application.
Regarding the Active Sessions, it should be possible to see those. If you cannot, I suspect there's either a security issue (insufficient rights for the ranks in the System module for example), or an inheritance related issue. (David Sanders had this a few weeks ago). So should this page remain blank despite having users logged in which you should be able to see the sessions of (all, if you are logged in as server admin), please review if the account has sufficient rights (including those to manage users of other roles) or let me know about any inheritance you might use.
On a sidenote btw, persistent sessions are not necessary for the LPM, due to the option to retrieve the current sessions which was added to the API in 2.5.3, which is also used for the Active Sessions.
PS I realized today while considering your problem that the current version has some issues for servers with a specified user limit but license pools which do not have such a limit. (Right now these pools could cause the server to reach its limit before the pools with specified limits reach theirs) I'll release a new version in the upcoming days where this is fixed by no longer allowing licensepools with unlimited named/concurrent users if the server has a specified limit in that category.
My testing of this module indicates that you can successfully restrict concurrent users in pools, OR named users, but not a mixture of the two.
In your case, create 2 concurrent user pools, one with a limit of 3 and the other with a limit of 2. That should work as expected. If the second license pool is set to named users, the logic will not work as expected.
(Sjoerd, I would expect that the number of named user pool licenses should be subtracted from the server total to calculate the number available for concurrent user pools. This does not seem to happen)