MarkLogic Server 11.0 Product Documentation

Administrator's Guide — Chapter 12

Limiting Concurrent Requests with User Request Limits

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.

When the limit is reached, the application will throw a 403 (forbidden) error with the XDMP-REQUESTLIMIT exception.

Configuring User Concurrent Request Controls

To configure a user concurrent request limit, perform the following steps in the Admin Interface:

1. Click the Groups icon.
2. Click the group in which the App Server you want to configure resides (for example, Default).
3. Click the App Servers icon on the left tree menu.
4. Select the App Server in which you want to configure concurrent requests limits. The App Server Configuration page displays.
5. In the concurrent request limit field, enter a value corresponding to the maximum number of concurrent user requests you want to allow. For example, if you want only 3 concurrent requests, enter 3. A value of 0 means there is no concurrent request limit (unlimited).
6. Click OK to save the configuration change.

For new requests, the new concurrent request limit will be enforced.

Configuring Request Blackouts

Perform the following to configure request blackout periods:

1. In the Admin Interface tree menu, click the Groups > group_name > App Servers > app_server_name link, where group_name is the name of the group and app_server_name is the name of the App Server in which you want to specify a request blackout period.
2. Click the Request Blackout menu item under your App Server. The Request Blackout Policy Configuration page appears.
3. Click the Create tab. The Add Request Blackout page appears.
4. Fill in the form as needed for the blackout period you want to create. Clicking the radio buttons will bring up more forms to complete.
5. Click OK to create the blackout period.

The new blackout period will take effect immediately.

Deleting Request Blackouts

Perform the following to delete a request blackout period:

1. In the Admin Interface tree menu, click the Groups > group_name > App Servers > app_server_name link, where group_name is the name of the group and app_server_name is the name of the App Server in which you want to specify a request blackout period.
2. Click the Request Blackout menu item under your App Server. The Request Blackout Policy Configuration page appears.
3. In the area corresponding to the blackout period you want to delete, click the Delete button.
4. Click OK on the confirmation page to delete the blackout period.

The blackout period is deleted immediately.

Storing Last User Login Information in a Last-Login Database

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.

A history of the successful login attempts is not retained; only the time of the last successful login is stored in the database.

Configuring User Login Monitoring

Perform the following steps to set up user login monitoring for a given App Server.

1. Click the Groups icon.
2. Click the group in which the App Server you want to configure resides (for example, Default).
3. Click the App Servers icon on the left tree menu.
4. Select the App Server in which you want to configure the last-login database. The App Server Configuration page displays.
5. Select a database for the Last Login database. The Last-Login database 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.
6. Optionally, select true on the Display Last Login radio button.
7. Click OK to save the changes.

Displaying the Last Login Information for an App Server or for the Admin Interface

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:

last successful login: September 2, 2008 7:54:16 PM
                      last unsuccessful login: none
    unsuccessful login attempts since last login: 0