MarkLogic Server allows you to limit the maximum number of concurrent user sessions against a given App Server. This section describes this feature and provides information on configuring the concurrent request limit, and includes the following parts:
There is an option on each App Server (HTTP , ODBC, XDBC, and WebDAV Server) configuration to limit the number of concurrent requests a user can have against that App Server. A concurrent request is defined to be a request against that App Server from the same user while another request from the same user is still active. Each App Server has a
concurrent request limit configuration parameter. The default is 0, which means there is no limit to the number of concurrent requests. The value must be an integer greater than or equal to 0.
If you set the
concurrent request limit configuration parameter to a value other than 0, it limits the number of concurrent requests any user can run against that App Server to the specified number. For example, if you set the number to 3, then any requests made by a user named
raymond while 3 requests from
raymond are running will fail with an exception.
concurrent request limitfield, enter a value corresponding to the maximum number of concurrent user sessions you want to allow. For example, if you want only 3 concurrent sessions, enter 3. A value of 0 means there is no concurrent request limit (unlimited).
MarkLogic Server allows you to manage when a user or group of users cannot run requests against an App Server. You can manage these blackout periods for each App Server by setting up one or more Request Blackouts for an App Server. Request blackouts can specify users, roles, and time periods for the blackouts, as well as specifying if it is a one-time blackout or a recurring blackout.
A database named
Last-Login is created upon installation of (or upgrade from 3.2 to) MarkLogic Server. You can use this database as the last-login database for one or more App Servers. Each time a successful or unsuccessful login is made via the App Server, the last-login database is updated with that information. Only information for the last login attempt is retained. Because this database is constantly changing with each login attempt (every request is authenticated, so each request updates the last-login database), it is a good idea to use a different database than content database for your last-login database. In general, it is probably OK to keep a single last-login database that is shared by all App Servers who use this functionality, but if you do this, keep in mind that the information will then be shared by all the App Servers; that is, that the last-login time and other statistics will be for all App Servers using the last-login database.
Last-Logindatabase is created for this purpose, but you can select any database that you want. If no last-login database is selected, then the last-login feature is disabled.
trueon the Display Last Login radio button.
Each App Server configuration page has a
display last login setting. The value of this setting is returned as part of the XML output of the xdmp:user-last-login API. You can use this information as logic in your application to determine whether to display some last-login information to the application.
The Admin Interface uses the
display last login setting to show information about its last login attempt. When a last-login database is configured and the
display last login setting is true, then something similar to the following is displayed at the bottom of each page of the Admin Interface: